The Goal of a Build

More and more, I feel that the goal of a build is very simple.  The goal is to provide a convincing illusion of done.  

Some people might disagree with my wording.  Illusion?  Isn't that something we should avoid?  But, the fact of the matter is that we are never done.  There is always one more test that we can dream up and run.  When builds pass, software goes into production.   Sometimes we find bugs.  We correct them.  Sometimes new features are needed.  It's all work.  We are never done.  

For an area of code, all we know is how long it has been free of defects.  Builds should help us radically shorten the amount of time it takes to find them.  In fact, in a high performance team, very few bugs should escape into production.  And, if they do, they should be found and repaired quickly.  

So, that is what a build looks like from a technical point of view.  But, there is another way of looking at a build.  When developers check in code, they need to get some sense of completion, and it's better when they get it quickly.  We could gloss this over and say that it is not necessary, but I think it really is.  Development is an attention-focused activity, and for me at least, a sense of closure is important for that focus and important for morale.  All of that evaporates with awareness of the long pipeline toward the eventual discovery of a fault.   At a certain point, I want to be able to say, "based upon what we know, we can consider this to be correct now", and I want that to happen as early as possible.

How can you get to that sense as the number of tests grow in a system?  I don't know, but subjectively, what I wish for is quality at a level where about 99% of errors are found with in minutes of commission.  I want to be able to call that done.  The remaining 1%, well, it may take a while to discover those, but as a developer, I don't want to have to have to think about those right away.  Spill them back to me in bug reports.  Pipe-dream?  Perhaps.  But I think there's value in a convincing illusion of done.

 

Comments

[Cody]

Very good explanation. The points were very informative. Keep posting more. Thanks!

[Peeja]

Here's another, equivalent way to think about it: A build is a formal definition of "done". It's not the same "done" that you might otherwise have. Your default "done" might mean "fully functional and free of defects". But that's not very useful. A build gives us a more useful definition for "done".

It's only an illusion with respect to the original meaning of "done". And that meaning of "done" was an illusion to begin with.

[Mark Knell]

Charles Duhigg has a recent bestseller, "The Power of Habit", which makes a case for why we might, as you put it, "need to get some sense of completion", and to get it quickly.

He writes for the NY Times and had a piece in the Sunday magazine around the time the book was published. It covers both theories of habits, and also some interesting stuff about datamining for consumer behavior. Really a good read.
http://www.nytimes.com/2012/02/19/magazine/shopping-habits.html

To take one example: there's a nice story in there about how Febreze was kind of a flop in its first formulation and marketing attempt. They positioned it simply as an odor remover--just another household chemical. Worse, the people who needed it most (people living with strong smells around the house) didn't purchase it, because they had merely adapted to the smells to the point they weren't even aware of their need. P&G pivoted, tweaking the formula (adding perfumes, so you could tell you'd used it) and selling people on the idea of Febreze as a finishing touch on a cleanup job well done. They baked it into their cleaning routine--their habits--and Febreze became a billion-dollar hit.

The book's larger point is that habits that lack a moment of reward and self-congratulations, promptly applied, don't stick. If true, then it's both a strong argument that--and a clear explanation of how and why--a build should give quick, confidence-building feedback.

Great post, as usual.