Developing Software is Messy

As a software engineer, a developer, who is moving upwards (perhaps downwards) towards being an engineering manager; it strikes me that software development is messy; perhaps inherently so.

I so badly want to codify “the process” such that a developer can be plugged and un-plugged with minimal effort from my side.

We think that "If only the requirements were better" there would be no questions from developers on how to implement this or how to implement that.

There would be no questions from QA engineers on how to test this and what to test there.

We would write our stories during the day, assign them to our offshore resources at the end of the day and we would walk in to the office the next morning and find working software committed to the SVN ready to be merged and deployed. Down the pipeline it goes.

Managers know that this is not reality. This is the foodstuff for the happy hour, the lunch meeting, the tech blog.

You must spend cycles explaining an re-explaining requirements.

You must spend cycles ironing out implementation details once those requirements are understood and absorbed by your team.

You must spend cycles when code review reveals that patterns were not followed, conventions not maintained, standards not upheld.

You must spend cycles teaching QA how to test the features and functionality that you are intimately familiar with.

This is the hidden cost that is incurred for offshoring your development.

Creating software is a messy process. You must iterate. You must prototype. You must refactor. You must document. You must pivot. You will fail.

When your team is sitting next to you in the same cubicle or, at the very least, in the same time zone. This takes MUCH fewer cycles and at the end of the day the team is cross-trained. Everyone is an expert.

If you’re making software that can be codified, decomposed, distributed, retuned, merged and deployed then I’m sorry, but you’re not innovating.