Why developers should be the software buyers

Would you trust a F1 team manager that doesn’t know what type of tires their race car drives on?
16 March 2020 | 3 Shares

Perhaps your best business software buyers aren’t sat in the boardroom. Source: Shutterstock

Software application developers should be empowered with software procurement responsibility for enterprise organizations that want to get the best out of their IT stack at any given point in time.

It sounds like a crazy proposition doesn’t it? Why would you let the geeks start to control the IT programme? Well, when you put it like that, right? 

But all too often this ‘craziness’ is exactly how it plays out in the real world. 

Major software packages, platforms and tools are brought into organizations because a) that’s the way it’s always been done b) those are the incumbent vendor partnerships that the company works with or even c) the CTO or CIO thought that it sounded like a good idea at the time.

Lotus Notes syndrome

Anyone who has ever used Lotus Notes will know what we’re suggesting here. Notes (in the Lotus years; the latter IBM years) was always an arguably more powerful, adept and multi-functional piece of software than any other email client or similarly functional piece of software. 

It was bitty, gritty and tough to use, but that didn’t stop many companies ‘who never got fired for buying IBM’ and others thinking that it was a smart choice. But maybe a more solid observance of user functionality would have been better, no?

Does any of this lead us to the point where we might be so bold as to suggest that software developers should be the ones deciding which software platforms, tools, processes, tools and workflow principles a company uses?

Could we be on the cusp of a time of change? Software is supposed to rule the world, so shouldn’t software developers rule the decision-making process that underpins which software is running the world.

Rise of the developers

A growing number of industry commentators believe that in 2020 and beyond, we will see developers play an increasingly important role in the way enterprise technology is adopted in contemporary organizations.

Would you trust a high-end restaurant that doesn’t give the head chef a view into the provenance of the produce used in the kitchens? Would you trust a F1 team manager that doesn’t know what type of tires their race car drives on? Would you trust a rock musician that doesn’t know what brand of guitar they use? 

The software-centric data-driven cloud-first mobile-enabled world of business runs on applications, so (and we hope it’s not an unreasonable suggestion by this point) should ideally be run on an IT backbone that stems from a DNA that is engineered by people who have spent somewhere around five years studying for a degree in computer science.

Ability for responsibility 

If we give developers a more centralized remit and formalized responsibility for IT procurement than we may well find that users themselves are better cared for. 

Developers often view themselves as this middle tier function tasked with serving the (typically irrational, in the view of the coders) needs of users who ask for functional ‘requirements’ that appear to make little sense to the guys and girls who have to code and build the end product.

Give developers a more responsible role in the total process and the end result could be a more total software delivery experience overall.

There are many shards to this argument and open source could be a contributory factor. 

Developers may often opt for open platform tools and components that they know they will have access to even if they switch roles. It gives them portability and freedom. 

Given the widespread enterprise adoption of open source technology everywhere from Microsoft and onwards, denying developers the openness to be open might not be a good idea.

Giving developers the ability to choose which software platforms, tools and components they use might just, on the other hand, work out to be a really good idea after all.

Developers need more corporate responsibility, more functional operational workplace empowerment and more freedom to help steer the future direction of any given organization’s IT stack and strategy.

Just don’t give them total responsibility for ordering the corporate lunch menu, unless you’re cool with Pepsi and Pepperoni Pizza like five times a week, yeah?