Scratching an itch
posted by pete on May 10th, 2009
When I fell in love with Ruby and Rails some years ago (Unspace turns 5 this fall!) it was David’s framework that got me in the door, why’s eccentricity that made me feel at home, and the rush of a rapidly growing community of almost universally fascinating people that kept me grounded. I can’t believe how many friends I have met through working with Ruby! It’s surreal to wonder what my life would be like today if I hadn’t met folks like Hampton Catlin and Tobi Luetke.
The English-speaking Ruby community sure has had its share of controversies, and watching how everything plays out — sometimes being involved — has been a total blast… for the most part. It’s like a distributed network of creative individuals that are all scratching their various itches with a tool we share a deep affection for.
Well, sometimes if something itches a lot — won’t stop itching, in fact — it turns out that it’s not an itch at all. Sometimes it’s actually a cancer, or perhaps gangrene. In both examples, they can be prevented to some degree; in any case, early diagnosis and response is the best hope of removing something before it removes you.
This whole Rails Maturity Model debacle has been fascinating to watch, regardless of your stance on whether it is good, bad, or ugly. I have nothing but respect for Obie, and I’m curious to see if his itch gets scratched. I see RMM as equal parts “make the community more accessible to new Rubyists and transparent to the entities that would hire them” and “establish Hashrocket as an obvious baseline for defining a quality Ruby development shop”. Personally, I wish him all of the best with that, even if that’s not the itch I need to scratch.
Where RMM fails me is not any fear that Unspace wouldn’t measure up. Everyone involved with Unspace is here for a good reason, and we’re all different. I like how Giles described the fluctuating best practices at ENTP best.
What RMM does not do is facilitate an early warning for the other kind of itch: the cancers and the gangrenes that creep into otherwise healthy systems and take advantage. The Ruby community tries to be so polite that we end up being totally spineless when confronted by a shared threat. We don’t want to hear about our new cancer, think about that slowly creeping gangrene — even though our paralysis to act on things we know aren’t right are causing us harm.
What are we supposed to do when there are people or companies in our community that should be pilloried for their regretful behaviour? There are people amongst us that are, for all intents and purposes, frauds. They lie, cheat, and steal; things most people would consider problematic beyond anti-social Internet troll antics and IRC melodramas.
It’s painful when you’ve personally talked to 3-4 start-up founders that have all been victimized by the same individual. I’ve put a huge amount of my life into making Ruby-backed web applications the obvious choice for new ventures in Toronto, and so it’s beyond embarrassing when people are in visible distress because one of the rare bad apples made a whole bunch of promises, took their money, and ran. Ruby was sold to them as being a way to identify people who were team players at the top of their game. These are people who will likely think twice about anything we as a community promise a second time. That’s a huge shame.
I sincerely hope RMM serves whatever needs it was created to take care of. In the meantime, what I want — the Ruby blacklist — is something that most people are terrified about discussing for fear of social, business, and — let’s face it — legal backlash.
That’s a real shame, because these cancers are eating us.
May 11th, 2009 at 04:18 AM
I deeply share your itch/cancer, however I don’t think blacklists are the solution. They are notoriously inaccurate and unfair, likely because they require authoritative judgment by some intermediary.
Fortunately, the internets enable judgment to be captured at the source and aggregated. Intermediary judgment is not required. What is needed is an independent tool to collect feedback from experienced customers. Done right, such a thing can provide new customers with all the information they need to make their own judgments.
Such tools already exist for many other markets but curiously, not for tech consultancies, as far as I can google. Perhaps this is, as you say, due to a natural aversion to self-scrutiny. Or perhaps the momentum of the industry has simply prevented cynicism from taking hold. Regardless, such a thing is long overdue, not only in the Ruby community, but in the tech industry as a whole, which has supported a rich ecosystem of parasites from the day the cash started flowing. These entities hurt customers, firms and developers alike.
Rating sites tend to be more effective the narrower their scope, so the local Ruby community would be a great place to start. I’m sure this site would be teeming with controversy and even good people would sometimes need to defend themselves from misguided criticism. However, I believe that with the right approach, such a project would be a huge benefit to honest and competent members of the community, big and small, old and new.
May 11th, 2009 at 09:27 AM
Pete, we should talk on the phone sometime soon and I’ll explain RMM in detail. At the moment your post doesn’t really make sense, since RMM only serves to document and capture endorsements of the processes of its member firms, whatever those practices might be. Whenever you go to the Practices page, you should see it as a menu of many different choices served up by the community—NOT a comprehensive list of everything that a Rails shop should do. In fact, some of the practices are contradictory.
Some folks are being thrown off by the fact that we seeded the site’s data with our own practices, as the first firm on the site.
May 11th, 2009 at 10:08 AM
That’s the value of getting together over beers and asking a trusted person about Person X and getting a real answer. Or chatting over the phone. I suppose beer isn’t requisite. But the old adage definitely applies – don’t write (or type) anything that you wouldn’t want to see reproduced any where else.
Honestly, I didn’t realize there was such a problem in the Ruby community that it could be called a cancer or a gangrene. In fact, I didn’t even realize you were talking about specific people, or problematic trends. I’m still not sure, actually! Perhaps some clarification without naming any names?
May 11th, 2009 at 10:09 AM
comment fail: i had a < to quote those first two paragraphs, but i think it got strippededed off.
May 11th, 2009 at 12:37 PM
@Jed: To be clear, this post was intended to start conversation. I don’t think there can or will ever be a physical, functioning blacklist. The issues I’m working through revolve around it being relatively easy for developers to find and discuss this information amongst themselves, but potential customers have only their instincts to go on. A good loud talker can fool these instincts.
@Obie: I miss you, man. I’d love to talk, but I have to admit I’d rather hear about your photography and new ideas for developing business than RMM at this point. I’m probably going to be firmly in the “undecided” category for a long time on this one, but I’m open minded.
@Billy: On one hand, you can never devise a perfect way to get rid of all of the bad apples, and I used to think that Ruby was somewhat immune to this sad phenomena. I was wrong, and all it takes is a few people actively saying one thing and doing another to give us all a bad rep.
All: Yes, this post was inspired by my long-term experiences with and conversations with other victims of a certain individual. Frankly, I probably give them too much credit on the “don’t attribute to malice that which can be explained by ignorance” scale. Part of my frustration is that I am sick and tired of people calling me (often too late) and repeating the same sad story. I feel like my hands are tied, and I’m not sure what I can possibly do to affect change without exposing myself or Unspace to a world of legal pain.
May 11th, 2009 at 01:15 PM
I think a formal blacklist would be a recipe for abuse and disaster – and as Giles Bowkett pointed out, you can’t even really ‘certify’ the practices of the extremely good developers.
I think part of the problem is that the ‘Ruby Community’ (or any other language community) mostly consists of programmers – while it should also include employers, managers, CTOs, and startup founders. If you’re hiring Ruby developers in Toronto, then really you’re part of the Ruby Community.
The Rails Pub Nights (thanks Pete) and the Presentation Nights (thanks Corina) have been great ways to meet people – and it’s also a way to figure out who is a jerk or an idiot (or often both). If employers feel like they’re in the dark about who they can or should hire, they should take part in more of these kinds of events – not just sponsorship, but sitting down and talking with people.
I gather that one of the steps that big-shot law firms do in hiring new law-school graduates is to take them out to a nice dinner, to see how they are in a social situation, and to get a better sense of their personality. Programmers are usually hired by HR people checking if their resumes say ‘10 years of PHP’ – or by founders checking blogs and Google. There’s no substitute for meeting people and getting a personal sense of them, as well as how other people treat them.
Although some companies have had strong presences at the various Ruby events, perhaps the focus and promotion of these events could be adjusted a bit to include managers, CTOs, etc. I know a lot of ‘business’ types don’t like to mix with the nerds – and the feeling is often mutual – but it might not be so bad once they get used to each other – and it might be better in the longer-term for both.
May 11th, 2009 at 02:44 PM
As far as RMM, my theory is Obie’s integrity is A-OK, it’s just his logic that got jumbled. It could be as much a way of starting a dialogue around business practices as anything else. I obviously remain very skeptical of RMM but I don’t doubt his heart’s in the right place.
Re: the blacklist, clearly there are problems I didn’t know about at all. I’ll refrain from prescribing any solution there, but I have to say, a blacklist sounds like a recipe for legal problems. Also remember that power corrupts. After all, if you’re concerned about manipulative people, think how much damage a manipulative person could do with a blacklist. Remember that I’m speaking as somebody got banned from a conference for criticizing one of the conference’s organizers.
I don’t think a blacklist would work, for a variety of reasons, but I think that if it did work, it would not be a good thing, on the whole. I don’t know what to suggest instead – client testimonials? Blogging about the activities of individuals that have tarnished our reputation? Sunlight is the best disinfectant, but that path has its own risks.
I like the Nietzchean rule myself – “wrestle not with monsters, lest you become a monster” – although I obviously haven’t had a very good rate of success at following that rule the past few weeks.
May 11th, 2009 at 03:26 PM
@Pete and @Giles Thanks for the warm and fuzzies. My heart is in the right place, I assure you. So, let’s establish some clarity here, because it still sounds like both of you are considering RMM to be prescriptive. It’s not prescriptive at all. It’s objective, in the sense that it catalogues a wide range of practices, even some that are contradictory.
For example, at Hashrocket we practice “Everyone Together” and that’s in RMM, and at ENTP they practice “Remote Workers” and that’s in RMM too. Those practices are opposite each other. Could some firm implement both? Sure, since maybe some of their folks are together and some are remote. Does any firm have to pick at least one of those two practices. A resounding “no, they don’t” is the answer, since you’re only supposed to document the practices that characterize your firm’s “recipe for success”.
The site will not lend itself to judgment, either by us (Hashrocket) or outside forces, since the site does not establish that any practices are better than others or “best practices” that need to be adopted by anyone. We have plans to compare/contrast practices in terms of adoption and intensity, but that’s it—conclusions drawn from that data will provide plenty of fodder for discussion in the community.
May 11th, 2009 at 05:57 PM
@Obie: Maybe this is a minor linguistic quibble, but what’s the word “maturity” doing in it, if it isn’t intended to be prescriptive?
May 12th, 2009 at 05:34 AM
@Andrew: reputation seems to spread pretty smoothly among developers and employers. It’s the customers who are getting screwed, the ones who have no reason to be involved with the community until they need a site built. We can’t expect them to come gossip with us at the pub. They need a way to get informed on a massive scale.
May 12th, 2009 at 06:05 AM
Following on from Jed, I don’t think the vast majority customers appreciate even the existence of the Ruby community let alone make stereotyped judgements of it based on individual experiences. The few bad apples are certainly bad news but if your concern is customers forming negative opinions of Ruby practitioners I think your concern is misplaced. The actions of these dishonest people reflect poorly on programmers and web developers in general much more seriously than they do specifically on Ruby developers. I could be wrong, but this is my initial impression.
As for what you should do about it, isn’t there already an existing legal system? Otherwise I’d accept it as something you don’t have a great deal of control over. The problem originates with the hiring practises of customers so unless you can educate them I think you’ll have little effect. Even if a blacklist existed how would customers come to learn of it?
May 13th, 2009 at 11:55 AM
One problem with a blacklist is a problem of moderation. There would be either no policing at all, or policing by inappropriate people. Having been a member of the community for a long time, I’ve certainly heard some horror stories; and I’ve been part horror stories. Not all client interactions go well, but I would argue that it’s rarely due to malicious intent of either party, more often born out of a lack of education or experience on one side or the other. Indeed, many of the people posting here would find themselves on such a blacklist, and it might not be deserved. I would certainly find myself on a blacklist due to past misunderstandings, but work hard to avoid those problems in the future.
Another problem with a blacklist as you describe is that many clients don’t even know when they’ve been screwed, and often when they think they were screwed they weren’t. I know of several clients locally (ie: in Toronto) who received extremely poor quality code that is nearly impossible to maintain, doesn’t perform under load, and wasn’t feature complete: but they absolutely love the vendor who provided it. On the flip side, I know clients (and I’ve had clients like this) who received maintainable code that followed “best practices”, made their business successful, and absolutely hated the vendor and felt they were “screwed” by said vendor.
The bottom line is, there are two sides to every story. If there are ill-meaning, malicious, greedy, unreliable people in our development community, we need to understand that there are also clients with the same characteristics. What we need to do is stop making personal attacks out of failed business relationships1 and help people grow as a result of these relationships. Individually, we must encourage each other to admit our mistakes, and work to correct them for the future.
1. Which I’ve absolutely done in the past, and am modifying my criticisms of myself and others to be technically based, rather than trying to infer intent.