Agile thought 41 years ago
Recently, Robby dropped off his copy of The New Utopians by Robert Boguslaw at my desk with a section marked: “For Whom and For What”. Here are a couple interesting quotes on page 45:
This, then, is one of the fundamental problems of application: on the one hand, the temptation is almost overpowering to establish the techniques and practices of practitioners as handbook truths available in situations of the sort we have termed established. It is the temptation to speak with the same degree of assurance under all professional circumstances as does the familiar stereotype of the TV repairman or journeyman carpenter.
On the other hand, there may be found equally strong temptation to revert to unbridled intuitionism–on the part of those who somehow sense the inadequacy of established situation science applied to emergent situation reality.
This reminded me of the recent blog exchange between Peat and Alex regarding the role of common sense and intuition in application development.
It is an attractive and beguiling illusion that attempts to persuade us to think that if we just apply enough analysis from correct principles, we’ll produce something “correct.” And we should do the analysis first. That pretty siren sings so sweetly over the shipwreck mess of many development projects. The allure is so powerful, of course, because sometimes it is correct. The problem is when to do this and at what scale.
Sometimes it is much better to analyze things first. Some people will say, “First make it correct, then optimize it.” But when speaking with Stefan Kaes at RailsConf 2006 after his talk, I thanked him for pointing out that some consideration for performance must be made up front. To paraphrase his reply, “Absolutely”. Here, the scale is large. Broad decisions are made, not detailed ones. And it is necessary to do it earlier rather than later because this broad decision will dictate the confines under which many small decisions are made that create a structure of significant weight that will resist change.
I was a bit disturbed to read this comparison of Tracer Bullet Development versus eXtreme Programming where it was asserted that TBD uses up-front design while XP does not. Obviously, using XP, you don’t just start randomly writing code. Somewhere, somehow a bunch of decisions were made that create the context in which you start writing tests. Disregarding appropriate situations at which to make preliminary decisions is as dangerous as deciding too much.
Even if we know extremely well the technical details of the small bits of test-driven code we are writing, it’s probably guaranteed that we have but a faint understanding of how those pieces will make a complete application. As Robert points out summarizing Kurt Lewin in “Field Theory and Learning”
In short, it is not … that the whole is more than the sum of its parts; it is different from the some of its parts
3 Responses to “Agile thought 41 years ago”
Sorry, comments are closed for this article.
August 29th, 2006 at 05:03 AM "...I thanked him for pointing out that some consideration for performance must be made up front." interesting contrast: http://www.butunclebob.com/ArticleS.UncleBob.PerformanceTuning Knuth said it 32 years ago, yet computer scientists far less skilled than Knuth continue to be seduced by the siren song of premature optimization.
August 29th, 2006 at 08:05 AM John, I'm not understanding your point. Perhaps you could elaborate. I said "consideration for performance", nothing about premature optimization. At the point I'm talking about, there is not even any code to optimize. I'm talking about high level architecture decisions that will influence the box in which code will be written. It's an illusion (or delusion) to say that such decisions are not being made. It's as silly to say that you can start out on a journey toward a place without any consideration for direction at all. Even if your first step is in any random direction, you'd better be taking your bearings before walking far or you could be wasting a lot of time. The longer the span between correcting your course, the more wasted time. Sometimes it's simple to look over to where you want to go and start in that direction. Other times you may have no idea. But in the latter case, you should hope to get better information at some point, otherwise how do you expect to end up there?
September 1st, 2006 at 11:24 PM I've always admired the work of Donald Knuth and I'm well aware of his famous quote on premature optimization. And he's absolutely right: premature optimization is evil. However, what most people seem to miss out is that the most important word in his statement is "premature", which is also the tricky part of this quote. If you don't give any consideration to performance, you will be sure to avoid premature optimization. But you might have made a design decision which simply cannot be reverted without huge cost at a later stage of the project. Let me give you an example: I once was asked to evaluate a project because it had performance problems. The software was intended to be used in a call center, which requires really fast response times. It turned out that the external company hired to implement this software, had made the decision to write the UI dialogs in a custom templating language, for which they had written an interpreter. The interpreter had been written in Visual Basic, which, at that time, was an interpreter as well. So in effect, the dialogs were running c1*c2 times slower than necessary, where c1 and c2 are the interpreter overheads. It's probably safe to assume the software ran about 25-50 times slower than necessary. And even top of the line hardware with 2 processors wasn't able to make the package run fast enough. In the end, the whole project was cancelled, after pouring a large 2 digit number of EUR into it. And the problem was solved by buying another call center wholesale. I still believe today that if some consideration had been given to performance questions during the architectural design phase, this desaster could have been avoided. So, yes, premature optimisation is evil, but no consideration for performance issues is just as bad.