What do you feel about Software Process like CMM/CMMi ?
15 comments
The road to hell is paved with good intentions (and bad specs).
Oh 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.)
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.)
I deal with CMM on a daily basis (gov. contracting). It is a huge waste of time, money, and resources. If people spent less time writing documents and more time writing software, the world would be a better place.
There was an interesting article on NASA's use of CMMI at FastCompany: http://www.fastcompany.com/online/06/writestuff.html
As for me, I don't like it. I abide by it at work and it's generally a huge bottleneck for all projects. Many of the ideas the SEI proposes are good practice, and I have a feeling a lot of developers already follow them without knowing that they're part of any "process".
A bad implementation of CMMI at an organization only makes things worse. For example, the latest version of CMMI encourages us to engage in rapid feedback cycles with customers, which is great. But the system we're supposed to track when and how we did that is clunky and consumes time, to the point that you don't want to go talk to customers for fear of having to do more writing and documenation.
As for me, I don't like it. I abide by it at work and it's generally a huge bottleneck for all projects. Many of the ideas the SEI proposes are good practice, and I have a feeling a lot of developers already follow them without knowing that they're part of any "process".
A bad implementation of CMMI at an organization only makes things worse. For example, the latest version of CMMI encourages us to engage in rapid feedback cycles with customers, which is great. But the system we're supposed to track when and how we did that is clunky and consumes time, to the point that you don't want to go talk to customers for fear of having to do more writing and documenation.
These models were "invented" for non-technical types like MBA monkeys to help them feel like they are in control of software engineering process. If you look at these models closely, you realize they resemble various principles employed by mechanical/civil engineering.
So what we have here is the attempt by non-technical managers, to bring some "feel" of control over something inherently complex (software development), modeled by their semi-successful methods of management employed in traditional industries (read companies like GE).
What those guys fail to realize is that software engineering is fundamentally more complex and, therefore, unpredictable than manufacturing industry they're used to (from their business school books).
Pathetic.
So what we have here is the attempt by non-technical managers, to bring some "feel" of control over something inherently complex (software development), modeled by their semi-successful methods of management employed in traditional industries (read companies like GE).
What those guys fail to realize is that software engineering is fundamentally more complex and, therefore, unpredictable than manufacturing industry they're used to (from their business school books).
Pathetic.
I think the keys to CMM are perfectly valid. However I don't think there's a direct correlation between CMM level and the success of the company. You can say that by looking at the companies with a high CMM level that there is a relation, but I could argue as to whether that it is the cause or the effect.
I'd say successful companies applied CMM after they became successful, not before that.
nausea and a vague sense of dread...
It sucks all the fun out of writing software. An awful methodology. I left the company that used it after only 3 months (would have been sooner if I found another job sooner).
I've also seen a bad implementation of CMM. indeed, if not implemented wisely, it adds a lot of unneeded redundancy.
Such processes should be fought tooth and nail:
http://www.fighttheprocess.com
http://www.fighttheprocess.com
The reson I would start a company is to get away from this stuff. It makes me sick.
yeap, I agree...I cannot find a single case where these would be necessary. probably others use it though
not in most startups... I don't see anyone here getting into defence contracting any time soon.
Granted, there are some common sense aspects that are slam dunks (c'mon, version control, why wouldn't you use it) but a lot of it still favours serious software where all the engineers wear dark suits and ties and do big design up front.
Most startups would run out of time and money just getting to level 2 CMMi compliance before they even started to really cut any code.
Granted, there are some common sense aspects that are slam dunks (c'mon, version control, why wouldn't you use it) but a lot of it still favours serious software where all the engineers wear dark suits and ties and do big design up front.
Most startups would run out of time and money just getting to level 2 CMMi compliance before they even started to really cut any code.
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.