The Skeptical Methodologist

Software, Rants and Management

Software Engineering Is Dead

Long live Software Engineering!

The exalted Father of many of the processes we know and lovehate, Tom Demarco, recently wrote an article describing his second thoughts on many of his prescriptions from his book, Controlling Software Projects: Management, Measurement and Estimation.

Much of what he says should ring true to most of us in the trenches.  Attempting to code directly to software metrics is a fools errand.  Not only do the current methods of collecting metrics frequently have relatively high costs to true value, but they also cause a game of metric cat and mouse where software increasingly fits what metrics say ‘looks good’ but loses all qualities associated with those metrics when developers begin coding ‘to’ the metric.  It’s basically teaching to the test!

It’s refreshing to see such an intellectual giant in our field so humbly admit his faults in the past – surely many more could learn from him.  We’ve had far too many methodologies come and go while their authors seem to continue to pretend that the few good ideas encased within those methodologies are worth all the cruft that’s built up over the years.  Just like in many cases what a software project needs is a complete gut-job or rewrite, some methodologies could use the same.

Let’s not throw out the baby with the bathwater though.  I’m convinced that nearly every ‘fad’ that’s appeared in the field of software HAS had some valuable things to teach us.  It’s all about keeping the good and dismissing the bad, separating diamonds from the rough.  The Waterfall method as a whole has shown to create projects drastically over schedule and over budget, but it has shown that many of our most expensive errors come from misunderstanding requirements/use cases.  Likewise, coding to metrics in and of themselves is going to get us no where.  It’s like writing until Word’s language analyzer gives me back a high ‘reading level’ for my paper.  Word can’t analyze the content or tell whether I used the English language correctly.  But, all other things being equal, these metrics – when combined with sound human judgement, can make our jobs easier.

If I’m brought on to a failing project as a firefighter, I want to know where the flames most likely are.  I can either slowly and methodically scan over the code with my own eyes – most likely spending weeks chasing false positives or style issues (even the most disciplined of ‘real’ developer is going to confuse style with content every now and then), or I can use a host of automated metric gathering tools to give me hints on where to start.

A few object oriented metrics, like various definitions of coupling and cohesion, probably would give me a good clue on where to start refactoring for maintainability.  Some good old basic metrics like line count per function or cyclomatic complexity may give me some good hints on where I ought to start tearing apart some unreadable or stagnant code.  Simple metrics like test coverage and test count would give me an eyeball figure of how brittle I should expect this code to be.

The point is, metrics in and of themselves say nothing about software quality.  When interpreted by a skillfull developer, they make that developer that much more useful and productive.  Since, as I’ve mentioned before, Amdahl’s law says as much about software projects as it does about software itself (namely, that any particular ‘solution’ a software product is to solved has an optimal number of different ‘threads’ of production, and any developers working on the project in addition to that will actually slow it down due to communication overhead), assuming we have an optimal number of developers, the only way we can speed up projects is to actually increase the speed of each individual developer rather than adding more.

But this is the rub, isn’t it?  In fact, hasn’t this always been the rub?  No one ever said metrics were all you needed, but it was in fact a misinterpretation by PHB (pointy-haired bosses) that we could automate and more easily manage software development with these metrics.  A hammer will allow a craftsman to do a lot more work than his hands alone, but also allow someone unskilled to do a lot more damage.  While the point that software is a people problem, not an engineering problem, is beyond the scope of this blog post, perhaps DeMarco’s later focus on the people problem and now his disemphasis on the ‘engineering’ problem will help the community lurch (ever so slowly) towards really understanding how to build software.


July 19, 2009 - Posted by | Uncategorized

No comments yet.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: