L-P Huberdeau

There are good and bad places to work at. Recently, Joel Spolsky spoke against internal software development. Of course, he was pitching to students and hoping to get them to apply to his own shrink-wrap software company, but I think saying all internal software development is a bad job to have is just plain wrong. I spent most of my career working on internal software. Recently, I worked on shink-wrap. I completely agree that if all you do is assemble components and plug them to a database, your job is boring, but there is a lot more to internal software development than simply plugging components together.

The main argument is that, working for internal software, the goal is not to achieve very high quality, but rather to push out as many features as possible and repair last year’s junk. Sure, that does sound like the feeling, but that’s not related to internal software development at all. Any understaffed company will do such things. Even in shrink-wrap, you find deadlines, cut corners and suffer from the previous releases corner cutting. Sure, there is no way you will spend a month polishing a GUI aspect for internal software. When you are alone on a project, it’s quite hard to justify. That polishing is simply not worth doing based on the returns - just like finding the perfect algorithmic solution.

The huge advantage of internal software is rapid feedback. Sure, the final result is not polished, but it does make Brian happy, and he thanks you for it every day he comes in to work. During my first internship many years ago, I was at the Canadian space agency working with the mission operation software analysis team. They were working on software for the canadian components of the international space station and I was working on tools to help them. I ended up working on a project named Q*BERT (we did get to have funny names for internal software, and figurines to represent them) after a few weeks in. It was a complete new development. It started small just to display some search results in a way that made sense for the system. It ended up as a complete document navigation system based on result parsing (just a few regex in the end) and had the capacity to attach meta-data to the document. At some point, it also aggregated meta-data to produce reports. The end product was so far from the original purpose, but the amount of time it could save to it’s half a dozen users could not be estimated.

Was it perfect? Of course not. Was it a maintenance pain after I left? Probably - I was fresh out of college, can’t expect miracles. Are they still using it? No idea.

Q*BERT could not be shrink-wrap. It was too specific. If your business is based around knowledge workers, you need someone building internal software to support them. No single solution packaged out there can fit all their needs and their preferences. No external vendor can be close enough to answer their specific needs and save them those precious work hours.

The whole point is that working for internal software can be just as thrilling as working on high-end video editing software. It’s just a different kind of work. As long as you get enough interest to get up in the morning and do the work you have to and enjoy the day, any environment can be good. You might not get the satisfaction of creating a nice Web 2.0 application that every teenager loves, but you will get the satisfaction of helping your company offer better services and be more efficient.

An other great thing with internal software development is that you get to learn a lot. You get to work on the entire software lifecycle. You learn about the domain. You learn about the business objectives. You get to do some project management, or get very close to it. The job is not just about programming, and it won’t get you the carpal tunnel syndrome any more than an other programming job. I would say that the job generally offers more freedom. The software produced is only going to be used internally. You’re likely to be the only developper working on it and your boss has no idea what the difference between Java and PHP is. You could as well try that new project in Rails if you care. As long as it works.