Fanatical About Build Published 8th Apr 2014

The build process is the most commonly overlooked aspect of complex software development projects.

There's a big difference between coding and software engineering. Engineering as a work conjures up impressions of solidity, reliability, safety. From the engineer who fixes your washing machine or broadband, to the engineer who designed the train you came to work on this morning and all the bridges and tunnels it travelled through, there are many people who use this title professionally, and what they have in common is that their job is to make something that works. When they finish their job, you the consumer / client should left with something that works reliably, without further intervention, for a significant and predictable period of time.

Software is an engineering discipline, but an odd one. The weird thing about software engineering is that there is no factory, no building site, no logisitics. The manufacturing process, the process of turning a design into the finished product, is more-or-less instantaneous, and the cost of re-making the product in an entirely different form is tiny. Instead of producing drawings, prototypes, numerical models of the end product, software engineers build their product over and over again in the course of developing it.

The shop floor worker of the software engineering project is the Developer, someone who develops code. This is a curious term - who 'develops' a wall? The developer is responsible for writing the source code for the product, but they're not building the product, not manufacturing it, merely developing the rough design that the project started with, refining it from the sleek curves of the architect's model into the unarguable dimensions on the blueprints, the size and strength and composition of every component which, when assembled, will be the product. The cost of manufacturing, of building the product, is so small that typically any change to the source code will be verified by actually building and then testing it, and this might happen dozens of times in a single developer's working day.

Now what was I saying about the manufacturing process being free? Unfortunately, the fact is, it's not. Sure, it's a lot cheaper than building a skyscraper or even a toaster, but remember that the critical path between a developer completing the design of a feature and being satisfied that it works involves a trip through the manufacturing process, in order to build something that can be tested, so the manufacturing (or 'build') process needs to be unusually fast and reliable, of the order of seconds and minutes, not months and years. Where a software product involves deployment of things like databases, web services etc, this cost can extend to days.

Time spent waiting for a build is time wasted. If the time it takes a developer, having completed the development of a feature as best they know, to verify that it actually works, is in order of hours or more then it's a serious drain on productivity. Not only that, but it starts to nudge people's behaviour. More on this in another post.

If you have experience of working in large software development teams, and this sounds obvious, then I agree with you - it is. However, when a project comes under pressure, when features balloon in complexity and deadlines loom, what are the most common responses from project leaders?

  1. "Quick, let's hire more developers!" - to get the work done quicker?
  2. "Quick, let's hire more project managers!" - to keep better track of how far we've got?
  3. "Quick, let's hire more testers!" - to maintain quality as working hours lengthen?
  4. "Quick, let's hire another build guy!" - yes, there's probably only one on the team, if you're lucky...

If your answer is anything but #4 then you're probably about right. The fact that the fourth role doesn't even have a name is enough to point out that it's undervalued or even unnoticed in a lot of projects, but if software aspires to achieve the quality and reliability routinely expected of other engineering disciplines, it needs to pay more attention to how the design becomes the product. A development team will only achieve its potential if it's Fanatical About Build.

blog comments powered by Disqus

Our assets

Our assets are unique and allow us to accelerate anything we do, supported by an exceptional combination of people, software products, project tools and methodology.