The Development Abstraction Layer
joelonsoftware.com
Is he really correct about Microsoft creating that illusion? It just doesn't fit the idea of M$ I have.
joelonsoftware.com
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...
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.
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).
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.
Well worth reading.
Joel knows marketing. 'nuff said.
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 sounds like big company logic to me though. A Startup would just pay 6.95 per month to host their SVN repository.
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. ;-)
For want of a localization the installer was done in-house.
For want of an installer the deployment process was done in-house.
For want of a deployment process the server set-up was done in-house.
For want of a server set-up the development was lost.
And all for the want of a localized word.
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).
"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.
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?
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.