The Renaissance Builder

This month we would like to turn the spotlight on to that oft neglected and under-valued specimen the build engineer. In the physical world, the term “building” has traditionally inspired status and respect. We just have to think of structures from the pyramids to medieval cathedrals to skyscrapers.

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

About the author

Robert Cowham's picture Robert Cowham

Robert Cowham has long been interested in software configuration management while retaining the attitude of a generalist with experience and skills in many aspects of software development. A regular presenter at conferences, he authored the Agile SCM column within the CM Journal together with Brad Appleton and Steve Berczuk. His day job is as Services Director for Square Mile Systems whose main focus is on skills and techniques for infrastructure configuration management and DCIM (Data Center Infrastructure Management) - applying configuration management principles to hardware documentation and implementation as well as mapping ITIL services to the underlying layers.

About the author

Brad Appleton's picture Brad Appleton

Brad Appleton is a software CM/ALM solution architect and lean/agile development champion at a large telecommunications company. Currently he helps projects and teams adopt and apply lean/agile development and CM/ALM practices and tools. He is coauthor of the book Software Configuration Management Patterns, a columnist for the CMCrossroads and AgileConnection communities at,  and a former section editor for The C++ Report. You can read Brad's blog at

About the author

Steve Berczuk's picture Steve Berczuk

Steve Berczuk is a Principal Engineer and Scrum Master at Fitbit. The author of Software Configuration Management Patterns: Effective Teamwork, Practical Integration, he is a recognized expert in software configuration management and agile software development. Steve is passionate about helping teams work effectively to produce quality software. He has an M.S. in operations research from Stanford University and an S.B. in Electrical Engineering from MIT, and is a certified, practicing ScrumMaster. Contact Steve at or visit and follow his blog at

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!