The cyclical nature of Tech
I recently saw a LinkedIn question from a former colleague of mine with the following question:
“Hello tech friends, what is the advice you wish you had gotten early in your career?”
Now, initially, I thought my response would relate to a technical challenge with a framework or language. However, those kinds of learnings are part of how we grow and develop, so shortcutting them wouldn’t have gotten me any further.
So then… would a lesson about some soft-skill have helped me? Delivering presentations, coaching tips, agile methodology concepts? I feel like you end up with a similar answer to the first point, because it still relates to personal skills.
This led me to start thinking about overarching concepts or industry-level advice, and I settled on the the following: You’ll soon be wrong.
A political aside
In sociology there is a concept around cyclical patterns of social change; particularly how they relate to political trends. Broadly speaking, the argument is that a liberal political environment promotes more internal pressure to adopt more conservative approaches, and vice-versa. This creates an infinite swinging pendulum between political liberalism and conservatism, as one forces the pendulum to swing to the other.
Political Tech
The same pattern is visible across the tech landscape, and I wanted to give a couple of quick examples:
- Agile
- Micro-services
Agile
Agile methodologies are everywhere. It’s an assumed aspect of modern development that you’re working in a team that has adopted at least some agile practices or ceremonies. The benefits of agility are widely known; ranging from reduction of release risk, to short-term predictability and opportunity to change with early user feedback. However, these benefits also create an opposing back-pressure. A product that can change direction quickly and easily revolves around a high-level vision with short-term details. This will create a desire for what we’ve lost: long-term requirements and stability in the product scope, both of which have value in designing and implementing a solution.
We can already see this growing desire in structured agile methodologies aimed at larger companies such as Scaled Agile Framework for enterprise (SAFe), and Enterprise Business Agility (EBA). Both these frameworks try to scale the planning and requirements from classic Scrum models over a longer increment, and while no-one is using the word Waterfall with loving nostalgia we can see the trend shifting back in that direction.
Micro-services
Similarly, distributed applications using micro-services, or Functions as a Service (FaaS) are trending hard right now. They bring a modular, dynamic and resilient (when done correctly) pattern to the formerly unwieldy and dense monoliths of the past. Again, we can see how the issues that are solved with distribution come with drawbacks that will inevitably push us back towards macro-applications. A distributed system is typically more complex in terms of orchestration than a monolith, and intrinsically creates more distance between functionality. A single server counting from 1 to 1000, is going to be faster than 2 servers, one holding the current value, and the other performing the increment. Whilst a simplistic example, it hopefully shows that distribution creates latency.
A recent product I was involved with decided to use a distributed event-based micro-service architecture with each core process going through several business domains and multiple services. It was embarrassingly slow… Hopping through the network so frequently meant that every part of the process had a couple of hundred milliseconds of lag before the functionality actually happened. This experience made me much more cautious when designing my next solution.
You’ll soon be wrong
The tech industry has these patterns everywhere, and codebases will be littered with decisions that have been made to follow the latest trend. One day we will look back at our flagship application and rue the direction we took as we stand across the aisle.
We’ll lament the sprawling number of React components, regret the immutable entity that we now wish we could change, and blame the DevOps model for burning out our teams.
This advice may sound pessimistic, like we can never do anything right, but that’s not the intention. The trick is just to be aware of these trends. There’s often little value in the long-term in shoehorning your product into a new pattern or approach that is gaining traction. It is always better to take a step back and understand your application’s needs. Likely, a centrist approach will yield the most benefit, and you’ll be less impacted by the changing tides.
TLDR:
Don’t get taken in by the latest trend, and focus on the important things, because trends tend to swing back in the other direction.
