More on the last bug

Continued from previous post "The last bug"

From Chapter 1:

Excerpt
...finding nitty little bugs is just work... So testing drags on and on, the last difficult bugs taking more time to find than the first. (page 9)

This seems like a good spot to include a passing note about scrum-style, Agile development. I've heard colleagues make claims about how schedule problems are solved by Agile because you plan and test the product out as you go. (Admittedly a gross over-simplification, but adequate for this purpose.)

I'm not a big fan--partly because it's often touted as a cure-all that can cure for cancer, solve world hunger and lead to world peace. (Brooks will discuss the general phenomena of programming cure-alls in the silver bullet chapter.) On less contrarian grounds, I'm not a fan because I've seen it improperly applied with very poor results. But, to be fair, I've also seen it applied with very good results.

From my perspective the good thing about Agile the incorporation of the iterative/incremental style of development that has been in use since the late '80 as Objectory and later as the Rational Unified Process. The unfortunate thing about Agile is that it deemphasizes the upfront planning. The result is a highly-tactical decision process that makes it impossible to predict what will be in the final package.

Probably the worst thing about Agile it that it invokes a 'true-believer' mindset that is intolerant of deviation from the creed. This sort of orthodoxy gives rise to all sorts of pathological behavior. For example, I know of a team of very talented team of programmers who subverted an Agile process in order to ensure the task had a long range plan that would produce the product promised to the customer. Call it a reverse Faustian strategy.

On the plus side, Agile seem very constructive for tasks where the architecture is very well understood and the design decisions happen on the edges of the core system. For example, an e-business application. However, for the development of new infrastructure or embedded (i.e. control system) applications, the lack of a clear vision will likely lead to considerable rework, schedule slips and budget overruns since the progress to the end will be a random walk.