There have been tons of books and articles written on how to be a decent engineering leader. Various authors have been dissecting the role into pieces and atoms, trying to pinpoint the true essence of success in this field. I'm dedicating this blog post to one of such aspects, the one I (until now) have only touched on in passing - the entropy control.
Why don't we start with a bit of theory, then? What is entropy?
Entropy is a measure of disorder or randomness in a system
(follow the definition of a "system" from System's Theory, of course)
So, when entropy increases, things become more disordered and less organized. Entropy is a part of nature - systems tend to naturally move toward higher entropy (hence more disorder) over time. Well, at least unless energy is added to maintain order (more on that later).
Because of this natural accumulation, when you think about entropy, you should separately consider two measures:
- actual level of entropy - how much entropy is already aggregated
- the velocity of entropy - how quickly the entropy increases - aka the "trend"
This is a very important conclusion for the consideration below.
Entropy in computer systems
The aforementioned observation about entropy in nature applies to computer systems as well - but even more so. Why?
- The inertia of making a change within a software system is lower than in the case of physical world objects (due to reversibility, lowered impact of physical constraints, malleability of source code).
- The ease of stacking abstractions in software is incomparable to almost any other discipline.
- Building software is very "meta" - we build software, but we also use (pick, configure, customize, ...) software to build software.
It doesn't come as a surprise - the state of the software systems we build can independently deteriorate in numerous dimensions: quality, performance, speed (of development), clarity, maintainability, reliability, etc..
Fighting entropy
As in the case of any other system, it's possible to reduce (or even temporarily halt) the velocity of entropy (to be clear: the FUTURE deterioration, not what has already accumulated), but that requires energy - or, in more adequate words, effort. Not any effort, but a very deliberate one:
- applied in carefully chosen places ("pick your battles wisely")
- based on real industry expertise (what truly matters vs what's a distraction)
- backed up with hard data collected in the wild (everyone talks about process/model/tech debt, but who really measures it?)
- multi-level perspective ("architect's elevator", to avoid tunnel vision & siloed thinking)
Examples? Here you go:
- "Here is the whitelist of our integration patterns with specific implementations: ..." (simplicity)
- "Here is the list of requirements for every deployable artifact, when it comes to: image, security, observability, ..." (quality - internal)
- "Here is the list of common conventions that we share across all the teams - regarding: versioning, releasing, authentication, ..." (standardization & re-use)
- "Here's a deprecation list for the internal & external technology we want 100% decommissioned, with specific borderline dates" (focus)
- "Here's the revised bug funnel process, with clear responsibilities & triage criteria, to make sure we have ways to handle both urgent bugs and the ones the can be planned ahead" (quality - external, process efficiency)
Role of a leader
Long story short - you need strong, capable engineering leaders to control entropy.
"Leaders" who are either "content-free" (never had been engineers or have themselves forgotten the craft a long time ago) or ones who avoid making hard decisions (& taking accountability for them) stand no chance. Such individuals typically jump clueless between random ideas coming from their engineers (who may have good intentions but are subject to their own bias and lack the experience/high-level perspective) - which inevitably ends with:
- No mechanisms to reduce the velocity of entropy (we'll keep gaining it as quickly as currently, or even faster).
- Draining, one-off hero "leap" projects aimed to reduce entropy locally (in a given part of the system) - that rarely reach their goals, cause burn-out & attrition, and reduce the faith that anything can be really improved (for real).
Let that sink in:
There's much bigger benefit in reducing the velocity of entropy, than focusing solely on spontaneous, romantic fire-fighting.
Sum it up
Let's wrap it up by debunking some common myths regarding entropy in software engineering:
- Entropy is not just tech debt. It's also bad engineering; it's accidental complexity; it's lack of ability to decommission; it's not seeing an advantage of standardization/unification; it's not noticing the new needs that come up with scale; it's following inefficient & pointless processes; it's failing to know when to automate and when not to, and much more.
- The most sensible way to reduce (down from a high+ level) existing & fossilized entropy is (typically) to scrap/rewrite (especially if you've succeeded to contain spiking entropy locally). Incremental reduction by applying gradual improvements may be economically nonviable & unrealistic.
- Reducing entropy by one-off hero efforts (the "leaps") is wasted energy as it gives no permanent effects. Instead, one should be building mechanisms that continuously enforce entropy-controlling rules & principles.
- One must learn to live with (some) entropy - trying to eliminate it completely would require unbearable effort. It would also cause several adverse side effects (hamstrung creativity, reduced flexibility, too much gating, etc.).
- Your role as a leader/manager is to chase indications of entropy far beyond source code/solution architecture: in culture, in processes, in the delivery lifecycle, in service quality standards, etc.
