Matt Aimonetti has a client that believes Rubyists don't scale. Sorry Matt, your client is wrong.
It's as easy to hire great Ruby programmers as it is to hire great Java programmers or great programmers for any given popular language.
The problem is, it's not easy to hire great programmers in any language. Worse, companies still think they need to hire one or two great programmers and a supporting cast of average programmers. As Martin Fowler pointed out, cheaper developers are actually more expensive than experts. To make things worse, if you end up with a NNPP or two you'll be headed in the wrong direction.
As I've said before, 50% of all programmers need to find a new profession. In the short term this will create a much larger demand for developers, and salaries will rise. However, since one expert programmer produces significantly more (up to 28 times more) than two terrible programmers, companies will ultimately save money. It's unlikely that salaries of experts will rise to the sum of 28 terrible programmer's salaries.
Some people believe that the average programmers are valuable because they do the jobs the experts don't feel like doing. This is simply wrong. Average programmers will do average jobs on mundane tasks, which often turns into a mess for expert programmers to fix. Even if the solution proposed by average programmers doesn't require an entire rewrite, it is often sub-optimal and can have implications with other pieces of software that rely on it.
There's a better way. Give mundane tasks to expert programmers. Expert programmers remove or automate mundane tasks. The solutions will be superior, and either way the experts won't be doing mundane tasks.
If you have great programmers producing up to 28 times more, and you only hire great programmers, how many programmers do you think you need? Of course the answer depends on how much software needs to be written, but in general teams can become a lot smaller.
And this is the problem with Matt's client's statement. While they may not be able to easily build a team of average Ruby developers, it doesn't matter, that's the wrong goal. Of course, I have no way of knowing the caliber they were looking to hire. But, I do know if they wanted Ruby experts that will travel, ThoughtWorks employs several. So, I'm left to guess that they fell into the same old misguided pattern of trying to pay average salaries to average developers.
I'm left wondering why they would take expert advice on what technology to use, hire an expert, achieve success and then stop pursuing experts. Of course, I'm not surprised. As a consultant, I saw it time and time again.
The question isn't whether you can hire rubyists or not, it's whether or not you are willing to put the effort in to hire experts. It isn't easy to hire experts regardless of the language, but it is worth it.
Absolutely excellent. I loved the Martin Fowler article as well. Although I'm a Ruby development, I'm finishing a degree in economics and productivity and labor economics in general are extremely interesting to me. I describe in my blog article some reasons why the software industry is what it is today (and doesn't recognize this productivity-pay disparity): http://www.respectcapitalism.com/2008/04/13/the-dead-sea-effect-in-it/
ReplyDeleteBut you and Martin really hit the nail on the head.
Thanks Jay for writing about the challenge I faced.
ReplyDeleteI totally agree that it has nothing to do with the language itself and to be honest with you, I'm quite reassured that even experts like yourself are facing these kind of decisions.
I look forward to someone now writing an article on how you create/train experts. Or do they just appear one day, riding into town on a horse?
ReplyDeleteYou don't give expert developers mundane tasks, you give them "this can't be done but if you manage to get it done, it'd be really great"-tasks. Because expert developers are experts in injecting mundane problems with galactic amounts of scope creep to make them "more interesting."
ReplyDeleteYou ask: "Hey, could you make a small database for these things?", preferred solution being SQLite or CREATE DATABASE. The expert hears: "Hey, could you write me an infinitely scalable database management system using the latest research in whatever language you happen to like at the moment?" And will proceed to waste two years on the project with a 10% chance of ever getting it done and a 5% chance of ever bothering to integrate it with the rest of the system. While it might've taken a regular Joe ten years to write a system like that, a regular Joe would've just used existing stuff and be finished in two hours.
Great post Jay.
ReplyDelete@DrNic: I'm trying to write a book to help people at the beginning of the journey toward mastering this craft of ours. IMO, no one can train or create an expert, though mentoring can certainly help the situation. In my experience, experts are are "created" when a person is passionate about what they do and has a insatiable appetite for learning and excellence.
@anonymous, I understand your point of view and those people definitely exist, but I don't consider them to be experts. Part of being an expert is knowing what the simplest thing that could possibly work is.
ReplyDeleteCheers, Jay
@anonymous - the person whom you are referring to is certainly no expert. They may be experienced, smart, and capable of getting things done, but in your case it seems they lack the business acumen; the understanding of the need to deliver value etc.
ReplyDeleteThis is so wrong I don't know where to start. First who decides what is "great"? Second, many programming tasks do not require "Kent Beck" or "Richard Stallman" greatness. They require good programmers. I have worked with more good programmers than bad ones, and very few great ones.
ReplyDeleteYes, we have all worked with NNPP. They exist in any field (not all doctor's graduated at the top of their class either).
And we all know that Thoughworks has its fair share of bad programmers. This rant smells of self serving bull hockey.
@peterb - how could it be self serving? Jay isn't at ThoughtWorks.
ReplyDeleteI do partly agree with @peterb. (Aside from the self serving stuff).
ReplyDeleteI don't consider myself to be an "expert" developer by any stretch of the imagination, but I do consider myself pretty well versed when it comes to development.
For example, I can ramble on with the best of them about all sort of design patterns, agile practices, refactoring techniques, data structures, etc ... but at the end of the day ... what makes me an "expert?" Popularity? Branding? Writing a book? Maintaining a blog?
The reason I, personally, don't consider myself an "expert" is because there is always something to learn. There is always someone out there that can write better code than I can. It's an ongoing process that NO developer will ever become the best at.
Does this mean I should quit my programming day job and move aside so that other "experts" can lead the way? I would certainly hope not.
Don't get me wrong. I understand there are people who just do not understand thing one about developing software, but when exactly should I throw in the towel and move on to another profession because I'm not "expert" enough?
@Bryan, At the bottom of Elephant in the Server Room I list what I expect from teammates. I'm guessing from your comment you fit the bill. When you don't it's time to throw in the towel.
ReplyDeleteAnd, no, writing, popularity, and branding have nothing to do with you being an expert.
Cheers, Jay
Interesting arguments on both sides. I wonder, are we able to go a bit further than arguments that sound good? Do we have a significant body of data to work with? I'd like to see a compilation (i.e. cross-cutting study) of scientific studies on programmer productivity. With only a relatively small number of anecdotes and disconnected individual experiences, I think we all must remain very open minded on the answers to these questions. We also need to flesh out what "good" means -- I suspect it varies considerably based on the project and team involved.
ReplyDeleteUh, ruby is just another programming language in the tradition of C++, C#, Java (as opposed to prolog or lisp); albeit a highly productive one. For a good programmer it should only take a few days to learn and a few short months to master.
ReplyDeleteYes, we have all worked with NNPP. They exist in any field (not all doctor's graduated at the top of their class either).
ReplyDeleteThere's a difference between being mediocre and being a net negative producer. I explained the concept of a net negative producer to my wife (a doctor) and she had never come across one in medicine. She understood how it came about in programmers, and could imagine some doctor somewhere being net negative producer, but eventually they would be called on it since "negative" to a doctor means someone gets sick or dies.
Dr Nic's commented that "expert" programmers cause trouble by over engineering complex solutions for simple problems. This is garbage. The top notch guys I've met and worked with size the solution to the problem. I'd go further and say they are the folks who are capable of tackling complex problems and reducing them through analysis and elegant logical reductions into the most simple solution that adequately meets requirements.
ReplyDelete@michael - I think it was "anonymous" who commented after I did that suggested that, not I. I haven't worked in enough situations + with enough people have any clear thoughts on the topic.
ReplyDeleteAs a proponent of PATFT and a recent ruby neophyte, I find your stated belief that one should hire only 'expert' developers highly dubious.
ReplyDeleteNot only have I benefited from the advice of far senior co-workers in our consultancy, I would argue that without them my skills would hardly be as advanced as they are now. Were it not for senior developers pairing with me and giving me some over-arching life lessons about Rails and Ruby, my progress would be greatly stunted compared to what it is. These lessons are all things I could have learned on my own, but were greatly advanced by working with supremely intelligent co-workers.
It will be a long time from now (if ever) that I consider myself a ruby or rails expert but, with all due respect, I must disagree with your ideas about hiring mentors and newbies. It's much more about the quality of the mentors and the quality of the newbies than it is about the fact that you're hiring newbies or mentors.
I still don't see where the client is wrong in this. It seems there may be a disconnect from the contractors in the workforce vs the FTE. I think the main point is that the client wanted to build a team of developers, not contractors. Finding great contractors is easy, finding great FTE's is hard.
ReplyDelete@anonymous' experiences seem close to my own. I've worked with SE who can build ingenious messages que systems in Ruby but whose Rails code is well ...not so good.
ReplyDeleteI've tried to ananlyse why that is. I can only figure they find the framework aspect too boring and consequently they don't apply themselves. I consider myself a 'framework developer' knowledgable in the low to mid-end of Rails but definately not a Ruby SE.
My experiences have led me to believe that Rails projects need a tiered skill approach with the high end programmers tackling high end problems and the mid level ensuring proper adoption of Rails philosophies.
I think some people leaving comments are missing the point. It is not about finding expert programmers. It is about finding great programmers. This is not the same thing. I don't want an engineer with '10 years experience in language xyzzy', I want an engineer who is a great programmer. That great programmer may have just graduated yesterday or may have been doing it for 10 years.
ReplyDeleteOh, and while I agree in theory that there is some risk (as some have said) of someone coming up with an 'overly complex' solution to a program, more often than not, this is just the response of a bad programmer who looks at a solution to a complex problem and is upset because it is complex.
I have seen far more pain caused by 'the easy' solution to complex problems than I'd care to admit.
What a pompous ass.
ReplyDelete