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.