In House Software vs. Software Companies (BoIB)

Originally posted on December 4, 2007 on the internal blog:

Joel Splotzy has two new posts where he provides the transcript of a speech he gave at Yale. The basic premise is his career and how he got to be where he is.

It's quite interesting, and quite frightening. I've seen some of the places he's talked about when he goes off on the "80%" of programming jobs that deal with in house software.

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 learned in CS323. 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, twenty-seven years of that and you get a gold watch. Oh, and they don’t give gold watches any more. 27 years and you get carpal tunnel syndrome. Now, at a product company, for example, if you’re a software developer working on a software product or even an online product like Google or Facebook, the better you make the product, the better it sells. The key point about in-house development is that once it’s “good enough,” you stop. When you’re working on products, you can keep refining and polishing and refactoring and improving, and if you work for Facebook, you can spend a whole month optimizing the Ajax name-choosing gizmo so that it’s really fast and really cool, and all that effort is worthwhile because it makes your product better than the competition. So, the number two reason product work is better than in-house work is that you get to make beautiful things.

One of the interesting things about this segment is the assumption that working on Products actually means that you're going to implement something that makes it better for your user. Sometimes, you make it better for your backend, which is far less glamorous than working on the frontend. Sometimes cool features get cut because, your customers aren't ready for it. I can think of several products which took several years to incorporate cool javascript gizmos, let alone Ajax gizmos because our customers were not ready for it. In essence, a segment of the customer base doesn't want the product they integrate into their online presence to look better than the rest of their online persona. There are customers who I've worked with who use older technology in 10% of their application simply because they aren't ready to fund the upgrade to the newer stuff.

It's unfortunately just not that simple in every instance.

Joel also comments on management styles when recalling his time at Juno:

Eventually, though, I started to discover that the management philosophy at Juno was old fashioned. The assumption there was that managers exist to tell people what to do. This is quite upside-down from the way management worked in typical west-coast high tech companies. 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.

My first question here is, who decides if the investment is worth it? I suppose if you're a startup with a ton of angel funding, it doesn't matter if it's worth it to upgrade gizmo X. But if you're a software services company, it does matter. If contracts are written in ways where it really doesn't matter if you create gizmo X because no one's going to pay to upgrade to it, then you probably aren't going to do it. Someone has to manage that. It's not a chore in this case. In this case it's paramount to the survival of the company that allows you to create cool gizmos. Someone has to understand the customer and what brings in the coin so that the correct gizmo X Y or Z can be created.

Joel is a bit simplistic in his view because he makes the assumption that you're always going to do what's cool working for a software company. You will do cool stuff quite often, but in many cases, you aren't. You're going to do what provides the best return on investment for our customers. It's not always glamorous, but it's what keeps you employed. You need management because you need to sell product. Yes, managers should help to get furniture out of the way, but they also need to be smart enough to step in when the team is floundering and not making the decisions needed to be successful.

I do agree with Joel on one thing, however. In house software is not as fun as working on software services. Software services gets you working with internal and external clients. It's challenging and keeps a set of social business skills nimble that you might otherwise neglect.