When I started out as a software developer (or engineer) I would overengineer things regularly. It took a while of crunching and missing some deadlines before learning that “done” trumps “perfect” and thus simple can be better.
At one point, I’d be puzzled about my colleagues retort on talking about working on a proper fix for a common problem; he would often ask “how common?” and “how long does it take?” implying, how much time would one actually save with coming up with a clever solution. I was puzzled, because on some level, this process was very unsatisfactory…
Here’s a real life case we had some years back. I had proposed an internal, centralised python repository to distribute utilities among the team instead of finding the latest state of some one-shot script from some specific repo, and copy-pasting it to the next one and stacking on a few changes to fix it or make it fit. My colleague would then compare how long it would take to do this process and that we would probably need to do that a few times a year – at most. He concluded, that setting up the repo would take heaps more time than those mere minutes it took to copy-paste adhoc scripts.
Then, a friend of mine provided his take on preventing premature engineering: fix many small things individually by hand – no overly abstracting or optimizing before it’s obvious, that it’s repeated often. Then improving or combining those few obvious ones – that I call “hot paths” – rinse and repeat.
I’ve also come to learn, that before optimizing – for performance that is – comes benchmarking. Always. If you don’t have a baseline, it didn’t happen. And, more, a small improvement on one run is not a benchmark – it could be a fluke.
I like to think there’s an exponentially increasing time cost curve to complexity; when your working memory is clogged up, when your energy is drained, when you’ve depleted all them proverbial spoons, the velocity starts halting abruptly. Social complexity is its own number adding weight and dragging further that stall. And so do transition costs from one context to another, for example, when you load up all the past work and navigate through anchors to pave way for new solutions.
What my colleague did not take into account in evaluating the python repository idea was that, while we might have copy-pasted the scripts by hand only a few times a year, we would go back and fix them often. Then, when one broke and we found a better way, those changes would need to be backported to the other ones. But, of course, in the haste of the moment, like a true cowboy, we rarely did that. Until that same problem slapped the Stetson off our heads again in another context interrupting our flow and forcing us to switch contexts to now dig into a rabbit hole. Sometimes digging your way out from that back to where you were was less taxing, sometimes more; sometimes there was a CI/CD system involved and sometimes there was a VPN, which had their own issues. And often another colleague had fixed that same problem in the script in their version and now we were fixing what had already been fixed – like herding the same cow in tandem, Yeehaw! Pew, pew!
When those factors are summed, fixing a common problem is not just the sum of the time spent on fixing it by hand. There are extra costs around them we were not clocking. Evaluating human activities with a stopwatch is not necessarily the best approach. When dealing with software, teams and projects in full flight, it most probably isn’t very scientific, although it might seem like it is.
That’s why the idea of hot paths helps to pay attention to where the time savings – or rather – brain-time savings might hide.