The real purpose of a software developer

06 September 2017Matt Hilton

As a developer, how do you see yourself? What is your role in your team, in your organisation? Are you a specialist and a partner, or a code-producer and outsource-able commodity?

Many organisations treat software development as a commodity. These are the ones that have been failing at waterfall projects for years and realise it needs to change, so then they invest in large-scale "agile transformation" projects. Putting lots of ceremony in place in the vain hope that this will somehow magically turn them into Google or Facebook, they simply replace one form of failing project with a new form.

I believe this is because the true benefits of a cohesive software development project can't be realised unless the purpose of software developers is properly understood.

In the many variations of team constitutions and sizes that I've seen over my career, the ones that inevitably encounter the lowest quality, the longest cycle times, the most failed projects and the lowest trust between "the business" and IT, are those that attempt to organise software development as a commodity.

As development teams, it's reasonably well accepted that lines of code produced is no way to measure our success, but how do we measure it? Story points delivered? Features shipped? Shipping lots of the wrong features is still a wasteful exercise.

Developers should be striving to be partners with our non-developer colleagues. We should be supporting business decisions with data and experimentation. We should be enabling the rapid testing of hypotheses, and setting up our development and deployment practices to enable this. We should be facilitating the organisation's ability to adapt to rapidly changing competitive environments. We should be collaborators and partners to the business, allowing them to rapidly innovate and provide new, exciting customer experiences.

There's a lot of things that hold us back from realising this kind of reality. Organisational perceptions and biases aside, one of the big problems is the technical mess we create for ourselves by under-investing in our teams' capability to reliably deliver. If we want to achieve our true purpose as developers, and become valued partners to our business colleagues, we need to clean up our house and get to the point where we can deliver software regularly, rapidly and with confidence.