Software reality: Multiple ways of solving the same problem
/If you learn one thing in software after spending your entire working life in it, it is:
There is no single answer to any problem
It is something you find out over and over in your software career. Any software solution you are working on, from a simple algorithm to creating an architecture for a large enterprise platform - you’ll find that there at least a few if not hundred ways to solve the problem. And the funny thing is that every one of those ways are good in some aspect and bad in others. Your job as software practitioner is to come up with “A Solution” by considering a few alternatives and hope for the best. But it’s super important to come up with a solution though, many a times I’ve found that a team gets so tied up with considering various alternatives, fighting it out with each other to decide what is good or bad in each of those alternatives that they run out of time or just can’t decide at all - and this is the biggest software development disease of all time: the dreaded :
“Analysis Paralysis” of software death.
Today’s post is little journey on the tips and tricks of avoiding the analysis paralysis picked up from decades in treating this dreaded disease.
Ego is the biggest problem in software
If you want a single rule, this is the one: don’t take it personally.
Don’t feel that anyone in your team is attacking you directly, as a person. You are a professional and it’s your job to voice out your concerns and find solutions. That’s what you do. It’s not about you, it’s about finding that solution.
If you try to defend your ideas just for the sake of being right, you will always lose as a professional. That is not the goal. Your ego is not what needs to be maintained. Being a developer is a concrete job where you have to create value. Therefore, you (and your ego), personally, are out of the equation.
It’s easy to see if you argue for the sake of being right or if you don’t: just listen to you arguments. If they feel weak, stop the discussion and try to find good arguments to defend your ideas if it’s worth defending. Never think about being wrong as something negative.
Has anyone solved this already?
You’ll find that most software problems are already solved by someone somewhere. You are just a google search away from finding those examples and trying to fit that solution to yours. In most cases you’ll not only find the solution but also the effect of implementing that solution. Stackoverflow threads will usually overtime build up on people who have tried something, worked or failed. Reading through such threads will save you from a lot of pain, and save you time and money.
“In my view the Gang of Four is the best book ever written on object-oriented design - possibly of any style of design.”
When you defend an idea, find examples, or suggestions by authorities, quote somebody who agrees with you. Authorities are great, a big name like Martin Fowler can easily solve a stalemate situation in a software paralysis situation. More examples you have the stronger your argumentation will be. It’s not your ideas against somebody else’s anymore, it’s influencer’s proven-to-be-right-ideas against ideas with less weight.
The must in this authority or example world are design patterns. Read, re-read, memorize GOF’s book there is nothing as final in a software discussion than a design pattern number or name from GOF.
Use Data
If you have some kind of data to prove your point or support your idea always use it. Don’t hesitate to use statistical data, survey results and scientific studies. You’d be surprised how much data is available about systems and practices in software. For example, even how productivity of software developers get better or worse by their table and sitting positions has got scientific data to support a certain way of layouts.
You’ll find loads of data and survey done by universities on correct software architecture, or algorithm or even productivity of developers. Use such data to support your thesis, to drive your solution home. When you have data on your side, from a reputable source it’s easy to come to a decision for the team and you get the whole team out from the analysis paralysis world.
Use Your experience
It is always OK to use your own experience to support a logic. But remember that it needs to be honest and without any ego. If you don’t have any concrete example or scientific data to support your suggestion, you can speak about your own experiences. Make sure you are very precise for people to connect your experience with the problem in hand. More connection you can draw between the experience you are relating and the present context the more effective you will be.
A team like stories. If you have a good one to share that goes over your experience and that your team will relate to, then use it. Trying to stay clear and using logic to explain how your experience relates to the solution of the current problem is key.
Stay open minded
No team can find the perfect solution to a problem just because there is no such thing as perfect solution. So keeping an open mind is crucial for finding the best fit solution. Even if the team reaches a conclusion, and obviously if they haven’t keep the options open for further testing and checking of the suggested solution. Here are some of the things that you can do to keep things flexible and to test out the solution you agreed on (but always a bit skeptical about):
If you can create a low cost prototype to test some functionalities or to test if it does indeed work. A quick test project can solve an analysis paralysis decision easily.
If possible run low cost A/B testing to see which of the multiple solution is a better option. Get two opposing groups to come up with low cost tests to prove or disprove things.
Run surveys to check your theory. Ask customers if they agree with what your proposing, or if it’s too technical ask other software developers or teams.
