The Problem With Modern Software Architecture

Darko Klincharski
tarmac
Published in
7 min readFeb 1, 2022

Today is more true than ever that everyone is in a rush. That is even more accurate when you put it in the context of software. Everyone is rushing to be the next Amazon or the next Uber, or just to be this unicorn startup that would get millions and maybe even billions in funding to do explosively rapid scaling and take over the world. And that is exactly where the problem lies. Rarely ever do you see these software startups being set up for success from the start.

Photo by Valery Fedotov on Unsplash

More often than not, software companies nowadays are started on the premise “let’s get something out there and get investors, and then we’ll do it right”. Guess what, the time to do it right is before you get investors, simply because once you do, you will be scaling so hard there’s not gonna be any time to look back even on your progress from the last sprint, let alone the pre-investment era. I think I came up with a good analogy here so bear with me here a bit.

The Steam Train Surmise

Imagine you are the stoker on a steam locomotive and you are parked right now. Starting a new software product is like getting a locomotive moving. You attach all the wagons, light the fires, you get it heated up, smoke starts coming out of it, and while the fire is slowly raising the temperature, you take some time to turn around and check if your shovel is there next to you, to check if you stocked up on coal, if your train whistle is working, etc. Once you get the first centimeter of movement your product is out there and there’s no going back. As soon as you develop inertia, there’s no stopping from there. From there on onwards, if your shovel breaks, you gonna be throwing in coal by hand, kicking it in like a football. If your whistle breaks, you will be shouting at the top of your voice, if you run out of coal you will be throwing in your clothes, the shovel’s handle, and basically anything flammable within your reach.

Photo by Adryan RA on Unsplash

So now, you have your train rolling one way or another. People come in, see your train is moving they like the destinations and decide that they want to invest in you so you can add more wagons, so you can transport more people meaning extra profit. At this point, most stokers are so high on the adrenaline rush of getting the boost in their business they fail to see the problem that they are about to face. Most investors want to see the wagons attached while the train is still moving at top speed. You can’t stop, because if you stop another train might overtake you and that’s no good for business. So, you keep shoveling and the wagons get attached, but more wagons, means more weight that needs to be pulled and that means that the steam locomotive needs more power. How do you get more power?! By shoveling more coal into it. But you convinced the investors that the train is rolling just fine with you behind the coal chute so nobody invested in a second stoker. And because you’ve done it so efficiently so far, there’s also no need to automate and modernize it. So, there you are, covered in sweat, black as night from the coal, panting like a dog in a summer heatwave and you see on the tracks parallel to you the same exact train, with the same (or similar) setup of wagons, but the stoker in sitting in a chair sipping on a coffee and enjoying the view, just because he got his kids’ backyard slide and put that between the coal wagon and the chute and he installed a trap door operated by a shoelace that he pulls on every few minutes, all from the comfort of his seat. Do you see my point?!

Both of them are competing in the same business. The difference is one of them can make his life that much easier. It’s not like the second stoker solved all the potential problems of running a steam locomotive, but he took just a tad bit more time at the start to think about what would be hardest for him and take simple measures to ease things up for him. Of course, next to him is the major corporation or a mogul who bought a maglev train and put that on the same track, and you can't really compete with that, and no one is expecting you to. But if you can leave time to focus on the other things in your product you might get something out of it. Maybe instead of selling transport, now you can sell experience. Yes, your train is slower than a maglev but yours is more authentic, it gives people an experience, by narrating the surrounding, by serving something more than extremely salty peanuts packed in a majorly oversized bag which only forces you to buy that extremely overpriced bottle of water as if it was filled by melting ice that was formed 10000 years ago when there was no pollution.

The Redesign Topology

I think I spent too much time on that analogy, but the bottom line is that that same principle applies to today’s software architecture too. Most companies just want to get a product out there in any shape of form. They don’t think about automation, maintainability or manageability, or anything of the sort. It’s all about the software features and how it looks for the users. I have seen it over and over in my career, the famous big meeting scheduled a month in advance with a big SAVE THE DATE email as if they were going to announce the end of world hunger on that call. So, you go to that call, and they announce they are stopping all work on the current product and they are making a full redesign. And yes, redesign of the UI. It’s always the UI and the UX. Then you wait for the Q&A session at the end of the presentation and you ask a very simple question: “What is this new software going to run on?” and the answer is almost always “well, we were going to reuse the same infrastructure, just replace the code” and you are using every bit of your self-control to not flip the desk in front of you and just storm out of the room. This happens because every decision for a redesign always comes from a team of managers who are not necessarily technical people but did a few surveys and focus groups and found out that their brand is not recognizable enough and they need to get something to show to their managers on the next annual review. And a new UI screenshot always looks nice on a presentation.

Photo by Lukas Blazek on Unsplash

You know the saying: “stop and smell the roses”, in this case, I would rephrase it “stop and listen to the servers”. All you gotta do is listen. Once you have worked closely with a proper infrastructure team (DevOps, SecOps, Platform, whatever you want to call it), you unlock a new sense for software infrastructure. You can hear the cries of the databases that are smothering in garbage, the panting of the overworked server that has been running for a decade without a day off or an upgrade, the “ka-ching” sound of Amazon’s cash register every time you don’t clean up your deprecated resources, the muffled screaming into the pillow of the engineer on-call just because PagerDuty triggered on a Friday night by someone deciding to fix this one little thing in production before going to bed.

Photo by LOGAN WEAVER on Unsplash

The Velocity Renormalization

I guess what I’m trying to say is: we need to slow down. Don’t get me wrong, I know that’s not how the world works. Money makes the world go round and currently, there’s no other place with more money in circulation than software. But, this is a ticking time bomb. How long before another Friday night fix, shuts down a nuclear reactor, before an “easy access” server gets hacked and takes control over a government satellite. Well, I hate to break it to you but that has happened so many times now everybody just stopped counting. But you know when they are going to start counting again?! When one of these events has a catastrophic consequence; when it costs people’s lives. So, I now speak to all the people looking to start a new software company, please, oh please, I beg you, slow down. Take the time to speak to everyone you plan to have helped you realize your vision, especially “low-level” engineers. Set yourself up for success from the start, so you don’t end up kicking coal into the chute naked.

--

--

Darko Klincharski
tarmac
Writer for

DevOps Engineer @ https://tarmac.io/ Automator of deployments, manager of infrastructure, watcher of logs, optimizer of databases, player/inventor of games…