Essentials of the Build Process

"I want it just like  that one but with these changes" instead of "Here are the complete plans for  my house".  Both will work, but in the former case we might say:   "Let's bring the team in that built 'that' house".

What's in a  Build
This leads us to a fundamental requirement.  Although it  matters less how you track a build (i.e. baseline + changes + options  vs  new baseline), it is crucial that you can look at two builds and ask:   What new features are there? What problems were fixed?  How does it  differ from what the customer currently has?  What level of retesting is  necessary?  The Sikorsky S-92 helicopter was grounded with a requirement  to replace the titanium studs in the gear box mounting with steel studs.   No new baseline has to be established to correct the hardware.  But a new  build definition is needed for new craft.  It may be due to a new  baseline definition, or to an revised build process that says apply the  following changes to the existing baseline.

The important thing in any  case is that we can ask: what's in this build that's not in that build. I like  a CM tool where I can take the customer's current build and then compare  it  interactively to various candidate delivery builds, just by scrolling  through the candidate build list and then zooming in on the differences list  for details.  If instead I have to commission a team to describe the  differences between every two builds, I've got a working, but painfully slow  process.

Comparing builds is not just necessary for releases.  If  a key feature is noticed to have stopped working and I know it was working a  month ago, I want to trace the changes build by build to see what  functionality potentially impacted the feature.  The more easily I can do  this, the better.  Traceability and zoom-in are critical.   Similarly, these features will come in handy if a customer notices that  something has stopped working.  The ability for an orgainization to  respond the same day, as opposed to days or weeks down the road, will make the  difference between a happy customer and one that might be ready to take you to  court.

Getting There
Your current build process  may be far from ideal.  But if you can describe where you'd ideally like  it to be, you can get there.  There are numerous tools to help. There's plenty of expertise available.  The demand for quicker turn-around continues to grow, especially as competitive pressures continue to  squeeze profits. Make sure your processes are moving to the next  generation, and if they're already there, keep on moving.

About the author

Joe Farah's picture
Joe Farah

Joe Farah is the President and CEO of Neuma Technology and is a regular contributor to the CM Journal. Prior to co-founding Neuma in 1990 and directing the development of CM+, Joe was Director of Software Architecture and Technology at Mitel, and in the 1970s a Development Manager at Nortel (Bell-Northern Research) where he developed the Program Library System (PLS) still heavily in use by Nortel's largest projects. A software developer since the late 1960s, Joe holds a B.A.Sc. degree in Engineering Science from the University of Toronto. You can contact Joe at farah@neuma.com