Agile Manifesto signatory Jim Highsmith talks about riding paradoxes in his approach to Adaptive Leadership.
A leader will find themselves choosing between two solutions or two situations that compete against each other. A leader successfully “rides the paradox” when they adopt an “AND” mindset, instead of an “OR” mindset. Instead of choosing one solution over another, they find a way to satisfy both situations, even though they contradict one another.
A common Tech Lead paradox is the case of Consistency versus Improvement.
The case for consistency
Code is easier to understand, maintain and modify when it is consistent. It is so important, that there is a wiki page on the topic and the 1999 classic programming book, The Pragmatic Programmer: From Journeyman to Master had a chapter titled, “The Evils of Duplication.” Martin Fowler wrote about similar code smells, calling them “Divergent Change” and “Shotgun Surgery” in his Refactoring book.
Consistency ultimately helps other developers (or even your future-self) change code with less mental burden figuring out of there will be unwanted side-effects.
The case for improvement
Many developers want to use the latest and greatest tool, framework or programming language. Some examples: Java instead of C/C++, Python/Ruby instead of Java, JavaScript (Node) instead of Python/Ruby and then Clojure in place of JavaScript. The newest and latest technologies promise increased productivity, fewer bugs and more effective software development. Something that we all want. They promise the ability to accomplish something with fewer lines of code, or a simpler, clearer way to write something.
The conflict
Software is meant to be soft. Software is meant to be changed. A successful codebase will evolve over time, but the more features and changes a codebase has, the harder it becomes to add something new without making the codebase inconsistent. When a new technology is added to the mix, there is suddenly two ways of accomplishing the same thing. Multiple this over time and number of transitions, and a codebase suddenly has eight different ways of accomplishing
Transitioning everything to a new technology is a function takes time. Making a change to an old part of the system is a gamble. Leaving the codebase as it is makes potentially new change in this area hard. That new change may never happen. Migrating everything over has the risk of introducing unwanted side-effects and taking time that may never be worth it.
To the developer wanting the new technology, the change appears easy. To those who have to follow up with change (i.e. other team members or future team members) it may not be so clear. Making it consistent takes time away from developing functionality. Business stakeholders want (understandably) justification.
Phil Calçado (@pcalcado) tweeted about this paradox:
As a dev, I love going for the shiny language. As a manager, I want a mature ecosystem and heaps of bibliography on how to write decent apps
What does a Tech Lead do?
Tech Leads ride the paradox by encouraging improvement and continually seeking consistency. But how? Below I provide you with a number of possible solutions.
Use Spike Solutions
Spikes are a time-boxed XP activity to provide an answer to a simple question. Tech Leads can encourage spike solutions to explore whether or not a new technology provides the foreseeable benefit.
Improvement spikes are usually written stand-alone – either in a branch or on a separate codebase. They are written with the goal of learning something as fast as possible, without worrying about writing maintainable code. When the spike is over, the spike solution should be thrown away.
Spikes provide many benefits over discussion because a prototype better demonstrates the benefits and problems given a particular codebase and problem domain. The spike solution provides a cheap way to experiment before committing to a particular direction.
Build a shared roadmap
Improvements are easy to make to a small, young codebase. Everything is easily refactored to design a new tool/technology. It’s the larger longer-lived codebases that are more difficult to change because more has been built up on the foundations that must be changed.
A Tech Lead establishes a shared understanding with the team of what “good” looks like. Specifically, which tool/technology should be used for new changes. They keep track of older instances, looking to transition them across where possible (and where it makes sense).
Techniques like the Mikado Method are indispensable for tackling problems that eating away at the bigger problem.
Playback the history
A new developer sees five different ways of doing the same thing. What do they do? A Tech Lead pre-empts this problem by recounting the story of how change was introduced, what was tried when and what the current preferred way of doing things are.
Ideally the Tech Lead avoids having five different ways of accomplishing the same thing, but when not possible, they provide a clear way ahead.
If you liked this article, you will be interested in “Talking with Tech Leads,” a book that shares real life experiences from over 35 Tech Leads around the world. Now available on Leanpub.
This paradox is also very visible if/when you are involved in multiple projects which share some kind of library code. Then, the consistency also encompasses what kind of tools each team uses, what build/test scripts can/should/could be shared, etc