What in the world is the “Enterprise”
As developers, we hear the phrases “Enterprise Development”, “Enterprise Application”, “Enterprise blah blah blah” ALL. THE. TIME. and everyone seems to have a different opinion about what the “Enterprise” code is and how “Enterprise” is supposed to be. You keep hearing about the “ Modern Enterprise” and you see it with images like the one above to make it look super cool and modern, like a place you may want to work for. In all honesty, I think “Enterprise” is a code word for “shitty”.
If you’ve ever worked at a place calling themselves an “Enterprise” software company, perhaps you feel the same way, perhaps you don’t, but no matter how you feel about it, this article applies to you.
We need to stop using the term “Enterprise development” to describe “big ass company that has something to do with writing code”. I open my Google news feed every day and see article after article going on about “Enterprise Node.js” or “Scaling the Enterprise” but few places claiming to be “Enterprise environments” but most places that claim to be “Enterprises” are inundated with “Legacy code”.
This is another term that, I’m not sure if you could tell, bothers me. “Why does this term bother you so much?” you may be wondering. Well, let me tell you why dear reader: we’re being dishonest with ourselves and with each other. “Legacy code” doesn’t sound as bad as it is, because it’s another code word for “shitty”. More specifically it describes code that was once fine but has since turned into a giant pile of rotting garbage that’s too big and stinky to do anything about within the “acceptable” timeframe that the “Enterprise” people want. “It’s too big to change”, “It does too much”, “It would take too long”, “It’s simply not possible”, “Higherups don’t want to spend the time because it works now”. These are just a few of the excuses developers and managers use so they don’t have to do the hard work to make their code base and product better so it isn’t a giant pile of garbage. So it just sits there gathering dust and mold while developers continue to pile more shit onto it.
So let me lay out the “Enterprise” for you that I’ve talked about so far: you have a codebase that is usually anywhere between 5 to 15+ years old that “works” (in the loosest possible sense of the word), a bunch of developers who claim not to know how the damn thing works, and no one motivated enough to do anything about it. New developers will be learning this old ass code and whatever old ass practices they used to create it so when they ultimately get tired of the crap and want to leave they can’t because no one is hiring them because they don’t know how to operate in the modern world and if a different company does hire them, they’ll be going into the same old crap.
What I’ve laid out there seems very bleak and some of you are thinking “Well this can’t be EVERY place” and you would be 100% right. There are tons of larger companies who are doing the hard work of refactoring their legacy code, modernizing their standards and practices, moving to the cloud (I’ll touch on the cloud later in this article), etc. Doing this is not easy and it isn’t cheap either, but it is absolutely necessary. I once worked at a place (literally like 2 or 3 years ago) that installed Windows Server 2000 boxes at their client’s site. “Why in the world would they do that?” you may be wondering, and it’s a good question. Well, you see reader, they made a few mistakes along the way. Their codebase was about 12 years old and, at the time it was written, was only designed for running on THAT specific version of Windows server. As time went on, Microsoft released new versions of Windows Server (as they generally do), but as they were upgrading we were not. So it’s around 2015–2016 and we’re using Windows Server 2000 boxes, a codebase that’s way too old, and a team of people who don’t know how to fix it and, quite frankly, don’t care. At this point, you also may be asking “Well maybe they don’t need to fix it” and you would be very wrong about that. There is a reason that companies like Microsoft release new versions of Windows and tons of updates and that’s because of a little thing called SECURITY.
Windows Server 2000 became fully unsupported by Microsoft around 2004, which means that for around 12 years (and, to my knowledge, they haven’t done anything about it yet so it’s still going) they installed boxes with extreme security flaws at their client’s site. To me, that’s disrespectful and dishonest because the clients don’t know that they are using bad practices. They don’t have the knowledge to understand that, instead of installing a steel barrier between potential bad actors and their business, they installed a block of swiss cheese.
I mentioned the cloud earlier, and I want to be very specific about this topic. I don’t think that every company needs to move toward the public cloud and in many cases, it wouldn’t make complete sense. For example, the company I mentioned previously wouldn’t have much of a use for the cloud. They installed automated factory equipment at client sites. You can see why the cloud wouldn’t make a ton of sense, and you can see why security should have been a primary concern. I used cloud earlier when talking about modern code and refactoring, but I don’t want you to think that you HAVE to do this to be modern. There are tons of people who would convince you that you have to move to the cloud, but you don’t. I do think that you should, at least, audit the use case for moving toward the cloud for 1 big reason: uptime. I’ll illustrate this with another example from my career.
Sometime after leaving the previous company I mentioned, I went to work for a different company that knew they had an old codebase and wanted to refactor it or even start from scratch. They had their own servers hosted in a few different datacenters. Their servers were a little old, and they were in the process of buying new servers. We needed to be able to scale our main database so we needed more servers. This was kind of a big issue because during a year we would have a high number of outages. Many of them were due to the server warehouse our servers were in, and a few were due to the fact that our database design sucked and our monolithic application would break often (hence the reason they wanted to modernize or possibly start from scratch). They ended up buying bigger and better servers (spending a few million on the machines and the installation) but we still had tons of outages. Our servers were no longer the problem because they were handling the database and the application well while we were refactoring, but the datacenters still kept going down. So we spent a few million dollars really for nothing because we didn’t solve the root issue. Now we could have moved to a different data center and spent more time and money working out a deal with that datacenter and then physically moving servers over and getting everything set up, OR we could have simply put all our shit in the cloud where databases scale automatically and our downtime is very limited as we can leverage the massive size of companies like Google, Amazon, or Microsoft. It would have been a lot cheaper considering our time and the actual cost of our data centers and servers.
I’ve covered a lot in this article, and to some, I may seem a little salty. I don’t mean to come off this way, but I am a little upset with a lot of the practices and terminology we throw around without really thinking about it. I could have gotten stuck in a serious rut with my career had I just rolled over and accepted this Enterprise mumbo-jumbo. Instead, I decided to ask questions, continually learn what the world of software development was heading, and educated myself on modern principles and best practices. That is really the point of this whole thing: don’t just roll over and accept something that is wrong because someone says a word like “Enterprise” or “Legacy code”. When we decide to educate ourselves and ignore bullshit like “Enterprise this” or “Legacy that” and just write good code.
If you’ve enjoyed this article I’d love for you to join my mailing list where I send out additional tips & tricks!
If you found this article helpful, interesting, or entertaining buy me a coffee to help me continue to put out content!
