My friend Hernán Wilkinson sent me a link to a blog post that included a reference to
My friend Hernán Wilkinson sent me a link to
a blog post
(Spa) that included a reference to a very interesting article by
Tom DeMarco
, one of the classic authors in
Software Engineering
. When I studied systems analysis more than 20 years ago,
his book on Structured Design was like a Bible.
I agree with almost everything he says there, but still, I think that he takes it too hard against his own work, and I want to relate this to my previous post, because what he proposed in “ Controlling Software Projects ” is something that even in 1982 didn’t work in all software development projects , although from what he says it looks like he didn’t realize that at that time
But the key is that they worked in many software projects: in the types of projects that DeMarco was involved in then. So, probably his mistake was not to mention in what types of software development projects the techniques he was proposing had proved to be effective or were important in relation to what they were trying to achieve.
Also, it is easy to say now that some things proposed 27 years ago are not true anymore. Just as an example, “ The Mythical Man Month “, Brook’s classic essays book that is a must for any software professional, has many things that are plain wrong if tried to applied nowadays, as Brooks himself recognized when he said “ Parnas was right, I was wrong ”.
So, why are so many things that were once right now wrong? Here’s a possible reason: For 40 years the software community (academia and parts of Industry) has been struggling to produce technologies to let us build more flexible software.
David Parnas and the initiators of the Object Oriented Community (like Alan Kay) had a lot to do with this. New development environments, debuggers and configuration management tools also produced great improvements. Increase in processing power also made a huge difference.
The funniest way of showing this is what Boehm recalls that his first boss told him when he was a programmer: “ Now listen. We are paying $600 an hour for this computer and $2 an hour for you, and I want you to act accordingly. ” But now that software is easier to change, the models that we strived to produce that were easier to change than the software itself have changed their cost-benefit equation.
The other side of this coin is that the “increasing cost of fixing errors” curve is more flat now than a few years ago (not for the case when a bug is found in a production environment, though). So now the methodologies we use are a bit closer to a “code and fix” development life cycle. Now… does this imply that code and fix is right? Does it imply that it was right 10 or 20 years ago? The answer is no in both cases, but the second no is stronger than the first one.
Does this imply that it was always wrong to invest a lot of effort in software models? No! And does it imply that it is wrong to build models now? Another no! But maybe today there are fewer cases where a significant investment in models is justified. The same can be said of other techniques, like the need for “ measures and control ” that DeMarco pushed for when he said “ You can’t control what you can’t measure ”, although he is right in that maybe there was too much a focus in management as a reaction to missed deadlines , and that now software engineering should concentrate on the more technical aspects of building software.
Our discipline is immature and a moving target. Our tools, techniques, and methodologies differ from project to project, from domain to domain, from company to company. And they change over time. There are a few universal truths that affect everyone: those are the ones that Brooks mentioned in “No Silver Bullet”. That’s about it.
I wanted to conclude by saying that the authors of the Agile Manifesto did an extremely good job by choosing the words: “We are uncovering better ways of developing software” to start the manifesto. Old technologies and paradigms, missing tools, and lack of processing power among others were covering those ways of developing software. So some things we did then seem evidently wrong now, but in many cases they were not, and DeMarco should still be proud of his work.
Comments? Contact us for more information. We’ll quickly get back to you with the information you need.
