The 10 000-line service
Towards the end of a release cycle of a large, enterprise-grade application I took a rare and long-planned week off with my family.
When I came back there was a small mountain of bugs, piled up by the testers. There was a deep backlog of merge requests and code reviews and 800 new emails, mostly from the bug-tracking system. There was a pile of help documentation and requirements specifications to review (or rewrite, sigh) plus a queue of requests from the sales guys and the boss.
I found also that my entire team of young developers had been taken away and diverted to other work.
So, early on my first day back, I'm digesting all the damage when a message pops from one of the sales/marketing guys. “So,” he says, “you must be pretty close to finished, with all that work that’s been going on. When can we release?”
F$&@!$?@!AAAARGGGHHHHHH !!!!!!
The subsequent conversation went something like
Me: “Let’s make an estimate. What’s n divided by 0?” Sales dude: “What do you mean?” Me: “Well, there’s a certain amount of work remaining to be done, and the release date depends on how many hours a day we can throw at that work” Sales dude: “Right, maths. So when can we release?” Me: “Actually, never. The organisation is throwing zero man-hours at fixing those bugs. You have taken away my entire implementation capacity. We will release on the 1 millionth of Decembruary, two-thousand and never”
...which got me a senior dev for a few weeks. After a couple of days of wading through the post-holiday sludge, we rolled up the sleeves and got to work fixing bugs.
It was a revelation. It had been months since I'd been deep inside this code base. I'd been doing a lot of code reviews but these don't really surface the stuff that should have been chopped out, or refactored. Building stuff on top of other people’s code places more demand on code quality than reviewing it.
The following probably sounds pretty familiar: To fix an apparently-simple bug, I disappeared for days down a rabbit hole of poor performance, duplicated code, horribly-named things, viewmodels that had grown into factory classes, expensive acquisitions of objects that were already in memory, etc. I scraped off bugs that were known only to reveal bugs that nobody knew about.
In the end, to fix a simple bug of the “if-you-change-this-thing-here-that-thing-over-there-should-change” variety I touched or stepped through every bit of code in a vertical down-and-back-up slice of the app. And the entire app was better for it.
My senior dev was doing exactly the same thing. We jokingly called it the 10 000-line service. The gunk in the machine that built up from a team of juniors pecking away at the codebase got sandblasted off by senior guys to extend the life of the machine for another couple of years.
In a medium to large software app, how often do you get the entire code base to yourself for a bit of no-holds-barred, free form refactoring? It felt valuable. That’s all.
