I always enjoy reading Mark Gregory Turansky's blog. Even if the topic is of no immediate interest, I'm always led to something new. His latest post led me to reading Fred Brooks' No Silver Bullet: Essence and Accidents of Software Engineering. Brooks, of Mythical Man-Month fame, writes about the difficulties of software, dividing them into essence and accidents. Software engineering is hard, and while some advances have eased/removed some accidental difficulties, software remains inherently difficult. There are no silver bullets that will remove these inherent difficulties and consequently an order of magnitude increase in productivity is not possible.
It's an interesting read and I concur (hard not to). That is why whenever someone says or implies this methodology (e.g., Agile) or this practice (e.g., unit testing) will result in software projects finishing in less time and/or of higher quality I tend to be very skeptical. Just the other day I read a study that compared a TDD project versus a tradtional project and how the TDD project completed earlier and had less defects. That may be factually correct, but to attribute it to TDD (the implied silver bullet) makes me roll my eyes.
It should be pointed out that No Silver Bullet was written in the 1980s. So in 2009, where do things stand? For this answer I found an article on InfoQ that summarized an 2007 OOPSLA panel discussion on No Silver Bullet. Some interesting points were discussed. Here are a couple which hit close to home.
Take the agile community for instance, I mean they are so cute, they run around talking about how to get rid of heavy weight process, then they forget there’s a whole group of people now who don’t really understand what agile is about.
I don't have the clout to make such a statement, but I'm glad someone who does made it. I admit, I have no idea what Agile (capital A) really means. People/projects/teams seem to love announcing that they're "Agile" but I swear no one on the team really knows what exactly is Agile, except that it's not waterfall. I really do think that only 100 people in the world truly knows what Agile is, and probably half of them work for the VersionOne marketing department.
The best way to get software components is to stop people build software frameworks, where they let the raw material leak out with all the encapsulation violations and complexities of frameworks. One of the big mistakes we made, I believe, is encouraging people in building frameworks and shipping them. Frameworks are the best way to ship something that is unfinished and is not professionally polished.
Whenever I hear the word framework I want to scream "serendity now! serendity now!" Frameworks are notoriously difficult to get right, but people love building them. Maybe because it looks good on your resume. I remember at my last job, during a meeting, someone said, "yea, Tinou built a framework for processing those requests using queues..." I cringed (it wasn't a framework). I've seen frameworks built that do very little, then another framework is built on top of that. By the time working code is shipped there's five frameworks involved just to do one simple thing. But hey, now we have (incomplete) frameworks if we ever need to do that simple thing again.
Returning to Agile for a bit, I did watch a presentation on how humans are agile in that we are wired to work in cycles. We sleep in 90 minute cycles, we work our best in 90 minute iterations. We don't consciously multi-task well. I've been telling my boss this for months but can finally point to some empirical evidence. Juggling a bunch of things is often seen as a great accomplishment. Unfortunately, when you're mult-tasking you're not very productive.
EOR (End Of Rambling)
Comments