It’s incredible that something so clearly a product of intellect like software, or its architecture, can be shaped by anxiety and fear, or by any human emotion for that matter. At the same time, if we think of it… is that not the case for everything that we do in life?
In this article, I will cover 7 different fears and, for each one of them, the bad influence they have in software, in their architectures and ultimately in the digital products that they underpin.
Forgive me if it is obvious, but I present them all below in sections whose titles are [fear] → [effect], as in fear leads to a certain bad effect in software or architecture.
- Fear of Imperfection → Overengineering
This fear may be associated with us not wanting to leave any room for criticism by our teams, peers, others. Or, perhaps, with a more genuine concern for the team’s product itself — a desire for failure to be impossible, for the product to be impeccable.
Whatever the reason or trigger, the fear of imperfection often leads to gold plating of the architecture (ie making it more complex than it is reasonably justifiable) and over-engineering of the solution.
Here are a few examples of bad decisions that frequently result from fear of imperfection:
- When high availability is taken further than justifiable. For example, when cross cloud region replication and ability to failover is implemented without a serious consideration on whether that is actually required at the current stage of the product roadmap.
- When caching and other performance optimizations are prematurely implemented, without a clear indication that the real world will require it or that improving it should really take priority over other functional and non-functional features of the product.
- When in a buy vs. build decision for a component of the solution, “buy” wins because of a larger (but unnecessary!) set of features relative to what could be achieved with a simple “build” within an acceptable time frame and for a fraction of the cost.
It is important to note that in all cases overengineering is unequivocally bad, as it inevitably comes to the sacrifice of actual value to the product.
2. Fear of Mistakes → Analysis Paralysis
As I explained in Make Decisions, Make Mistakes. Just Don’t Lock Yourself Up, in Agile product development mistakes are acceptable, especially if you and the team can iterate away from them as your product evolves.
If you try to avoid them at all costs in your software and its architecture you will eventually find yourself in analysis paralysis. The team will be unable to make progress, while you endlessly compare design options, run unnecessary POCs, etc. And that is a mistake that the team may not be able to recover from.
3. Fear of Estimation → Uninformed Decisions
Estimation may feel at times so incompatible with our desire to be precise, and almost scientific in our decisions. What if estimates are wrong? Are we going to be blamed if we underestimate? Challenged if we overestimate? Yet, we must put that fear to rest as estimation is so important to what we do.
Take estimation of effort, for example. Without any estimates we lose the ability to factor in feasibility in our decisions, and to consider if the outcome we want to achieve is worth the effort we need to put in. Something else can be prioritized for implementation if the effort is not worth it.
T-shirt sizing, story pointing or whatever approach, having a good, informed sense of how much of the team’s energy a potential solution will consume is one of the key considerations before committing to it, especially where there are alternative solutions to compare it to. As I said a number of times to different teams that hesitated to reflect on the duration of implementation, there has to be a more precise and informative range of time than zero to infinity.
4. Fear of Not Knowing Enough → Lack of [Technology] Vision
Fear of the unknown applies to almost everything. In Agile product development, however, it is the fear of not knowing requirements enough that is most harmful. A truly Agile team consciously chooses not to define everything up front about what their product will or will not do, and instead to define the product in short iterations based on feedback from customers in each release.
While a team fears not knowing requirements enough, it is paralyzed — it doesn’t know where and how to start. It fails to resort to the product vision (contrary to detailed requirements, that must exist), to derive a technology vision. As I explained in Enemy of the Target State, the technology vision allows the team to have a north star architecture to guide the implementation in the various iterations of their product.
5. Fear of Disagreement → No Commitment to a Decision
There are in general multiple ways (or “options”, as we more frequently say) of designing a solution or a given part of it. In a cross-functional team architect, product manager, designers and engineers often discuss those options together.
Hearing everyone’s voices is positive to best inform the decisions, especially by leveraging the diversity of thoughts and perspectives of a cross-functional team.
Consensus, however, is not always possible and insistence on pursuing it leads to inaction. That causes great harm to Agile product development. So the team must be able to “agree to disagree”, and disagree and commit. That is to favor action over consensus for the sake of the agility of the team and for their product.
6. Fear of Not Convincing → Lack of Practical Guidance
Defending an approach to solving a problem is a common task in the day-to-day job of an architect and other technical leads in the team. However simple or complex the problem, however incontestable or controversial the proposed solution, there’s always an element of convincing others in that defense.
What will others think about the proposal? What will they potentially argue? Will they find flaws in my arguments? Worrying too much about those questions is how fear of not convincing manifests itself. If you let yourself be dominated by that fear, you will be preparing comprehensive explanations (and normally long slide decks) that are not proportionate to the complexity of the argument that you are looking to defend, while the rest of the team will be waiting for you to provide them with some guidance on how to proceed. And, in that case, there will be a convincing argument that you have not done a good job for the team.
7. Fear of Speaking → No Buy-In
Fear of public speaking is apparently very common. But here I refer to the fear of speaking, or otherwise sharing a technology solution with a team or a larger group of people within an organization.
Slides, diagrams and documentation alone do not generally suffice. Most times, communicating it and discussing the solution verbally with those who should care — sponsors and implementors — is indispensable. Firstly, as I said above, space must be created in a cross-functional team for the various members to have their voices heard about the proposed solutions. Besides, even if or when everyone is confident about the solution, it is through verbal explanation and debate that everyone can get to the “why” or “why not” of certain decisions, which is essential for alignment and commitment to the architectural direction.