"Are you doing XP-style unit testing throughout your project? You know, we even write the test code prior to the functional code on each and every method.", the recent hire (fresh from polytechnic school) insisted. "Leave me in peace", I said to myself, "I have real work to do". Two years later I asked him how he was doing. "You know we gave up on the eXtreme Programming approach. It just was frustrating. Oh, and our project was cancelled"
Please don't get me wrong, XP brought some exciting new ideas, and I really admire Kent Beck for the groundwork he has laid in this area. XP also shares several ideas with the proposal I will discuss in a moment. I just don't understand people who immediately jump on the bandwagon of the latest software methodology hype, each time something new comes along. Those folks don't act deliberately, they don't consider whether certain measures make or do not make sense in a specific project scenario, they don't challenge new approaches, they just blindly follow them. Why? I am not sure, but my theory goes that forcing their favorite methodology on other people within their tiny software development microcosm creates a boost on their low self-esteem.
So I am not going to force my favorite methodology on you. But maybe you are also tired of overly bureaucratic software engineering (you know, no line of code will be written until hundreds of pages of detailed specs have been approved by several committees), and eXtreme programming is just too, well, extreme for your taste. The proposal that comes closest to what I think software development should be all about is Agile Programming (you might want to have a look at Martin Fowler's excellent introductionary article). In essence, Agile Programming is people-oriented (requires creative and talented people), acknowledges that there is just not a lot of predictability in the process of creating software, and puts emphasis on iterative development and communication with the customer.
Here, your design document IS in your sourcecode. Software development is not like the building industry, that's why you cannot just draw a construction plan and hand it over to the workers (=programmers) for execution. Agile Programming embraces change (e.g. changing requirements - face it, this will always happen), and helps to react accordingly, thus avoiding the rude awakening after months of denial that you project is off track - the kind of awakenings that might happen as long as you can hide behind stacks of UML diagrams and project plans, but do not have to deliver a new software release each week.
There is not "One-Size-Fits-All", and I probably wouldn't use Agile Programming when building navigation software for the NASA. But many of the agile principles just make sense within the projects I work on (and I try to apply those principles selectively).
I also don't completely agree to the Agile Manifesto's statement #1 "We have come to value individuals and interactions over processes and tools". If they would just have left away the part about tools, it would have been fine. I know what they meant, though, but let me be picky this time. Tools are important. Thing is, smart individuals tend to use or create good tools, so it all comes together again at the end. The manifesto also continues "That is, while there is value in the items on the right [referring to processes and tools], we value the items on the left [referring to individuals and interactions] more". Unfortunately people often forget about the footnotes, and might interpretate this more in a sense of "it doesn't matter I use Edlin for programming, as long as I write clever code".
Changing topic, did you know that Microsoft Project was tailored for building industry projects, NOT for software projects? Think about it for a moment.
