Blunder Dome Sighting  
privacy 
 
 
 

Hangout for experimental confirmation and demonstration of software, computing, and networking. The exercises don't always work out. The professor is a bumbler and the laboratory assistant is a skanky dufus.



Click for Blog Feed
Blog Feed

Recent Items
 
Patterns: Starting in the Meta-Middle
 
Without Context, Every Open-Format Standard Is the...
 
Second-Guessing Microsoft on ECMA: Shape-Shifting ...
 
Lining Up Open Formats for Office Documents
 
Open Standards are not Open Source
 
Steve McConnell Beyond Myths of Rapid Development
 
The Distraction of User Personas?
 
Magical Thinking and the Universal Document Elixir...
 
My FUD is FUDDier than your FUD, so FUD this!
 
Agile Scope-Creep and How to Detect It

This page is powered by Blogger. Isn't yours?
  

Locations of visitors to this site
visits to Orcmid's Lair pages

The nfoCentrale Blog Conclave
 
Millennia Antica: The Kiln Sitter's Diary
 
nfoWorks: Pursuing Harmony
 
Numbering Peano
 
Orcmid's Lair
 
Orcmid's Live Hideout
 
Prof. von Clueless in the Blunder Dome
 
Spanner Wingnut's Muddleware Lab (experimental)

nfoCentrale Associated Sites
 
DMA: The Document Management Alliance
 
DMware: Document Management Interoperability Exchange
 
Millennia Antica Pottery
 
The Miser Project
 
nfoCentrale: the Anchor Site
 
nfoWare: Information Processing Technology
 
nfoWorks: Tools for Document Interoperability
 
NuovoDoc: Design for Document System Interoperability
 
ODMA Interoperability Exchange
 
Orcmid's Lair
 
TROST: Open-System Trustworthiness

2006-01-09

 

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.

 

 
Construction Structure (Hard Hat Area) You are navigating Orcmid's Lair.

template created 2004-06-17-20:01 -0700 (pdt) by orcmid
$$Author: Orcmid $
$$Date: 10-04-30 22:33 $
$$Revision: 21 $