I'm an incredibly big Joel fan, and I think this essay is really well written. But I find something patronizing about this approach, and I have seen in my work with startups that it can lead to disaster, even though I have seen it work in big companies.
Startups are inherently chaotic; we often don't even know what problem we're trying to solve. By shielding developers from this chaos, we can make them more "productive" but are they really contributing to the company's success? I'm not sure they are.
I'd rather enlist the creativity and original thinking of my developers to help find new insights about what customers really want. (Naturally, buying chairs and moving desks is not in this category.)
I've written more about this, so I guess I should just link and be quiet. Thanks for listening.
Agreed. But I don't think he's really advocating shielding programmers completely from the sales process, or from customers.
He does say:
some patient tech support saints who help customers get the product working and help the programmers understand what problems are generating the tech support calls
I think it's nice to shield developers from the chaos of the air conditioner installations, but feedback based product development is definitely something they should get involved with.
It's harder with startups, of course, because if you have limited cash, you can only hire a limited number of people and those people then have to do everything. Not sure how FC (and even 37s) handled this when they were small (in revenue) and couldn't just hire support staff to create this development abstraction layer. I think just dumb luck had a lot to do with it, though.
In a startup, there's no one trying to shield developers from nothing, because developers are all there is. There are no more employees and developers do all the "other" work besides developing. If there is someone to daycare developers, then the startup has probably already figured out what problem they are trying to solve.
The assumptions that programmers are there to lead the way, and the rest of the organization is there to make sure they can do so is flawed, IMHO. Microsoft didn't get to where they are today because Bill G. is a great programmer, but because he is a great businessman. The fact that he's a hacker certainly helped a lot, but without his business sense (and a few lucky breaks) he wouldn't have gotten to where he is today.
The thing is that what you build is probably the most important decision a company makes, and the answer to that question is not something that programmers are uniquely qualified to answer. As a matter of fact many programmers live in a world that is quite different from normal people, and don't understand the fears, desires and motivations of normal users. Which you need to do if you want to answer the question of what to build.
Yes programmers are good at building things, and to use the yacht metaphor from the essay they should be in the engine room making sure the darn thing just runs. The one at the helm should be someone that understands business, people, marketing, and preferably technology.
Programmers don't need an implementation layer, they are the implementation layer.
Actually Microsoft has pretty terrible marketing. Can you imagine those dinosaur ads actually making someone want to buy Microsoft Office?
He's confusing marketing with advertising, a tiny portion of the marketing process. From Wikipedia:
Marketing is defined by the American Marketing Association as the activity, set of institutions, and processes for creating, communicating, delivering, and exchanging offerings that have value for customers, clients, partners, and society at large
Advertising is a tiny part of marketing. More important is developing the right products at the right time for the right market, and Microsoft does that very well (their bottom line proves it).
I don't really think joel needs an article like that to give young programmers the desire to work in his company. And that article makes some points going way beyond treating programmers as young gods.
Indeed. For example, he makes a comparison to the military—the military is an abstraction that allows soldiers to see themselves as fighting wars. But you all know, whether from experience or simply the media, how soldiers feel about what they do, and it bears very little resemblance to godliness.
I think it's slightly different marketing: as a programmer, you should be treated like the young god you are. Now that you feel good about us, you know who to call when you need bug tracking software.
It is marketing, and the article is a feel-good piece, but it's also true. I'm very happy that Joel has a way to align his interests with ours, and with truth.
I enjoyed the abstraction layer argument but I can't figure out what point Joel is trying to make about the lone MicroISV developer. Don't do it? Don't do it unless you can afford to hire a layer of sales and marketing at some stage? Do it, but don't be surprised that it fails and I told you so?
You'd be surprised how absurd things can get, even for a little startup.
Usually it starts with the need to customize one tiny little thing about the off-the-shelf offering. Then, you find that you have to install some new bit of software, which requires a new driver, which requires an OS upgrade...and before you know it, you're on a yak-shaving expedition that ends with a new data center and a rack full of equipment. ;-)
Isn't that a bit scary? I don't know anything about SVN backup practices, but what if they had a power failure? How protected are your crown jewels, at 6.95 pcm?
I appreciate the idea behind Joel's article--that developers need to have everything available to do their jobs and not be bothered by corporate minutia. The best software companies are organized this way. What I have always found dissatisfying by this sentiment is that it implicitly denigrates all of the other people in the "supporting roles" and it elevates the developers to prima donne.
I found his introductory parable somewhat compelling, as it mirrors, somewhat, the lives of many of us here. I only wish he would have focused more on how that lone developer could have succeeded with more "marketing" instead of diverting to track B and talking about how to successfully structure a small to medium sized company (like his).
But what's interesting is that Joel is pretty clearly making the point that he is the man responsible for making sure the "supporting roles" happen, allowing the programmers to assume allthe "prima donna" roles. In return, he gets to own the lion's share of the company and a commensurate share of the profits.
"instead of diverting to track B and talking about how to successfully structure a small to medium sized company (like his)."
Doesn't it make more sense for him to talk about the case of a small to medium sized company, which he actually knows something about?
I think, though, it isn't too hard to extrapolate the lesson for startups: if you are a programmer who formerly worked for a small to medium sized company, you suddenly need to figure out on your own how to do the jobs of that other 80% of the people at your company were doing. In fact, elsewhere I think Joel has made exactly the point that when he started Fog Creek he and his co-founder were the ones doing all of those tasks, in addition to the coding.
I understand that Joel's situation as a startup was pretty unusual in that he did the marketing first. Joel on Software was around for several years, and popular, before he decided to go into business rather than working for others, so he had a ready made market for the programmers' tools he started producing.
I love this article, although it also discourages me. How could I possibly create such a company? How could I ever find one?
His point about the second type of company touched a nerve: that's me, to a tee. It's an article from 2006, so the Great Ruby Rewrite in my case is the Great Clojure Rewrite - apart from that - ouch!
However, I don't see how having a Development Abstraction Layer in place will prevent programmers - being in charge - from making this kind of mistake. Isn't this exactly what happened to Netscape?
Every time it gets posted, it will be news to a group of readers that just joined, became interested and capable of digesting the article. 8 O'clock news is news for only a short time. A good article or essay can stay news for a much longer time.
Sometimes it may even take a while for something to become news: early 20th century philosophers already had sharp insight into the way we would be dominated by technology, but it took until the 80's for it to really sink in how right they were.
Startups are inherently chaotic; we often don't even know what problem we're trying to solve. By shielding developers from this chaos, we can make them more "productive" but are they really contributing to the company's success? I'm not sure they are.
I'd rather enlist the creativity and original thinking of my developers to help find new insights about what customers really want. (Naturally, buying chairs and moving desks is not in this category.)
I've written more about this, so I guess I should just link and be quiet. Thanks for listening.
http://startuplessonslearned.blogspot.com/2009/04/built-to-l...