Playing Grown-Up: The Rails Maturity Model

When I first heard about the RMM I thought it was a joke. Then I thought it was a terrible idea. Then Obie assured us all that it wasn’t about certification, and I thought about it for a while, and decided that it was still a terrible idea. Here’s why.

Let’s start by taking the RMM’s namesake, CMM[I], seriously. Taking CMM[I] seriously is also a terrible idea, but indulge me for the sake of exposition.

I was once tangentially involved in the effort to bring a large organization to CMMI level 3. In the process I became more familiar with Maturity Models than ever wanted to be. The first thing you learn about CMM[I] is that it’s not about specific practices. You will never see “waterfall development” or “cubicle officing” specified in CMM[I] literature. The creators of CMM[I] went to great lengths to keep it free of practice recommendations.

CMM[I] is a process meta-model: it’s a process about processes. The core idea of CMM[I] is that of learning from experience and incorporating that knowledge back into your processes – whatever they may be. The essence of the coveted CMMI Level 5 certification is simply this: An organization which continuously improves itself by gauging the effectiveness of processes and adjusting them accordingly.

So if the RMM seeks to impress the kind of novelty-wary big corporate customers who put stock in things like CMM[I] and 6Sigma, it has failed right off the bat. Anyone who knows anything about CMM[I] will take one look at RMM and laugh at those silly Rails kids who think maturity equates to using certain processes. “Go back to your sandbox” they’ll say. “Come back when you’re older”.

Now let’s stop talking about CMM[I] the lofty ideal, and start talking about CMM[I] the cynical reality. The real purpose of CMM[I] is to guarantee a reliable income for Carnegie Mellon, and to solidify the position of large established corporations. The amount paperwork and expense involved in getting CMM[I] certified is difficult to convey to anyone who hasn’t seen it first-hand.

Only large organizations have the kind of slack necessary to take the productivity hit a CMM[I] program inflicts and keep chugging along. And the sad truth is that the people on the ground have no idea what it’s all about; just that they suddenly have more paperwork to fill out and a lot of dull training sessions to go to where they learn to spit back what the auditors want to hear.

“But wait” you say. “RMM isn’t about certification!”. True. And perhaps that will save it from the excesses of paperwork and naked profiteering that characterizes the CMM[I]. But the fact remains that RMM is and will continue to be defined by the major players in the Rails Arena. If it gains traction, companies that are just getting started will face the choice of getting things done and risking discrimination by a market that knows only “RMM=good”;
or spending their time on processes instead of deliverable code. In the eyes of customers the onus will be on the “non-compliant” shops to explain why they don’t practice pair-programming, or collocation, etc. Not only will this place an undue burden on small, young companies; but as others have pointed out, it does not create a very fertile environment for process innovation. Which, ironically, makes it diametrically opposed to the intent of the original CMM.

I respect Obie a lot, but the RMM project appears like nothing so much as a group of children playing grown-up by aping the dress and mannerisms of stodgy, button-down businessmen. A high-power executive observing might be amused by their antics, but would scoff at their failure to grasp the reasons behind the trappings they have adopted. And anyone who has been through the corporate machine and come out the other side would ask them why a bunch of happy kids could possibly want to imitate the very worst aspects of being an adult.

In summary, I have three things to say to Obie and anyone else who thinks the RMM is a good idea.

  1. It’s a trap!
  2. Look, if nothing else, ditch the name. It will become a source of derision for anyone familiar with CMM; a source of confusion for anyone who hasn’t heard of CMM; and potentially a source of lawsuits if Carnegie Mellon catches wind of it.
  3. If you really care about your customers, help them talk to each other.

UPDATE: Anyone who thinks that the potential for an organisation like RMM to lock-in outdated practices is merely academic at this point should have a look at the current Practice #3: Everyone Together. This is an incredibly backward value to be espousing in 2009, and, again, favors established companies over ultra-lean organisations which prioritise finding the talent wherever it is over building up a brick-and-mortar presence.

7 comments

  1. Avdi, another aspect of RMM that reeks to me is that you either engage in a practice or you don't. There isn't even any gauge to whether or not you're effectively applying the practice (not that it would even be possible to vet people/companies on a large scale to this extent).

    It's kind of like when you're at a presentation and the presenter asks “who here has done x?” and you see a few hands go up, so you put yours up even though you've only read a blog or two about it….you just don't want to be left out.

    Just because you do #standup doesn't mean that it's a positive thing. Your team needs to understand how to approach it, what things are useful to share, etc. Otherwise. you just wasted 15 minutes of productivity for your entire team.

  2. I find it really interesting that people are so reluctant to call Obie out on what his true intentions are. I guess it could be political correctness or politeness; I see it as not offending someone with a lot of weight. The fact the the site originally went up with firm rankings leads me to believe Obie's true intentions are anything but self-serving. The rankings were removed from the site, but not doing so it would have made it hard to keep any credibility.

    What I have see here is an attempt by Obie and Hashrocket to create a club, where only the bigger shops can truly have any real influence. If I am a small shop I can choose to do my own thing, but the club has already biased the community and potential customers on what the best practices should be.

    1. Intentions are in the eye of the beholder. I can't stop you from judging me so harshly, but I can work hard to prove you wrong.

      If you think about it rationally, Hashrocket is already very popular and successful. Our track record of transparency and assisting other firms and individuals is beyond reproach. There is simply no need for us to spend what amounts to tens of thousands of dollars in labor to create a self-serving promotional site.

      Since you brought it up… The emphasis of the site is the practices. That's why it was no big deal to remove the firm page from the navigation. The firms page that was little more than a scaffolded list. Hashrocket only appeared at the top of that page since we had the most data in the system, an artifact of our position as initial alpha testers of the site.

      I do admit to naivete about the depths of cynicism among some people in the community. It's disappointing, but at the same time, provides strong motivation for me to prove the naysayers wrong.

  3. I should proofread before i post. Previous post should read:
    “The fact the the site originally went up with firm rankings leads me to believe Obie's true intentions are self-serving.”

  4. I'm not responding directly to your post, because I'm more amused by #rmm and reactions to it than ticked off or excited or worried by it.

    But: “Practice #3: Everyone Together. This is an incredibly backward value to be espousing in 2009.”

    I beg to differ. There can be serious competitive and qualitative advantages to following that practice and really utilizing the high-bandwidth communication it provides, just as there can be advantages to not following it. These are tradeoffs that many(most?) firms make without even really realizing what they are trading off. At any rate, it seems to me that there's nothing stopping anyone from putting a whole slew of recommended practices for remote workers onto the list and endorsing what's worked out best for them.

    And, on a more serious note, I do hope that someone posts a “practice” concerning the Sampsonite Theory of programming that you and John Trupiano were discussing a month or two back. From my experience, I know that I can and will endorse that, and there are at least a couple of rails shops that I can confirm adhere to it with at least some of their developers.

    1. Yeah, I overstated, as is my wont. I guess the real issue I have is that the practices are already starting to read a tiny bit like a “Java list”. Java was all about taking away all the features mediocre developers might shoot themselves with. Once it became “the standard” you had to justify the use of “dangerous” languages like C++ or Ruby.

      As you and I know, effective remote collab is possible, but it takes more effort than making collocated collab work. I wouldn't recommend it for just any group. Maybe it's good to have the default advice be “keep” everyone together” – but now we're right back at catering to the lowest common denominator. The annoying thing about enshrining collocation as a “best practice” in an ostensibly “cutting edge” context is that now shops that can do distributed collab are going to be asked to justify their choices, and/or seen as higher-risk.

      And given the people involved in the RMM, I don't see a “distributed development” practice gaining much traction on the list. The companies involved seem quite pleased with themselves and each other for keeping all their developers together in one place.

      Which sucks, because I genuinely believe that distributed development is a big part of the future of software. Not just because it's what I want to do; but because it's a more efficient, sustainable way of connecting talent to work without expensive, polluting, community-straining mobility.

  5. Yeah, I overstated, as is my wont. I guess the real issue I have is that the practices are already starting to read a tiny bit like a “Java list”. Java was all about taking away all the features mediocre developers might shoot themselves with. Once it became “the standard” you had to justify the use of “dangerous” languages like C++ or Ruby.

    As you and I know, effective remote collab is possible, but it takes more effort than making collocated collab work. I wouldn't recommend it for just any group. Maybe it's good to have the default advice be “keep” everyone together” – but now we're right back at catering to the lowest common denominator. The annoying thing about enshrining collocation as a “best practice” in an ostensibly “cutting edge” context is that now shops that can do distributed collab are going to be asked to justify their choices, and/or seen as higher-risk.

    And given the people involved in the RMM, I don't see a “distributed development” practice gaining much traction on the list. The companies involved seem quite pleased with themselves and each other for keeping all their developers together in one place.

    Which sucks, because I genuinely believe that distributed development is a big part of the future of software. Not just because it's what I want to do; but because it's a more efficient, sustainable way of connecting talent to work without expensive, polluting, community-straining mobility.

Leave a Reply to cduhard Cancel reply

Your email address will not be published. Required fields are marked *