Blunder Dome Sighting

Professor von Clueless in the Blunder Dome

status 
 
privacy 
 
contact 

Monday, January 09, 2006

Agile Builds: Making a Bad Idea Efficient?

ACM News Service: Will the Build Bottleneck Put the Brakes on Agile.  This old clipping (I’m doing a little catching up) reminds me of a problem I am noticing with software tool sets, SDKs and libraries, and understanding the dependencies in software.

The Geoff Koch 2005 August 15 SD Times article (commercially-sponsored .PDF download here) is looking at the problems that may happen if agile development methods runs into a daily build bottleneck.   There is an innate desire for faster builds so that new builds of complex, multi-component systems can happen at least overnight, not over weekends.   This is clearly a good thing for coordinated testing and refinement on a common daily base.  

The article has a great visual that illustrates James Van Riper’s solar system of builds:

  • dozens of developer builds per day taking no more than coffee-break time,
  • continuous integration builds for getting changes into a build and confirming that there’s no breakage by performing a quick smoke test,
  • then nightly builds for rebuilding from the entire code base,
  • and finally milestone builds for QA turnovers. 

In all of this, the faster and more automated the build the better.  Bottlenecks introduce programmer wait times and that burns useless development dollars.

There are some useful tips from Mike Clark, including the use of RSS feeds that provide continuous build output: the developer’s stock ticker.

My one reservation about this rush to have faster and faster builds is the degree to which we are allowing builds to become terribly complex and then relying on faster tools to save us.  My classic example of this is the investment in Visual C++ compiler performance simply so the windows.h preprocessor nightmare (and each Visual Studio’s new preprocessor burdens) are mitigated by Moore’s law and compiler-system cleverness.  I am dismayed to see how this infectious tendency has managed to make a mess out of even the Standard C++ Library header files between the VC++ library of Visual C++ Toolkit 2003 and those of the Visual C++ 2005 Express edition.  I quake at what we are teaching programmers to tolerate and perpetuate. 

My concern is that we are operating atop a quagmire of unmanageable dependencies and misplaced optimizations.  Instead of sweeping it all under the rug, getting atop code dependencies and modularizing the components might be a superior way to have faster compiles and builds while gaining understandable integration dependencies too.  Sometimes, instead of more-bigger-faster, the thing to do is step back and find a smarter, simpler way to organize the work and the technical tools that support it.  I wonder if we are missing out on that score.  With so much attention on getting the greatest code-test-rinse-repeat time out of developers, I fear that we are rushing into a very ugly “you can pay me now or you can pay me later” experience.

 

 
Comments: Post a Comment
 
Construction Zone (Hard Hat Area) You are navigating the Blunder Dome

template created 2004-06-17-20:01 -0700 (pdt) by orcmid
$$Author: Orcmid $
$$Date: 06-02-04 21:31 $
$$Revision: 1 $