David M Williams
Sunday, 19 July 2009 20:03
Opinion and Analysis
Page 2 of 3
The problem of managing software development, then, he continues, ought not to be about such tight control and metrics as software engineering would stipulate. Instead, software teams should work on projects that deliver genuine value and managers need to reduce expectations for how much they will be able to control the project.
I’m assuming DeMarco’s first suggestion above is aimed more at the business leaders or analysts who determine a software solution is required rather than the developers tasked to code them.
The average corporate programmer doesn’t have the luxury to pick and choose what they work on, but it does stand to reason executives should put effort into determining the quantitative and qualitative return a project can deliver prior to committing resources.
It is unsettling to hear a father of software engineering effectively tell people to relax and not be so hung about how much software costs or how long it takes.
DeMarco defends this by considering teenage children as an analogy. How do you apply the sentiment, “You can’t control what you can’t measure” to a teenager? How does a good parent genuinely measure their offspring’s ethics, discipline and kindness, for example?
In this instance you can’t “control” the human “project” of raising a productive member of society. Instead, you manage the people and control the time and money. Fundamentally, you need to steer as best you can with little metric feedback.
In the same way a software team ought to go about incrementally adding pieces to the whole of the project in order of relative value, documenting and testing as they proceed, ready to package and deliver the product at any time the project manager dictates it is finished.
DeMarco says it still makes sense to engineer software, but that’s not actually what the term “software engineering” has come to mean. It’s a set of disciplines, processes, inspections, metrics, planning, tracking and many other elements.
For decades teams have been torturing themselves over budgets and deadlines but this never should have been the supreme goal.
The more important goal is transformation, DeMarco now says. It is more important to genuinely transform the world or a company or how it does business.
Almost repenting for decades of striving to apply engineering principles to software DeMarco says that transformation “is where the focus always should have been.”
To my mind, DeMarco is right when he says the practice of engineering software is different to the phrase “software engineering.” Indeed, there are many who doubt software really is an engineering practice which rightly has measurable and manageable controls. Instead software, without roots in a hard science like physics, will always be full of abstractions and ethereal conceptions and even experimentation.
Some of my greatest memories of my career involve the dramatic transformations my solutions have had on companies. I mean that with complete modesty; what I had developed was not special in technical terms by any means. Yet, the effect they had on the company was remarkable and will never leave me.
