This content originally appeared on Level Up Coding - Medium and was authored by Bruno Rothgiesser
Don’t be scared! 7 irrational fears that lead to bad software and architecture
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 (i.e. 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 farther 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 optimisations 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 nearly 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 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 duration of implementation, there has to be a more precise and informative a 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 upfront 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 paralysed — 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 pursing 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 solve 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 of a technology solution with a team or a larger a group of people within an organisation.
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’s 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.
Note that it was not my intention in this article to explain in any depth how I would deal with those fears and counter them in architectures or in the approach to design software. I believe that by simply listing them and their potential for negative impact, that would trigger reflections on how you and your team could best deal with them.
It may be the case that you do not actually fear anything, but I work with the assumption that you as my reader also belong to the Homo Sapiens species and therefore do. In that case, think about your fears and their implications to your work. Face them, unleash yourself from them and enjoy the power that this brings to you, to your team and ultimately to your team’s product.
Level Up Coding
Thanks for being a part of our community! More content in the Level Up Coding publication.
Follow: Twitter, LinkedIn, Newsletter
Level Up is transforming tech recruiting ➡️ Join our talent collective
Don’t be scared! 7 irrational fears that lead to bad software with wrong architectures was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Level Up Coding - Medium and was authored by Bruno Rothgiesser
Bruno Rothgiesser | Sciencx (2022-07-11T11:49:39+00:00) Don’t be scared! 7 irrational fears that lead to bad software with wrong architectures. Retrieved from https://www.scien.cx/2022/07/11/dont-be-scared-7-irrational-fears-that-lead-to-bad-software-with-wrong-architectures/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.