Curious about your CMMI thoughts
-
A few of the responses to my earlier post has made me curious. Some of the people that replied seems to think that the CMMI process is a waste of time. While I do agree that it can be poorly implemented, I do not think that the process is bad. The way I understand CMM(I) is that it's tailorable. Essentially you, or your company, tailor the process to best fit your needs. So I'm curious is it CMMI that you do not like or is it your company's implementation of it? nay
-
A few of the responses to my earlier post has made me curious. Some of the people that replied seems to think that the CMMI process is a waste of time. While I do agree that it can be poorly implemented, I do not think that the process is bad. The way I understand CMM(I) is that it's tailorable. Essentially you, or your company, tailor the process to best fit your needs. So I'm curious is it CMMI that you do not like or is it your company's implementation of it? nay
I have seen two different implementations. Both added significant overhead to the business of creating software ( >50% overhead). Both suffered from significant "feed the process" syndrome: focus on maintaining the process and its metrics outweighed the need to create quality software efficiently. Both severly bound the companies to one way of doing things, prohibiting the introduction of, or even experimentation with, new ways of doing things (extrem programming, etc.). CMMI may be 'tailorable', but don't confuse that with flexible. Once entrenched, it becomes an immovable obstacle to change. Anger is the most impotent of passions. It effects nothing it goes about, and hurts the one who is possessed by it more than the one against whom it is directed. Carl Sandburg
-
A few of the responses to my earlier post has made me curious. Some of the people that replied seems to think that the CMMI process is a waste of time. While I do agree that it can be poorly implemented, I do not think that the process is bad. The way I understand CMM(I) is that it's tailorable. Essentially you, or your company, tailor the process to best fit your needs. So I'm curious is it CMMI that you do not like or is it your company's implementation of it? nay
nay wrote: is it CMMI that you do not like Yes. I believe that there are two kind of methodologies (oh, yes, I forgot, CMMI is a "process"): those that believe "change" is a good thing and necessary for development and those that believe that "change" is a problem in some of the early phases of the development. Starting from those beliefs, methodologies try to minimize or maximize changes on the project. CMMI is one of those methodologies that try to minimize changes. I believe that this is a futile effort, just like trying to stop from getting older. Change is part of the development, and change is chaotic. A developer cannot predict when changes will happen and will need to fit those changes on the software project. Indeed, I also believe that SEI methods often succeed to reduce change a lot by hindering the best company's development capability: creativity. Often (if not always) CMMI produced software is mediocre, at best. You see, I do not advocate firefighting, which is changing a software project by bad design, but simply allowing change to happen, because it will. BTW, there is not a single proof that any development method is better than another. No one ever was able to measure software productivity, so, no one really knows what is the best methodology. Yes, even I am blogging now!
-
nay wrote: is it CMMI that you do not like Yes. I believe that there are two kind of methodologies (oh, yes, I forgot, CMMI is a "process"): those that believe "change" is a good thing and necessary for development and those that believe that "change" is a problem in some of the early phases of the development. Starting from those beliefs, methodologies try to minimize or maximize changes on the project. CMMI is one of those methodologies that try to minimize changes. I believe that this is a futile effort, just like trying to stop from getting older. Change is part of the development, and change is chaotic. A developer cannot predict when changes will happen and will need to fit those changes on the software project. Indeed, I also believe that SEI methods often succeed to reduce change a lot by hindering the best company's development capability: creativity. Often (if not always) CMMI produced software is mediocre, at best. You see, I do not advocate firefighting, which is changing a software project by bad design, but simply allowing change to happen, because it will. BTW, there is not a single proof that any development method is better than another. No one ever was able to measure software productivity, so, no one really knows what is the best methodology. Yes, even I am blogging now!
Daniel Turini wrote: No one ever was able to measure software productivity, so, no one really knows what is the best methodology. very true. One of the difficulties is that to accurately measure software productivity, one would have to measure the productivity of the same programmers in two different environments, doing the exact same work. Since even if you attempted this, one unconsciously applies learned techniques once one learns it elsewhere, the second process cannot be equal in equivalence. If you use two different projects, how do you compare them? If you use two different sets of programmers, how do you adjust for performance differences in teams/individuals? Unfortunately the debate is endless.... There are "agile processeses" that account for and encourage "change," of course again, the debate is endless between those... I've been trying to adapt some of the lessons learned from various agile processes to how we do business and our deadlines. Unfortunately no one process fits us well _________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
A few of the responses to my earlier post has made me curious. Some of the people that replied seems to think that the CMMI process is a waste of time. While I do agree that it can be poorly implemented, I do not think that the process is bad. The way I understand CMM(I) is that it's tailorable. Essentially you, or your company, tailor the process to best fit your needs. So I'm curious is it CMMI that you do not like or is it your company's implementation of it? nay
Ok, I googled CMMI to try and find out more about it. I found out that it stands for Capability Maturity Model® Integration (love the (r) in the middle). Those four words, when strung together, mean almost (but not quite) completely nothing to me. It sounds like the punchline of a Dilbert cartoon. Who wastes their time coming up with crap like this? I swear that the logic these people use is along the lines of, "If it's a pain in the ass to implement, it must be worth it, right?" Reading deeper, I found out that with this product I can "expand the scope of and visibility into the product life cycle" as well as "implement more robust high-maturity practices." Can I use an optical mouse to burn out my eyes? We should be reducing the amount of garbage we need to plow through in order to Get Work Done, not increase it.
-
nay wrote: is it CMMI that you do not like Yes. I believe that there are two kind of methodologies (oh, yes, I forgot, CMMI is a "process"): those that believe "change" is a good thing and necessary for development and those that believe that "change" is a problem in some of the early phases of the development. Starting from those beliefs, methodologies try to minimize or maximize changes on the project. CMMI is one of those methodologies that try to minimize changes. I believe that this is a futile effort, just like trying to stop from getting older. Change is part of the development, and change is chaotic. A developer cannot predict when changes will happen and will need to fit those changes on the software project. Indeed, I also believe that SEI methods often succeed to reduce change a lot by hindering the best company's development capability: creativity. Often (if not always) CMMI produced software is mediocre, at best. You see, I do not advocate firefighting, which is changing a software project by bad design, but simply allowing change to happen, because it will. BTW, there is not a single proof that any development method is better than another. No one ever was able to measure software productivity, so, no one really knows what is the best methodology. Yes, even I am blogging now!
Daniel Turini wrote: No one ever was able to measure software productivity, so, no one really knows what is the best methodology. I did see one report from some researchers at MIT. It only had a few datapoints (approx 30). What it found is that the biggest corrolation between mesurement and success was the time between getting a requirement from a user and getting the feature in the product. It didn't highlight that one particular methodology was best, because there wasn't enough data. I wouldn't consider it proof of anything, but it was the closest I've seen to an objective comparision of the principles behind some of the popular methodologies out there.
I can imagine the sinking feeling one would have after ordering my book, only to find a laughably ridiculous theory with demented logic once the book arrives - Mark McCutcheon
-
A few of the responses to my earlier post has made me curious. Some of the people that replied seems to think that the CMMI process is a waste of time. While I do agree that it can be poorly implemented, I do not think that the process is bad. The way I understand CMM(I) is that it's tailorable. Essentially you, or your company, tailor the process to best fit your needs. So I'm curious is it CMMI that you do not like or is it your company's implementation of it? nay
Yes, i firmly believe that Computer-Managed Marmot Interfacing is a wonderful thing. Though you are right in that some implementations of it have been terrible, and no-doubt turn some people away, a well-done CMMI system is a sight to behold. Row after row of happy, fuzzy, creatures, expertly paired and ready to produce many future marmot generations. Yes, the problems during initial implementation still give me nightmares... and i haven't quite gotten all the blood stains off my shoes yet. But in the end, i don't think any sane person could look at our organization and not say that CMMI was beneficial. As a side note, i would like to address the arguments put forth by many that the basic idea behind CMMI is flawed, that it is difficult for even an experienced Marmot Technician to interface correctly, and that no computerized system could possibly handle all the relevant inputs, much less process them properly. To this, i have but one reply: "Bah!". Sure, the work done by hot-shot MTs has been phenomenal, and largely responsible for the current boom in the Marmot sector of our economy. But look at the damage done by less-than-experienced techs! We can't rely on having quality workers doing quality work, or even plan on being able to hire someone with a basic understanding of Marmot physiology... so surely, a system that does, at best, good enough is better than one that runs the risk of failing completely? I think that question speaks rhetorically for itself. No, CMMI is here to stay, and those looking for better results based on individual skill should dig out their buggy whips and get nostalgic somewhere else.
Shog9
I'm not the Jack of Diamonds... I'm not the six of spades. I don't know what you thought; I'm not your astronaut...
-
Ok, I googled CMMI to try and find out more about it. I found out that it stands for Capability Maturity Model® Integration (love the (r) in the middle). Those four words, when strung together, mean almost (but not quite) completely nothing to me. It sounds like the punchline of a Dilbert cartoon. Who wastes their time coming up with crap like this? I swear that the logic these people use is along the lines of, "If it's a pain in the ass to implement, it must be worth it, right?" Reading deeper, I found out that with this product I can "expand the scope of and visibility into the product life cycle" as well as "implement more robust high-maturity practices." Can I use an optical mouse to burn out my eyes? We should be reducing the amount of garbage we need to plow through in order to Get Work Done, not increase it.
David Kentley wrote: Who wastes their time coming up with crap like this? It's a gold mine. Plenty of companies are constantly looking to throw money at the latest trend in managerial/organizational "crap". Hiring companies to help you implement their process/organizational utilities/etc. helps shift the work off some managers shoulders, so they can tote the virtues of the new QZ7CX-standard. that is until the QZ7CX-2000 standard comes out, then he can sell the obvious failure of the first implementation to the company having "outgrown" the QZ7CX standard, and say "Hey, look over here now. There's something better!". It'd be too much to ask some guy who has risen to the top on incompetence alone to actually analyze the business and figure out where the real problems lie. He might really screw something up that way. BW
"Get up and open your eyes. Don't let yourself ever fall down.
Get through it and learn how to fly. I know you will find a way...
Today"
-Days of the New -
David Kentley wrote: Who wastes their time coming up with crap like this? It's a gold mine. Plenty of companies are constantly looking to throw money at the latest trend in managerial/organizational "crap". Hiring companies to help you implement their process/organizational utilities/etc. helps shift the work off some managers shoulders, so they can tote the virtues of the new QZ7CX-standard. that is until the QZ7CX-2000 standard comes out, then he can sell the obvious failure of the first implementation to the company having "outgrown" the QZ7CX standard, and say "Hey, look over here now. There's something better!". It'd be too much to ask some guy who has risen to the top on incompetence alone to actually analyze the business and figure out where the real problems lie. He might really screw something up that way. BW
"Get up and open your eyes. Don't let yourself ever fall down.
Get through it and learn how to fly. I know you will find a way...
Today"
-Days of the Newbrianwelsch wrote: It'd be too much to ask some guy who has risen to the top on incompetence alone to actually analyze the business and figure out where the real problems lie. He might really screw something up that way. :laugh::laugh::laugh: I may have to borrow that for my sig...:) Anger is the most impotent of passions. It effects nothing it goes about, and hurts the one who is possessed by it more than the one against whom it is directed. Carl Sandburg
-
Ok, I googled CMMI to try and find out more about it. I found out that it stands for Capability Maturity Model® Integration (love the (r) in the middle). Those four words, when strung together, mean almost (but not quite) completely nothing to me. It sounds like the punchline of a Dilbert cartoon. Who wastes their time coming up with crap like this? I swear that the logic these people use is along the lines of, "If it's a pain in the ass to implement, it must be worth it, right?" Reading deeper, I found out that with this product I can "expand the scope of and visibility into the product life cycle" as well as "implement more robust high-maturity practices." Can I use an optical mouse to burn out my eyes? We should be reducing the amount of garbage we need to plow through in order to Get Work Done, not increase it.
CMMI came after CMM (just like a CMM 2.0). CMM born from some bureaucratic agency of US government that was ridden with failed software projects, and decided to reduce losses. So they developed a "Capability Maturity Model" to make sure that they wouldn't give a project bigger than the capability or the maturity of a company would be able to handle, and a method to assess it (there are 5 CMM levels, and no one was able to reach level 5 yet). It'd be intuitive for us to ask a few questions, like "do you backup your sources?", "do you use a SCC system?", "do you have a separate test staff?", "do you have a build machine?". But as a bureaucratic agency, they completely screwed it by reducing it to a bunch of forms to be filled. Someone at SEI (Software Engineering Institute, or something like this) got this model and thought "hey, this is describing how an ideal software company should be!". So, those guys at SEI developed a methodology (sorry, "a process") that assures that you spend at least 50% of your time filling forms, 30% writing standard documents, and 20% of your time developing software. On the past, for a series of reasons, I learned a lot about CMM. So, I know what I'm talking about: If you actually read the original SEI CMM process descriptions, you won't find a single word about when to read the documents and forms. All documents and forms are only meant to be written and maintained up to date. Yes, even I am blogging now!
-
Yes, i firmly believe that Computer-Managed Marmot Interfacing is a wonderful thing. Though you are right in that some implementations of it have been terrible, and no-doubt turn some people away, a well-done CMMI system is a sight to behold. Row after row of happy, fuzzy, creatures, expertly paired and ready to produce many future marmot generations. Yes, the problems during initial implementation still give me nightmares... and i haven't quite gotten all the blood stains off my shoes yet. But in the end, i don't think any sane person could look at our organization and not say that CMMI was beneficial. As a side note, i would like to address the arguments put forth by many that the basic idea behind CMMI is flawed, that it is difficult for even an experienced Marmot Technician to interface correctly, and that no computerized system could possibly handle all the relevant inputs, much less process them properly. To this, i have but one reply: "Bah!". Sure, the work done by hot-shot MTs has been phenomenal, and largely responsible for the current boom in the Marmot sector of our economy. But look at the damage done by less-than-experienced techs! We can't rely on having quality workers doing quality work, or even plan on being able to hire someone with a basic understanding of Marmot physiology... so surely, a system that does, at best, good enough is better than one that runs the risk of failing completely? I think that question speaks rhetorically for itself. No, CMMI is here to stay, and those looking for better results based on individual skill should dig out their buggy whips and get nostalgic somewhere else.
Shog9
I'm not the Jack of Diamonds... I'm not the six of spades. I don't know what you thought; I'm not your astronaut...
-
CMMI came after CMM (just like a CMM 2.0). CMM born from some bureaucratic agency of US government that was ridden with failed software projects, and decided to reduce losses. So they developed a "Capability Maturity Model" to make sure that they wouldn't give a project bigger than the capability or the maturity of a company would be able to handle, and a method to assess it (there are 5 CMM levels, and no one was able to reach level 5 yet). It'd be intuitive for us to ask a few questions, like "do you backup your sources?", "do you use a SCC system?", "do you have a separate test staff?", "do you have a build machine?". But as a bureaucratic agency, they completely screwed it by reducing it to a bunch of forms to be filled. Someone at SEI (Software Engineering Institute, or something like this) got this model and thought "hey, this is describing how an ideal software company should be!". So, those guys at SEI developed a methodology (sorry, "a process") that assures that you spend at least 50% of your time filling forms, 30% writing standard documents, and 20% of your time developing software. On the past, for a series of reasons, I learned a lot about CMM. So, I know what I'm talking about: If you actually read the original SEI CMM process descriptions, you won't find a single word about when to read the documents and forms. All documents and forms are only meant to be written and maintained up to date. Yes, even I am blogging now!
Daniel Turini wrote: you won't find a single word about when to read the documents and forms. True. Worse yet, CMMI does not really have much to say (or seem to care about) the quality of the final product. All it really cares about is that you do things in a documented, repeatable way, and can prove that you do them in that fashion...it is entirely about process, not product. Anger is the most impotent of passions. It effects nothing it goes about, and hurts the one who is possessed by it more than the one against whom it is directed. Carl Sandburg
-
CMMI came after CMM (just like a CMM 2.0). CMM born from some bureaucratic agency of US government that was ridden with failed software projects, and decided to reduce losses. So they developed a "Capability Maturity Model" to make sure that they wouldn't give a project bigger than the capability or the maturity of a company would be able to handle, and a method to assess it (there are 5 CMM levels, and no one was able to reach level 5 yet). It'd be intuitive for us to ask a few questions, like "do you backup your sources?", "do you use a SCC system?", "do you have a separate test staff?", "do you have a build machine?". But as a bureaucratic agency, they completely screwed it by reducing it to a bunch of forms to be filled. Someone at SEI (Software Engineering Institute, or something like this) got this model and thought "hey, this is describing how an ideal software company should be!". So, those guys at SEI developed a methodology (sorry, "a process") that assures that you spend at least 50% of your time filling forms, 30% writing standard documents, and 20% of your time developing software. On the past, for a series of reasons, I learned a lot about CMM. So, I know what I'm talking about: If you actually read the original SEI CMM process descriptions, you won't find a single word about when to read the documents and forms. All documents and forms are only meant to be written and maintained up to date. Yes, even I am blogging now!
there are alot of outsourcing houses in India that claim they are CMM5 or CMM4. Being that level means that you have a process in place to be repeatable and that you have been. It does not mean that you make good, useful software. Steve Maier, MCSD MCAD
-
Yes, i firmly believe that Computer-Managed Marmot Interfacing is a wonderful thing. Though you are right in that some implementations of it have been terrible, and no-doubt turn some people away, a well-done CMMI system is a sight to behold. Row after row of happy, fuzzy, creatures, expertly paired and ready to produce many future marmot generations. Yes, the problems during initial implementation still give me nightmares... and i haven't quite gotten all the blood stains off my shoes yet. But in the end, i don't think any sane person could look at our organization and not say that CMMI was beneficial. As a side note, i would like to address the arguments put forth by many that the basic idea behind CMMI is flawed, that it is difficult for even an experienced Marmot Technician to interface correctly, and that no computerized system could possibly handle all the relevant inputs, much less process them properly. To this, i have but one reply: "Bah!". Sure, the work done by hot-shot MTs has been phenomenal, and largely responsible for the current boom in the Marmot sector of our economy. But look at the damage done by less-than-experienced techs! We can't rely on having quality workers doing quality work, or even plan on being able to hire someone with a basic understanding of Marmot physiology... so surely, a system that does, at best, good enough is better than one that runs the risk of failing completely? I think that question speaks rhetorically for itself. No, CMMI is here to stay, and those looking for better results based on individual skill should dig out their buggy whips and get nostalgic somewhere else.
Shog9
I'm not the Jack of Diamonds... I'm not the six of spades. I don't know what you thought; I'm not your astronaut...
-
there are alot of outsourcing houses in India that claim they are CMM5 or CMM4. Being that level means that you have a process in place to be repeatable and that you have been. It does not mean that you make good, useful software. Steve Maier, MCSD MCAD
Steve Maier wrote: there are alot of outsourcing houses in India that claim they are CMM5 or CMM4. Being that level means that you have a process in place to be repeatable and that you have been. It does not mean that you make good, useful software. Actually, if any really are CMM5, I would expect that they make practically no software. At that level, the process IS the product. Anger is the most impotent of passions. It effects nothing it goes about, and hurts the one who is possessed by it more than the one against whom it is directed. Carl Sandburg
-
Steve Maier wrote: there are alot of outsourcing houses in India that claim they are CMM5 or CMM4. Being that level means that you have a process in place to be repeatable and that you have been. It does not mean that you make good, useful software. Actually, if any really are CMM5, I would expect that they make practically no software. At that level, the process IS the product. Anger is the most impotent of passions. It effects nothing it goes about, and hurts the one who is possessed by it more than the one against whom it is directed. Carl Sandburg
There was one that I worked with at my last job (I will keep the name private), that always boasted that they were CMM5 but when they wrote software for us, I was very disappointed. Of course working with the company that I was, they did not do specs very well and had to be able tochange things quickly without formal change requests. The issue with that is that a CMM5 should not have accepted it. But they did. Steve Maier, MCSD MCAD
-
A few of the responses to my earlier post has made me curious. Some of the people that replied seems to think that the CMMI process is a waste of time. While I do agree that it can be poorly implemented, I do not think that the process is bad. The way I understand CMM(I) is that it's tailorable. Essentially you, or your company, tailor the process to best fit your needs. So I'm curious is it CMMI that you do not like or is it your company's implementation of it? nay
I see CMM as a necessary evil in large scale software development. Large scale meaning either a few hugely complex projects, or lots and lots of projects (or both). I think there is a certain point at which disparate project groups, or development groups within a project, are no longer able to effectively and efficiently communicate with the clarity required to keep them from always stepping on each others' toes. From the CMM implementation at my company, I believe that it does a pretty good job of reducing the number of stepped-on toes. But it's greatest benefit is forcing enough information to be recorded about things that you'll be able to figure who's stepping on your toes, and what changes caused the actual problem. That being said, I detest working on a project that is under CMM control, because of the copious amount of process and documentation required to get anything done. But the first time a big program I was working on went tits-up for no discernable reason, we were able to look through our CMM repository to pretty quickly find the culprit. It would have been a much bigger headache to have to pow-wow with fifty-something different project teams working on all the downstream systems we're using, not to mention the server maintenance team that was responsible for patching/updating the various servers our program components lived on. If we were a much smaller shop, or didn't have as many projects under development or active maintenance, the extra workload imposed by CMM probably wouldn't be worth it. -- Russell Morris "So, broccoli, mother says you're good for me... but I'm afraid I'm no good for you!" - Stewy
-
A few of the responses to my earlier post has made me curious. Some of the people that replied seems to think that the CMMI process is a waste of time. While I do agree that it can be poorly implemented, I do not think that the process is bad. The way I understand CMM(I) is that it's tailorable. Essentially you, or your company, tailor the process to best fit your needs. So I'm curious is it CMMI that you do not like or is it your company's implementation of it? nay
CMMI is all about improving the way the company operates in order to attempt to create better quality products. In theory, that's a good thing, but in practice, it centres on writing documentation (although very rarely reading it). I'm a developer, which means I want to design and implement software, not spend 50% of my time writing useless documentation that means nothing and which nobody will ever read. It's just ludicrous.
Ryan
"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
-
A few of the responses to my earlier post has made me curious. Some of the people that replied seems to think that the CMMI process is a waste of time. While I do agree that it can be poorly implemented, I do not think that the process is bad. The way I understand CMM(I) is that it's tailorable. Essentially you, or your company, tailor the process to best fit your needs. So I'm curious is it CMMI that you do not like or is it your company's implementation of it? nay
I think joel[^] does a good job covering the highlights of what makes a good software development shop. There is process, and it is very important that it is there, but it exists for only one reason, to produce high quality software. I think CMM breaks down because it has one solution for every problem, create a document. It enforces process and communication through documentation and that is very unnatural and slow. Many problems have better solutions. I had a manager that was all into CMM. Every time we had a problem, he added a section to a document or another document to prevent it from happening again. So when the team wanted to create an automated install to reduce launch problems and get us out of the office before 2AM, he fought it because it elmininated the 8 page launch document and all the launch drills that we had to endure, even though most problems during launch could be linked to the admins missing steps outlined in the launch doc.
I can imagine the sinking feeling one would have after ordering my book, only to find a laughably ridiculous theory with demented logic once the book arrives - Mark McCutcheon