Tuesday, March 24, 2009

High quality developers and language flame war retards

Having now built out my team of developers, I continually refer back to my experience of being interviewed by and performing interviews for Amazon. I've been feeling a lot of frustration at Ruby Kool Aid - and not for the usual reasons at all. The real annoyance for me is just like Republicans cloaking themselves with the flag while they systematically looted the country for 25 years and sent it to hell, Ruby foamers think they know how to write good software because they can bang out a RoR site quickly. The reality is that the Ruby scene has become densely populated with a large number of charlatans who are just like the sucky php and perl hackers from days of yore: array bashers and hash smashers who put 2000 lines of junk in a controller and call that agile high quality scalable code.

I've had 2 major problems with software in the past: unmaintainable code and performance. Sooner or later, when enough people are pounding your website at the same time, you'll have performance problems, as any decisions you made that are suspect will get grossly magnified and you'll have to do some careful analysis and get it fixed. I don't care if you write in Java or C# or RoR, this will be true. But if you wrote good maintainable code that follows principals, it again doesn't matter what language you wrote it in; you can fix it. And the reality is, regardless of technology, most software gets thrown out at this stage due to the steaming shit pile condition it is usually in by the time performance becomes an issue. Just like any other solution, RoR doesn't and can't force the desperate hackers to write good code; but for those that know what they're doing, they can write well-designed software in any language or environment (well maybe except php hahahaha just kidding).

This was the Amazon way of finding talent. You looked for people who could solve problems quickly, efficiently; who could handle the stress of a day of hard problems; who liked to bite their teeth into a challenge; etc. They were language agnostic in the interview. You could write any kind of pseudocode you wanted. It was all about well-formed thought under pressure. This of course was because the existing code base was so bad that you had better be able to fix super gnarly problems after getting paged at 3am but that's another story.

I swear I will never become an evangelist for any type of technology. I will always promote developers delivering high business value software that achieves the objectives. I think if you are still in the software game in your 30's and beyond, you get bitter -- I mean ok everyone who makes it out of their 20's in one piece is going to be a little bitter -- and you kind of keep on fighting last year's war. I think a lot of java veterans who are now Ruby nuts do so because of spending years and years working on million-line J2EE projects from hell that were designed by management and not developers. Again, Ruby isn't the solution: the solution is letting engineers design software that delivers business value.

The true war I fight and the true problem with the profession is the never-ending gap between business stakeholders and implementation teams. Both sides need to develop a shared understanding of business value and then go implement it. Now in Rails' favor, you can get a lot more done quickly to get something up and running in Rails, absolutely no doubt about it. The other day I was messing around with Apache Axis2 as I fantasized about replacing ActiveRecord with a bunch of Web service calls and a Java back-end, and I was immediately reminded of all the awesome things you don't have to deal with in Rails. There's quite a bit of fucking about just to get a java web service up and running. I think the challenge of desiging a well-formed API is just as hard in either language, but Rails lets you sketch it out a lot faster. Anyway I don't care how it gets done, in any environment, if you know what you're doing, you'll get 80% of the way there in a few days and then spend 3 weeks getting the last bits right.

No comments: