The Origins of Software Engineering Economics — You are Ron Turcotte

Dietrich Kappe, Sunday, April 5, 2009 @ 1:16 pm

Between the idea / And the reality / Between the motion / And the act / Falls the Shadow. -- T. S. Elliot

We have a particular way of developing software. We practice it until we're like the Harlem Globetrotters and your software project is like the New Jersey Generals -- defenseless against our iterative, pair programming, test and user experience driven weave. We didn't just happen upon this approach haphazardly; rather, we evolved it through trial and error and shameless adaptation of other software developers' ideas. It represents our answer to a number of the critical questions of software development. Three of those questions (that you'll hear us refer to over and over again) are:

1. If bugs get more expensive to fix the longer it takes to identify them, how do we catch them as quickly as possible?
2. If most bugs in a mature application are caused by missing or unclear requirements, how can we close this communication gap?
3. If 50%-70% of the cost of most software is spent in maintenance as opposed to the original development, is there a way to spend a little more up front to improve that ratio?

So where do these nuggets of software development wisdom come from? From a Software Engineering Classic called Software Engineering Economics by Barry Boehm. Like most of these classics, such as The Mythical Man Month,  its findings and advice are widely accepted yet honored mostly in the breach. Yet its empirical findings about bugs, maintenance costs and unclear requirements still govern most of what makes the software development landscape so treacherous for product managers.

Our answers are a little different than the ones that were proposed in the 80's and 90's. Rather than advocating an exhaustive specification before development can begin, we are firm believers in a rapid feedback loop that exposes working software to clients and customers as early as possible. The primary gap in requirements is not between the client and the developers (although that is also a common source of problems), but between the idea and the reality, between the paper and the real system. The sooner we move from paper to product, the less chance the shadow has to fall.

Constant, automated testing, from unit tests to QA tests, further reduce the number of bugs that can slip  through and also reduce the cost of maintenance by providing a backstop for maintenance programmers who may have misunderstood the code.

We live these rules of software economics every day. Every so often we get a client that believes that these rules don't apply to them, who sees unit testing as wasteful or quick iterations as risky compared to exhaustive specifications. Then it's usually a race to see whether we can convince them otherwise, or whether the cost of the project will overtake their budget. For those of you at the helm of a professional and experienced software development team such as one of ours: take their advice. You are the expert in your business domain, they are the experts in theirs. Just as they would not presume to tell you how to run your business, don't presume to tell them that their collective experience is wrong. You are Ron Turcotte, riding Secretariat in the Belmont. Provide the business expertise, furnish vision and direction to the product development process, then hang on tight and don't fall off.

Related posts:

1. Are We Engineering Software or People?
2. 800 on Your Math SAT, Software Development and Bugs
3. Agile Development for Product Managers: Why Agile Testing Rocks
4. Digging a Hole and Covering it with Leaves — The Software Development Version
5. You’re at the Software Development Finish Line! …. or are you?

Comments (1)

Software Development

Comments: 1 so far

• Leave a comment
• Comment feed for this post
• TrackBack URL

1. [...] wanted to take a moment to try and make my point a little clearer. Bugs and estimation have been a hot topic with us lately, but interestingly we are all working on different projects and actually have a [...]

   Pingback by Agile Ajax » Bugs can’t be estimated » Pathfinder Development, Tuesday, May 5, 2009 @ 11:58 pm

Leave a comment