In-House Software, The Problem – Linux Liaison

In-House Software, The Problem

If you’ve ever worked at a company that has needs specialized enough to require in-house software, then you know how much of a pain it can be to not only use it, but also to support it. In-house software, because of its nature, is often underdeveloped, full of quirks that no end-user would want to deal with, and best of all, ugly as all hell.

First of all, let’s go over what in-house software is and what types of requirements are there for it. In-house software is a piece of software developed by a company for use within the organization. This means that the developer(s) know the exact hardware configuration, the platform that’s to be developed for and even a general idea of the knowledge level of those intended to be using the software. Even with all of these variables nailed to the floor, there’s still the hurdle of making the software resilient enough that a V2 isn’t necessary and that random bugs don’t pop up as often as is acceptable in software intended for public use. 

What this type of resilience means is using development platforms such as Java or older versions of Internet Explorer, or even older libraries, to base the in-house software on. If you’re familiar with software development, you’ll know that older software bases are closer to not being supported anymore. While it’s more reliable now because the bugs found in the initial releases for these platforms and libraries have been squashed, down the road support for these libraries and platforms on future operating systems (such as Windows 10) can be almost non-existant*.

So we use resilient software, which eliminates bugs in the short run, but once the end of life dates pass us by, what does that look like? At the hospital I work at, that looks like absolutely requiring an older version of Java, and other pieces of software have to use that version too. That looks like having to set printers as default in Windows (not the application itself) just to be able to print to them. That looks like printing not even working if the phase of the moon isn’t correct and the planets aren’t aligned. This of course isn’t exclusive to in-house software, it’s true of most pieces of legacy software that’s been transplanted from one OS to another.

This is why virtualization and containerization is so popular these days. With these solutions you can control the environment within which the software runs. You can specify the Java version and deploy an application to work in its own environment where it only sees what’s necessary for it to run, and another application can run alongside it using a completely different environment. 

Back to the topic at hand, you might also find that in-house software is not only ugly, and particular, but also quite hard to use.

[U]sability is a lower priority, because a limited number of people need to use the software, and they don’t have any choice in the matter, and they will just have to deal with it.

Joel on Software – Five Worlds

I’ve experienced this first hand with our ticketing system. You’d have to do the thing, to get this thing to work, to in turn be able to access this other thing, and it’s a whole rigmarole just to get to the “Print Ticket” button.

So what’s this all for? Is it because the developers care so much to make it work the best possible without fail? No it’s because the companies that hire them don’t give them enough time or money. Especially with public institutions, every single dollar has to be accounted for. Every minute needs to have at least a few lines of code dedicated to it otherwise the project is either considered a failure or completely abandoned. And if the developers themselves are in-house, god help you.

The kicker? It’s always closed-source.

* Windows 7 Classic theme is one that doesn’t exist past Windows 7 and the underlying infrastructure for it was completely gutted out in future versions of Windows. Some applications require this infrastructure and as such would never run on Windows 10 without proper modifications.

My blog is self-hosted on a VPS running Ubuntu nested in Digital Ocean’s VPS service. If you want to get a VPS from Digital Ocean, I’d like to ask you to graciously use this referral link: You’ll get $10 in free credit (2 months worth of the lowest tier VPS) and once you’ve spent $25 of your own money, I’ll receive $25 myself, meaning that you’ll be indirectly supporting my blog.

2 Comments Posted

  1. I can definitely relate to this being the developer and also the user of in-house software. The thing we built was just made to “work”. The user experience wasn’t the worst but it sure wasn’t optimized for the work it was supposed to do. People used to work with it all day long and only got so much done. Fortunately we had more developer interns come in who were given the job to improve the state of the software.

    • I find interns are generally unappreciated. They bring a fresh view into the business. They have the guts (or stupidity) to speak their mind! They have the courage to propose (or repropose) changes that should have been made a long time ago!

      But yeah, I didn’t even go over optimization. One piece of in-house software here is so slow, it takes 1 minute full just to log in, and another minute to finish setting up the patient database list on the screen. Though I suspect some of this is the network.

Leave a Reply

Your email address will not be published.


This site uses Akismet to reduce spam. Learn how your comment data is processed.