Recently a stir has been made in our lovely little community about the Rails Maturity Model. The crux seems to be that one or two excellent Rails shops have found a process that really works well for them and there is a belief that this process or “best practices” will ensure a successful outcome.
I am thrilled that companies in our community have found processes that work really well for their people, and I laud the good will to try to lift the community by creating more successful outcomes. But I shudder at the thought of trying to force their process on the rest of the community by creating some de facto standard for anything.
The RMM idea started with the concept of creating a certification for Rails shops. The purpose of a certification is to give a person who does not have the time or ability to evaluate someone an easy to evaluate them. Most of us have enough experience with certifications to know that they are rarely a true evaluation of anything. They turn into a checkbox that everyone must have so that whatever middle level manager that probably has trouble cleaning himself properly in the toilet can say that this person/shop is clearly superior that person/shop. This is true even if the word “certification” is not used and is instead a list of “Best Practices.” This travesty is a result of a badly implemented reaction to the scaling of a technical community. Certifications or Best Practices are a very poor way of trying to say this person or shop will deliver the goods.
The “Best Practice Checklist” idea is particularly bad because on the surface it seems so reasonable. We could probably make a list of best practices that the vast majority of us can agree on. Something like automated testing, iterative development, and short methods sound like great practices to follow, but following them has zero correlation to project outcome. A failed project might have followed all of these practices and a successful project might have followed none. The sole reliable predictor of project outcome is the people that are doing the project; the process used is irrelevant. And it’s even harder than that to predict, because you can have a great developer and a bad client and the project still fails. Or a great client that fails with one great developer but succeeds with another. This chemistry is real and is completely unquantifiable.
What any checklist really says is that process is more important than people. Which is wrong. People are the only thing that matter, process is irrelevant. I can take a great engineer and force the worst process on them and they will succeed, and I can take the worst engineer and force the best process on them and they will fail. That’s one of the reasons pair programming works so well, take any two people and there is a greater chance that one of them can succeed.
As an example, Linus Torvalds recently said that he chose to use tar-balls and patch files rather than use SVN. That sounds like a horrible process to me, but I would not want to say that because he doesn’t follow the RMM that he is not qualified.
So here’s my idea:
Rather than encourage any system that promotes process over people, one that tries to quantify a person based on the process they follow, I would like to propose a Maturity Model that is decentralized, people centric and community oriented: The Ruby Artisans Guild. Like traditional guilds members will be one of the following: apprentice, journeyman, or master. Instead of saying that a person is a master because they do things a certain way, we should honor the individuality of everyone and let them find their own strengths and weaknesses. This is one of the tenets of open source, that people are judged by their contributions, not by how closely they follow a process.
People can evaluate themselves and determine if they are an apprentice, journeyman, or master. They can put a badge on their website and maybe even add something to their “Working With Rails” profile. I would expect a journeyman to charge less than a master and put out lower quality of work. This is fine, many people will gladly make this trade off when hiring. I always ask potential clients who else they are talking to and give honest feedback (usually positive) of others in the community. We should encourage this type of open dialogue. For the most part, developers know their own skill level and are honest about it. The problem occurs when people aren’t asked what their level is. We should exploit this and assign our own rankings. I hope that any system where people are encouraged to self.eval would be welcome to our community. Here’s a hint: If you’re not sure if you are a journeyman or a master, then you’re a journeyman.
This system also promotes the idea of mentorship. An apprentice may become a journeyman by reading and practice, but more likely will grow by the mentor ship of a journeyman or a master. This is how it works in academia: A doctoral candidate is an apprentice, a post-doc is a journeyman, and a professor is a master. And it can work for us too.
If you wanted it to build a product you’d find a way to get time to work on it. If you really wanted to start that new hobby you’d sacrifice something to find the time and money to do it.
I'll define a "Wannabe Entrepreneur" as someone who has never made money from their businesses. Here are the different types of wannabes.
In the past few years I've built go-carts, built a 200+ sq ft workshop, written several eBooks. How do I create a life where I have time to work on side projects?
Receive 5 Software projects mistakes we have made over the years and how to avoid them.