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.
Primeval Building
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:
Renaissance Builder
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 – they can deal with appropriate levels of detail whatever the technology that is thrown at them. They understand the important principles in terms of automation, repeatability and reliability and can adapt these to the job at hand. The intricacies of dependency calculations and parallel building techniques hold no fear for them.
- Politically aware (the sub-species of Machiavellian Builders) - they seek to influence decisions as to which languages and technologies are used, and ensure that the requirements of building and releasing are designed in from the outset.
Conclusion
This academic research on the rise of Renaissance Builder might appear to be wishful thinking, but is strongly supported by the increasing frequency of occurent of the title “build engineer” in job postings. We can’t think why this prosaic title was chosen in place of “Renaissance Builder”, but bow to the inevitable and just seek to encourage further evolution.
References
- Building for Success, CM Journal, Apr 2005 (Vol 4. No. 4), by Robert Cowham, Steve Berczuk and Brad Appleton
- The Importance of Building Earnestly, CM Journal, Feb 2005 (Vol 4. No. 2), by Steve Berczuk, Robert Cowham and Brad Appleton
- The Samba Build Farm - interesting example of "farming it out"
