The Development Abstraction Layer

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.<p>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.<p>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.)<p>I've written more about this, so I guess I should just link and be quiet. Thanks for listening.<p><a href="http://startuplessonslearned.blogspot.com/2009/04/built-to-learn.html" rel="nofollow">http://startuplessonslearned.blogspot.com/2009/04/built-to-l...</a>

<i>Actually Microsoft has pretty terrible marketing. Can you imagine those dinosaur ads actually making someone want to buy Microsoft Office?</i><p>He's confusing marketing with advertising, a tiny portion of the marketing process. From Wikipedia:<p><i>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</i><p>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).

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.<p>The thing is that <i>what</i> 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.<p>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.<p>Programmers don't need an implementation layer, they <i>are</i> the implementation layer.

Unbelievably beautiful essay. Midway through my heart sank in despair, then I was awakened by a logical argument.<p>Well worth reading.

Translation: come work for us, because if we deign to hire you, we'll treat you like the young god you are.<p>Joel knows marketing. 'nuff said.

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?

I really like the analogy with SVN and the air conditioner though.<p>I sounds like big company logic to me though. A Startup would just pay 6.95 per month to host their SVN repository.

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.<p>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).

I love this article, although it also discourages me. How could I possibly create such a company? How could I ever find one?<p>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!<p>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?

One should learn to sail in all winds.

Is this "news" if it is almost 3 years old?