The One Feature Built Different
A stable system, a decade of experience, and one decision to be interesting.
The application was built in 2005. WebForms, the way everything was built then. It was a work order automation system I’d helped build, and by the time this happened it had been running in production for years. Large, stable, understood. Every screen worked the way every other screen worked. A developer who had never seen a particular corner of it could still find their way around, because there were no particular corners. It was all one thing.
I had been writing software for ten years.
The feature itself was small. A new piece of the workflow, the kind of thing the system absorbed a few times a year without anyone noticing. I could have built it the way the rest of the application was built. I knew how. I’d done it a hundred times, and that was most of the reason I didn’t want to.
The standard approach would have worked, and it would have taken an afternoon. Some part of me had started to read that as the problem rather than the point. Doing the known thing felt like going through the motions. Reaching for something new felt like doing real work. I told myself the feature would be better for it, more responsive, more capable, and there was a version of that I could have defended. It wasn’t the version I was actually running on.
I reached for Ember. It was new then, one of the first JavaScript frameworks promising to make the browser behave like an application instead of a document. I wired it into the feature. I added a build step to our process to minify the JavaScript, tooling that had never existed in our pipeline because nothing in the pipeline had ever needed it. On my machine it was clean and fast. It felt like the right kind of modern, the kind you can point at. I was pleased with it.
It went to production and could not carry the load.
This was an intranet system. We controlled the browsers. We controlled the machines, the network, the whole environment end to end. There was no hostile variable, no user on some ancient laptop to point at. It was a closed room, and inside that closed room the feature buckled under the volume of data the real workflow ran through it. The thing that moved fine against a handful of test records would not move against what the job actually required.
The load problem was immediate. The other one took longer to surface.
The application had been consistent, and now it wasn’t. There was a single feature that didn’t work like the others, built on tooling nobody else had a reason to know, sitting inside a system whose whole value was that you never had to relearn it from one screen to the next. Anyone who needed to touch that feature had to stop first and learn a framework, a build step, a set of conventions that lived nowhere else in the codebase and served nothing except the feature I’d decided to make interesting. Every hour someone spent in there was an hour the rest of the system had never charged anyone.
So I took it out. I rebuilt the feature the way the rest of the application worked, on the tooling the whole team already knew. It did the job.
The people who had signed off on the timeline were not glad to spend weeks rebuilding something that had already shipped once. The client, who I’d had a good relationship with, was cooler with me afterward than before.
The rebuild took the better part of a few weeks, and at the end of it the feature worked exactly the way everything else in the application had worked the entire time.
👉 If you enjoy reading this post, feel free to share it with friends!
Or feel free to click the ❤️ button on this post so more people can discover it on Substack 🙏
You can find me on X and Instagram.