|
|
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.
Blog Feed Recent Items The nfoCentrale Blog Conclave nfoCentrale Associated Sites |
2006-01-09Agile 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:
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.
|
||
|
|
You are navigating Orcmid's Lair. |
template
created 2004-06-17-20:01 -0700 (pdt)
by orcmid |