When I was a junior software engineer, I had a mentor who gave me two of the most valuable tools I’ve carried and still carry throughout my career.

The first tool was this one—how to break coupling:

How to break coupling

If the left-hand side of the diagram are two components with mutual dependencies, then the right-hand side is the solution. That is, two coupled components are decoupled by introducing a third component that becomes the new dependency.

This visual formula is simple but the fundamental skill set that can leverage it effectively is deep and takes years of practice to master and become part of one’s instinctual process.

The second tool I inherited from my mentor was the practice of personal work estimation and time tracking, which, along with component decoupling, is another practice that cannot be ignored by any software practitioner wanting to move beyond “expert beginner”.

These two skill sets are intimately related; estimating the cost of manipulating decoupled systems is far cheaper and more predictable than estimating and predicting delivery within a heavily coupled system. (A future post will have to elaborate on this.)

Interestingly, both of these skill sets—decoupling and time estimation—are highly controversial in the software industry. It is not uncommon for both of these skill sets to be looked at with near disdain by certain circles of software practitioners.

I’ve always found this surprising because I believe the ultimate goal of any creative professional or business is to master time management. With more time, we can create more—thus increasing our chances of creating valuable things.

I don’t think there’d be much disagreement on this if the point were pressed. Time has always been the most limited resource, by far, when I consider my own career experience, as well as being a frequent outside observer of other creative and business endeavours—when software projects fail, it’s ultimately because of a misuse or misunderstanding about time.

There is a natural correlation between the difficulty it takes to master a skill set and its value, but I suspect also to how much resistance there is to the skill set. If someone is telling us there are riches at the top of a steep mountain but we are at the bottom, that’s going to be some bitter news.

The trick with decoupling and time estimation is that if you start valuing and practicing these tools early in your career—as you cultivate your other technical skill sets—then you’ll find yourself incrementally moving up the steep mountain instead of having at some point to look at it from the bottom to decide whether there is value up there.