Why it sucks to be an in house programmer
Tuesday, December 4th, 2007
Joel Spolsksy presented to the Yale Computer Science department on 28 November 2007 with a talk about software development and his experiences. Rather than do a standard save to this month’s del.icio.us bookmarks, I wanted to dedicate a full post to it as it resonates so well with my current situation.
“you might find yourself working on in-house software, by accident, and let me tell you, it can drain the life out of you.”
So why does it suck?
“Number one. You never get to do things the right way. You always have to do things the expedient way. You’re not going to [be] allowed to build things with Ruby on Rails no matter how cool Ruby is and no matter how spiffy the Ajax is going to be. You’re going into Visual Studio, you’re going to click on the wizard, you’re going to drag the little Grid control onto the page, you’re going to hook it up to the database, and presto, you’re done. It’s good enough. Get out of there and onto the next thing.”
First I should point out that I don’t actually do .NET programming. Our programmers were made redundant last year and me and my one remaining colleague have yet to receive any kind of support to plug the skill shortage. We have another guy who can write PHP in the support team but we can’t realign to deliver solutions using open source technology based on PHP / mySQL. We can’t even deliver a blog because we don’t have a LAMP infrastructure and we certainly don’t have the skill to implement a .NET solution either. We’re not empowered to do anything about it. I’ve snuck some jQuery into our Intranet and that’s as good as it gets. Ajax? Ruby on Rails? Yes, very cool. Would be nice.
“That’s the second reason these jobs suck: as soon as your program gets good enough, you have to stop working on it. Once the core functionality is there, the main problem is solved, there is absolutely no return-on-investment, no business reason to make the software any better. So all of these in house programs look like a dog’s breakfast: because it’s just not worth a penny to make them look nice. Forget any pride in workmanship or craftsmanship… You’re going to churn out embarrassing junk, and then, you’re going to rush off to patch up last year’s embarrassing junk which is starting to break down because it wasn’t done right in the first place. So, the number two reason product work is better than in-house work is that you get to make beautiful things.”
We have some ugly, poorly-designed web apps. Apps that handle things like surveys and feedback are a nightmare to configure because the initial scope and deadline was so tight they couldn’t be thought out properly so as to be flexible or extendable. “It can’t carbon copy the form submission to the sender?” We get bitten on the arse and made to look like fools too often. It wasn’t our former colleagues’ fault. It’s the circumstances, the management environment they found themselves working in. Ugly? Isn’t that my job? Yes, but you have to be given project time first. I deliver professional, minimal and clean design with consistent CSS treatment of typography and vertical rhythm and semantic, accessible markup but a website takes more than two days to put together because design is not all about the code either.
“Number three: when you’re a programmer at a software company, the work you’re doing is directly related to the way the company makes money. That means, for one thing, that management cares about you. What I was used to from the west coast was an attitude that management is just an annoying, mundane chore someone has to do so that the smart people can get their work done. Think of an academic department at a university, where being the chairperson of the department is actually something of a burden that nobody really wants to do; they’d much rather be doing research. That’s the Silicon Valley style of management. Managers exist to get furniture out of the way so the real talent can do brilliant work.”
Well, I have experienced this in-house before—and how lucky I was I see now—in my previous job as an intranet developer using PL/SQL and Oracle Portal (awful product though). We actually had deadlines that allowed for quality, testing and documentation. We solved internal customers problems and innovated by further streamlining established workflows. The department boss was a geek like the rest of us—with a sympathetic ear, wise words and a sense of direction.
I want that back before I lose my soul.
Technorati Tags: Joel Spolsksy, software development, work environment, job satisfaction