A very catchy title for the first article on this blog, but I am sure you have not heard this term in a software development context. In the following paragraphs, I will try to explain what I mean and how you can avoid falling into this unpleasant situation.
In short, “hot potato syndrome” is а specific type of interaction during burnout (or highly stressful situations leading to burnout). It occurs mainly with inexperienced software developers under stress, and it is detrimental to their performance. The main roles in such situations are (but not limited to) a software developer and a QA. The role of the “hot potato” is “played” by some buggy functionality developed by the developer.
In a normal workflow, when QA finds a bug, the task should be returned to the developer so they can fix the found bug. This process is ok and often occurs in real life. If, however, the task with the buggy functionality is transferred around multiple times, it gets hot. Very hot! Therefore, the next time the developer gets it, they try to get rid of it as soon as possible. Shocking, but very often, the developer “fixes” the bug but does not even test the fix and sends it back to the QA. This behavior, of course, leads to poor fixes, introducing new bugs and a hotter potato. It is just a matter of time the developer and the QA burn out totally and catch each other’s throats. It does not mean that the developer and the QA are bad people. In 90% of the cases, developers are competent professionals (but inexperienced) who want to do their job the best way they can. They just happened to operate in a highly stressful environment. The tossing of the potato is only a defensive reaction of the brain trying to take away the pain and stress.
What can we do to avoid such a situation? Not much if it is already present. All of our efforts should aim at prevention.
So, what makes the potatoes to be tossed around? What causes this stress? Experience has taught me that the main reason for such a disaster is when the developer does not entirely understand what they develop. The developer is not able to see the idea behind the functionality and how this functionality integrates with the other parts of the system. The developer misses the big picture. Developing in such isolation creates technically correct functionalities but often far from the business need behind them. Most of the time, this work in isolation from reality is caused by missing or unclear communication. Please note that I am not saying “missing or unclear specification”.
If you are a lead developer, you need to make sure that the tasks you assign to your inexperienced colleagues are as clear as possible. They should be clear not only from a technical point of view, but they should also communicate well enough about the business idea behind their realization. More important, your role as a leader necessitates the promotion of an open and equal environment of communication. Do not limit this communication only to your teammates in the dev team. Include the QA, BA, and Dev Ops teams.
How not to get in such a situation if you are a developer? Your top priority is asking questions. There are no stupid ones. You must assemble the puzzle in your head. Try to understand how your task fits into the big picture. Before start coding, analyze each step of the process you develop. Try to predict any possible complications, border cases, and inconsistent logic. If you do not understand something, ask someone to explain it to you until you get it. Don’t say that you understand something when you don’t. Don’t worry, your colleagues will not think of you as stupid or incompetent for asking important questions.
A hot potato is in my hand. What to do?
Stop. Just stop and clear your mind. I know that the deadline is coming, and other tasks are piling up, but the best thing you can do is to stop. Don’t rush for a quick solution to the problem. Most likely, it is not that simple (if the potato is very hot, trust me, the problem is not trivial). Do a short walk, then sit and analyze what you are trying to achieve. Analyze all impediments that you are facing. Why are they there? What did you miss? What is unclear? What additional information do you need? What is the desired result?
After answering all of these questions, take a pen and write down a short action plan (up to 10 simple steps on how are you going to get to the desired result).
Only after you have a clear vision of the desired result and a well-defined action plan, you can start writing code.
When you are ready, don’t test only “the happy path”. Think of situations and cases, which can break your solution. Test them. Test them again and write the necessary unit tests.
In addition, always remember software development is a team sport. If you need help, ask for it.
