Twenty years ago this spring, I started my first “real” job at a local IT company. I was hired as Support, but it wasn’t the burger flipping, minimum wage earning, soul sucking Support of a monopolistic ISP help desk. This was Enterprise Support. I worked the same eight hours, at the same desk, Monday to Friday. I got to know the customers, their use cases, their workflows, and their work habits. I learned the difference between strategic customers and everyone else. I learned to work without a pre-written script.
In the three years I was there I learned a ton, and memories come and go, but the one thing I always remember was this:
At one point we had started receiving a lot of customer tickets around sluggish performance and Java out of memory errors.
With the customers grabbing pitchforks and lighting torches, we finally had a meeting with the VP of Development and one of the senior Developers. We explained that the issue which was plaguing the customers was a particular feature (if I recall, it was a report of some sort) was, once invoked, slowing down the entire app and as the day went on, the whole system would just start to error out with java.lang.OutOfMemoryError messages. Restarting the servers every night seemed to give relief, but the next day it would start all over again. This was true for both our hosted servers (which were now being restarted every night) and the servers of our on premise customers who had logged tickets with us (and who we had instructed to restart their servers every evening).
After some discussion, the senior Dev stated, quite confidently, that the issue was simple to solve. “It’s running out of memory, so just throw more hardware at it until the error stops.”
The VP looked at him and in a very level voice said: “No. That’s lazy. If it was coded properly in the first place, it wouldn’t be running out of memory.”
He then instructed the senior Dev to optimize the code until it ran on on the bare minimum server requirements that we stated it was supposed to be able to run on for any on premise customers, and that would more than suffice for our hosted servers now, and in the future, and any customers servers to boot.
The senior Dev, grumbling, went off and did just that. If I remember right, it took him the better part of a week, but he did it. We kept the customers at bay with promises of a fix, and when the new code was completed, tested, and pushed out, it was pretty glorious. The sluggishness vanished and the java.lang.OutOfMemoryError messages were nowhere to be seen.
After having witnessed this it burns my ass that, to this day – a time where even the cheapest of consumer computing hardware is so insanely more powerful than the servers were twenty years ago were, the experience for a huge percentage of the population is absolute garbage.
I’m not a Developer at all. I can write some mean HTML and am pretty okay at CSS, but that’s it. Code just does not click in my brain in the same way math doesn’t click for me, so I’m not gong to stand here and even pretend to know what’s going on with code. What I do know is that I’ve experienced, first hand, a major software performance issue fixed because a VP told a Dev to optimize lazy code rather than just throw more hardware at it until the problem went away. This proved to me that it could be done.
This is what DeepSeek showed the world this week: convincing everyone that all you need is more hardware and more money is lazy.
That’s us though. It’s all about releasing more new features. It’s about pushing code with an “acceptable number of bugs” and questionable performance out to paying customers. And if there is any kind of bottleneck, you can always just throw hardware at it until the issue goes away… but it never really goes away.
While you theoretically can to fix a clogged toilet by making making the bowl bigger, it will just keep right on filling with shit.