What kind of developer are you?

Garbos of the world, Unite!

Hey Mark, Thanks for the comment on my blog and to return the favor I'd like to answer your question here. You asked, to paraphrase: What do you do when you uncover a truly horrible mess? It depends (like most things, eh?), for me, at what point in the lifecycle the mess was discovered. I believe all software is destined to become Big Balls of Mudd and exhibit the exact traits you describe *unless* course corrections are applied during the entire lifecycle. Now what do you do when you join a project where the rot has extended to the foundation? Look for the lifeboat, if I can be flippant and mix metaphors. Seriously, though, that is a difficult question to answer because it calls into question (at least in my mind) the project leadership, the customer's propensity to pay for the "right" answer, and the developer's commitment to quality. I would suggest, at a minimum, if it is not feasible to halt all work and regroup then build into the software, like adding structural supports, the correct abstractions and implementations. Easier said then done in the face of inertia and looming deadlines, I know. Dunno if that answers your questions. However, thanks again for the comments and questions on my blog. Cheers, Mel Riffe

by Unregistered Visitor on 06/03/07

Big Balls of Mudd

Thanks Mel. Classic Fowlerism :)

It's interesting you suggest halting all work. This project *did* halt, a year or so back, because it had blown it's time and budget without delivering even half the functionality (I can see why). It's interesting that at the macro level it was clear that there was a big problem even though the developers (of the time) didn't see it that way.

The half-functionality was pressed into use though, and it's become my job to shoe-horn a bit of extra functionality into it.

I like your concept of "structural supports" - it makes me think of making modifications to a heritage listed building. You know that the foundations are dodgy, but you can't just knock it down. So you build some external structural support to hold it in place while you work, and go about fixing the foundations/walls/whatever from within.

It's slower, in the end, than knocking it down and starting again. But in the case of a heritage building (or tens of thousands of lines of unclear and undocumented code) you don't have that choice because you could never reconstruct it. Another benefit of the structural support approach is that people get to keep using the building while you work on it.

But what does that mean in this context? Well, there's a nasty custom ORM layer (actually, three layers) that I could think of as the foundation. Perhaps I could temporarily sandwich an extra layer above that as a place to switch out the old ORM for a cleaner one, a bit at a time. When the work's done I can remove that support layer.

That's a specific example, but I think the structural support metaphor has legs (stilts might be more appropriate ;)

by Mark Aufflick on 06/03/07