This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: Where Graham gets it wrong
Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants
Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml
Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general.
Everyone and his brother has commented on this essay by Paul Graham. Most of the commentary has been positive; Eric Sink is one of the few who's had a contrary opinion. I've been looking at the essay, and I have to say that I've got a few problems with his essay myself. Let's have a look at his notion of why you want hackers (as he descibes them, top notch developers):
It's pretty easy to say what kinds of problems are not interesting: those where instead of solving a few big, clear, problems, you have to solve a lot of nasty little ones. One of the worst kinds of projects is writing an interface to a piece of software that's full of bugs. Another is when you have to customize something for an individual client's complex and ill-defined needs. To hackers these kinds of projects are the death of a thousand cuts.
Ok, let me be extremely clear here - he's full of crap on this. What he's saying is that problems that actual users care about are uninteresting. This doesn't really jive with his assertions that startups are a great place for hackers. Why not? The best startups (you know, the ones that succeed) - pay attention to their early clientele. In fact, they often build stuff more or less exactly to the specifications of their early clientele. The minute you stop fulfilling end user needs is the minute you stop making money.
Now, Graham's assertion is that you can "protect" your great hackers by having them build "tools". That sounds nice - until you ask: "Who are these tools for"? Well, they are going to be for some set of users (Internal or external). If your hackers aren't paying attention to the users, then they are going to end up building a bunch of over-architected crap that no one wants or needs. Trust me on that last point - I was at ParcPlace, and got exposed to plenty of "hackers". We had some really brilliant people back when I joined ParcPlace in 1993 - and the ones who Graham would call "hackers" were typically the least useful developers. They would wander off and build things they thought were highly interesting - and that no one else wanted.
I recall one of our hackers touting some great browser extensions he had in 1994. I publically ripped him a new backside - because he had done all the work on the legacy browser, not the new one that was coming out for VW 2.5 (in the then new GUI toolkit). This would be the equivalent of one of our (Cincom's) engineers proudly touting some additions to the GUI builder (current) after Pollock had shipped. Cool? Maybe. Also completely useless.
That's the trouble with Graham's idea of a hacker. He elevates the sort of developer that lives off in the clouds, building their own idea of perfection without regard to what anyone else might need. You know what? I don't need that kind of guy on my team - Graham can keep him. I want the kind of people we have on the Cincom Smalltalk team now - extremely bright, highly motivated developers - who listen and respond to customers. Are they perfect? Heck no, no more than I'm a perfect Product Manager. We know who pays the bills though. I'm not sure Graham gets that part.
Here's exactly where he gets it wrong:
The distinguishing feature of nasty little problems is that you don't learn anything from them. Writing a compiler is interesting because it teaches you what a compiler is. But writing an interface to a buggy piece of software doesn't teach you anything, because the bugs are random. So it's not just fastidiousness that makes good hackers avoid nasty little problems. It's more a question of self-preservation. Working on nasty little problems makes you stupid. Good hackers avoid it for the same reason models avoid cheeseburgers.
Bull. I'd actually say it's almost completely the other way - if you go in and fix the nasty, stupid UI bugs you learn something about what your users (you know, the people who pay your salary) want. You learn the difference between adequate work that people accept and great work that makes people happy. Look at the difference between the VW tools in VW 5i.2 and every release since then, for instance - the "polish" that's been added (mostly by Vassili) has been more important in many respects than the added functionality. Appearance matters - a nice UI differs from a bad one in the same way that a person with a shower differs from the one without - while a shower doesn't make you any smarter, it certainly makes you easier to be around. Save me from developers who don't want anything to do with the user community. I'll happily load down any of my competitors with them.
Previous Topic
