Toward the end of last year, I did a lot of reading around strategy, specifically strategy as the military uses the term, but applied to internal IT. By coincidence, I read both The Phoenix Project and Stephen Wardley’s emerging book on mapping within a few weeks of each other. Apart from meshing very well, the two sets of ideas are a nice jumping-off point for a new year. Before I start to delve into what the cutting edge looks like and is going to look like in years to come—into patterns that repeat and can be predicted—I want to think about where the rubber hits the road in my own world.
It’s relatively easy to read about companies of enterprise size and larger, where a small project is $250,000 and can be tried on a whim by middle management, and picking up a few developers from a couple of teams and asking them to quickly put together your pet project can be a political battle but, at the end of the day, is not all that hard. If there are twenty developers on those teams, who will miss three? But what if there are only three developers in your company? What if your annual budget is $250,000? What can you try then?
In a smaller business, with a much smaller team, people are handling multiple traditional roles with multiple responsibilities. This becomes a much more complex affair. Picking up the latest new thing is a lot harder. Moving systems wholesale to VMs, containers, or APIs becomes a lot less obvious. These things also take a much higher percentage of your budget. The risk is higher. The inertia is strong.
The books, of course, are there to paint a rosy picture. There would be no point in cluttering them with the multitude of “what-ifs” that are real-world issues for many. They wouldn’t apply to most! To be useful, the books can only capture the happy path, with the necessary excursions to describe the problems they are trying to solve.
So, what does this mean? It means that most of us are left with a fair degree of inertia—with systems we see should be changed, but without the impetus to change them. That 10 Mb hub that has been sitting on a desk for ten years should have been replaced long since. However, until it fails, it is fulfilling a purpose, and there is little point in going to the effort to remove it unless some other constraint comes into play. With only a couple of developers, it can be easy to start to change a practice, but it is just as easy to fall back to old ways when there can’t be a dedicated development team lead.
In the ideal world, we would be able to keep all systems up to date with the latest and most efficient means of working. In reality, we have to decide where to focus effort. If we start each new project by looking at the landscape and picking the best technology for the job, then the natural lifecycle of projects and software will keep us mostly on the straight and narrow. If we start each new project with “this is what worked last time,” we can end up spiraling out of control. The only time this isn’t true is at the genesis of the business. With a brand-new start-up, it’s possible to pick the latest tech and most compelling practices and to be right at the cutting edge. Within a year, though, we may be a step behind; we may be fighting inertia.
What does this mean, then? It means we will always be slightly smeared across that cutting edge, with some parts lagging. No matter how much we try, we will never live on the sharpest edge of efficiency. It also means that whenever we look at a new technology, a new way of working or implementing (and we must keep looking at these all the time), we must look at how it will interact with what we have already. We need to see the inertia in our systems. After all, the first step in solving a problem is to identify it. We tend to see the “legacy” as an anchor holding us back, when often, it’s the rock we are building our house upon.