Diagnostics, Problem Definition and “House”

There was a “House” marathon a couple weeks ago, and I caught a bit of it while working on some projects around the house. As I watched it became pretty clear that every episode is built around solving a complex medical problem. And 90% of the show is spent learning about the problem, finding new pieces of information, and testing incorrect assumptions.

I think this is a pretty good description of lots of a lot of projects I’ve worked on as a software developer and project manager. Lots of Software Developers want to get the “Problem Definition” done as soon as possible, and get on to the “real work” of solving the problem. But there’s real danger there, it’s easy to define and solve the wrong problem.

I like the system they use in House — there’s a central whiteboard which contains a description of the problem they’re trying to solve. As the show progresses, the problem definition is continuously updated, and the diagnostic team comes up with various theories. I’ve worked on projects where we the developers didn’t have a clear understanding of the problem, or where our understanding of the problem was months and months out of date.

The result was that we built the software that solved the wrong problem, or in the best case, software that solved the right problem in the wrong way. Either way, what we built fit the user stories we got for that iteration, but wasn’t “well designed” in terms of solving the core problem. In both cases, it was very clear as I talked to the end users after the project was completed, that we could have spent less time, and built better software if we’d just had a clear and up to date picture of the client code.

I think a problem definition whiteboard is a great addition to the standard Agile software system, and I’ve started thinking about how to integrate this into all the projects I’m working on.

I think this is particularly important for Open Source projects with a distributed team, so I’d like to integrate this idea with the TurboGears 1.1 development process. I’ve posted Alberto’s 1.1 roadmap on the Docs wiki (docs.turbogears.org) and I’ll try to keep that as up to date as possible, and to add a very clear problem definition to the top of the roadmap.

4 Responses to “Diagnostics, Problem Definition and “House””

  1. 1Tom Weir

    Apparently their methodology is called “Differential diagnosis”

    In my experience, a virtual status whiteboard is a very effective way to keep small teams in sync.

  2. Agreed! We already used one, the new bit is just keeping the problem definition front-and-center on the whiteboard.

  3. I am working with your book
    and on page 52 setting up for nosetests
    “from turbogears import testutil”
    Testutil.py is not present in the recent version of TG. and looking on
    the net I find many different versions
    the several I tried are incomplete.
    Where do I get a copy of testutil.py that you are mentioning?
    Thanks Dave

  4. Ah yes, my problem was with
    ‘yum install TurboGears’
    on Fedora gave an out of date version
    of TG.

    Thanks anyway.

Comments are currently closed.