So perhaps it is not a surprise that the activities and people associated with building software have descended rather low in the software development pecking order and have come to be viewed as a sub-developer species of cave dwelling beings subsisting on scraps.
However, we see a light at the end of this tunnel, and beg to report that there are signs of a renaissance of builders in terms of the recognition of their importance to the overall scheme of delivering software.
In the pre-historic (bad old) days, building the system was seen as an administrative task which just required following a recipe by rote. Building the system took a long time and was done infrequently, as it was a bottle-neck. This was not an area that people were drawn to pursuing – it was rather a career dead-end.
The build systems themselves tended to be a hodge-podge of scripts and tools, that had grown by accretion over the years rather than being designed and architected. Technologies ranged at best to Make and its derivatives, usually with a wrapping of batch or shell scripts or some Perl duct tape, and a large sprinkling of manual build recipes. This became particularly prevalent with the rise of technologies where the IDE seemed to be the only way to get repeatability.
The Emergence of Builder Erectus
There is strong evidence of this new species arising back in Neolithic times when research for silver bullets was proving difficult. However, the new species had a hard time and existed only in pockets where the habitat was particularly conducive to its survival.
The rise of more iterative methods started to stretch bad processes and systems to breaking point.
- The more frequently you do builds, the more obvious it is that the build process and system isn’t working well and is being a bottle-neck.
- If you can’t build it reliably and repeatably you can’t get your release out the door.
- Different build processes for individual developers and integration or system builds leads to lots of problems and unreliable integration cycles with plenty of delays at the worst moment (as reported by Builders from the tribe of Murphy).
Fossil evidence of Builder Erectus becomes much more noticeable in the era agilis:
- The more often you build and release the more incentive there is to improve it.
- You can’t do continuous integration if there isn’t a simple automated way to do your builds
- Spreading knowledge through practices such as paired programming amongst the whole team results in spreading knowledge of building practices too.
And this leads to the rise of the most advanced of the species:
So what are the attributes of this new species? Research identifies the following – they are:
- Lazy – they want to automate as much as possible so that they don’t have to do it manually. It’s amazing the incentive of not having to work late every time a release is required. In addition, they are prepared to train and educate the developers to ensure that Private Builds and other such exotic patterns are easily achievable and can be done with little or no support.
- Organized – if the worst comes to it, they can do manual steps or ensure that they are done in a repeatable and timely fashion (by appropriately incentivised Elbonian serfs if necessary)
- Intolerant - of bad build practices and seeks to change them!
- Creative - in finding solutions - where necessary can build a mnemonic circuit with stone-knives and bearskins
- Pragmatic - knows when to live with a less than perfect solution
- Technically competent –