Understanding Sunk Costs

James Robertson had quote on how often huge failed projects continue under their own momentum:

“A week after the primary election was plagued by human error and technical glitches, Maryland Gov. Robert L. Ehrlich Jr. (R) called yesterday for the state to scrap its $106 million electronic voting apparatus and revert to a paper ballot system for the November election. “When in doubt, go paper, go low-tech,” he said.”

On the other hand, the legislature is in the classic IT management “We spent all this money!” mode:

“We paid millions. These are state-of-the-art machines,” said Miller, who called Ehrlich’s announcement a political ploy to energize his Republican supporters.”

Sigh. Politics, IT – there’s very little difference. After enough money gets spent, no one is willing to admit just how bad things are. Better to just go along, and pretend it’s all fine.

No one likes to admit they made a mistake, especially a multi-million dollar mistake. Thus we have instances like this.

The crucial mistake is not understanding sunk costs. Once you’ve spent the money it’s just gone. If the project you’re running produces no software or badly broken software then yes you’ve wasted the money. The brave thing to do is admit things have gone badly wrong and start over. Far too often we just soldier on wasting millions more until finally someone points out that the emperor has no clothes and cuts off the funding. It’s how we get so many classic death march projects.

And on a related point I worked on an electronic voting project for a county government about 9 years ago. There were some minor bumps when they were first rolled out, but we always had a paper receipt. I’m still shocked that they started producing machines that didn’t have some sort of hard copy. And before that we had classic punch card voting. Hanging chad was a well known occurrence because there were always a few mainframe developers who were paid overtime to sort through the rejected punch cards.

Office to Team Room Complete

I realized today my former office has officially become a team room. One of my employees came by to talk and I had to guide us to another meeting room because an ad-hoc meeting had started after one team’s daily meeting. Feels like a lot better use of the space.

Agile Lite to Agile

Today our Agile Lite project was officially voted in as an Agile project. Proof that persistence pays off after about 6 months. The project has always been a Scrum project minus colocation, and we were always forced to pretend it wasn’t an ‘official’ Agile project. In this case official refers to getting the blessing from the PMO.

Semantics aside I think we’re getting closer in our organization to assuming Agile/Scrum as the default methodology unless there’s some overriding reason to do things differently. That’s some progress.

TDD Next Year

I had two major practices to put in place to improve our overall software development for this fiscal year.

  1. Implementing Test Driven Development with a target of 70% unit test coverage.
  2. Implementing frequent, lightweight code reviews.

Easy enough, on number two we’ve been fairly successful and will continue to tighten things up over the next year. Crucible has proved to be a good lightweight tool to help enable this.

On number one I suspect we’re at the same place a lot of development shops end up especially if they aren’t already XP shops. We’re doing a bit of TDD, but the bulk of the unit tests are written after the code sometimes days or weeks after the code. Thus we lose a lot of the design benefit. As a bonus it feels more like a chore when you write the tests later.

On a positive note, we’ve come a long way and the developers see many of the benefits of having a good set of tests around your code. And all pretty much all of the code developed this year had 70% or greater test coverage.

Next year is likely to see another goal of going from unit testing to TDD.

Google TechTalk Videos

I’ve watched a video of Dave Astels on BDD at Google in the past, but Kane Mar recently pointed out a Google talk by Ken Schwaber on Scrum. Doing a search for Google engEDU reveals about 150+ talks. When I get some downtime I’m going to look through a few of them.