People vs. Process

Submitted by Larry on 3 June 2007 - 4:51pm

I am a regular reader of TheDailyWTF. Aside from being thoroughly entertaining, it's a great way to learn what not to do by example. Sometimes, though, they have a really insightful article, like The Great Pyramid of Agile. It's spot-on.

It's not that Agile is useless. There's plenty to be learned from a "baby steps" style approach. But there's also a great deal that can go wrong if you don't have the right mind-space for the entire project when you start. You'll forget things that matter only when you are done, but have to be done from the start. (Memory optimization? Synchronization? Code loading time for non-opcode-cached PHP? Locking under high load?)

To be sure, business logic will change part way through the project. It always does. Plan for that. But the way to plan isn't to try and turn a log cabin into a wood house into a brick house into a steel skyscraper. That sort of business logic simply can't change on the fly, and if you find you need to then it means the project manager screwed up somewhere along the line.

Instead, you need to find the right foundation so that you can shift the innards around easily without breaking anything, then stand firm when (not if) someone suggests the foundation change. Design the interior walls to move around easily, sure, but that requires really strong and unmoveable supporting walls and a poured concrete foundation. Get that wrong at the start, and no matter what you do it's still going to suck when you're done.

That means you need the right people figuring out what that foundation is from the get-go. No process (Agile, OOP, test-driven, whatever) can substitute for someone who knows what they're doing. Ever.