4 ms·
The goals they have are good ones. If you're stuck with more than 10 programmers of varying levels of ability, and you're taking marching orders from a client
by cwilbur 19y ago
The goals they have are good ones. If you're stuck with more than 10 programmers of varying levels of ability, and you're taking marching orders from a client who has no idea what the tradeoffs are, they're arguably the best way to get things done.
When you're a group of fewer than 5 programmers and you're all smarter than the average bear, they're useless.
In essence, they're a ritualization of the communication and testing process that has to happen to make software good and reliable. Without some communication and testing, the software will suck; at a certain organizational size, or with programmers of lower ability levels, you can't rely on the programmers to do it themselves.
- create_account 19y agoThe road to hell is paved with good intentions (and bad specs).
- cwilbur 19y agoOh yes - I don't think CMM &c are silver bullets. But in the end, to build software you have to communicate. Once the group working on the software is larger than 5 or 6, unless everyone on the team is phenomenally good, you need to formalize this communication somehow. All of these formal development methodologies are ways of accomplishing that -- none of them are necessarily good, but at least they solve that problem so you can get to other problems. Of course, this leads to other problems, such as the ISO 9001 compliant company that has all of its dysfunctional processes documented in explicit detail that must be followed. (I worked there once. It was like Office Space meets Brazil.)