In one production planning project, we had reached a stalemate with a client. Repeated feedback came back that the development package was not working as it should. We received seemingly endless documentation with screenshots, but we could not clearly see what the customer was seeing. It was only when we were able to go through their observations of the problem with the customer, point by point, that we understood how the customer saw it. One by one, the hidden problems began to open up and be solved, as if a plug had been opened. So never underestimate the importance of the human encounter. Even if the client knows clearly what he wants and the developers use all their skills to solve the problems, one person may talk about the fence and the other about the famous stake. Sitting down together helps to focus on the big picture and moves you from the frustration of the feedback pixel to the heart of the problem scenarios.
Recently, one of our customers' sites crashed once a week, and the server was always being restarted in a hurry. As the situation was always quickly restored and no clear cause could be found, it became the new normal for everyone and was not prioritised for resolution. However, the problem kept popping up with equal determination, until one evening in the shower at home I realised that the pages were always crashing around the time the newsletter was sent. A newsletter that contained links to sites. Links, each with a unique tracking code for Google Analytics. That unique code then caused every visitor who came through the newsletter to bypass the site's cache and directly load the application server. It couldn't take that kind of load, but went down every time, in effect the newsletter caused a ddos attack on the site. My lesson? Systematic investigation and detection is absolutely essential, but it also requires insights, which in turn require time, space and peace.
This reminds me of another case where the program didn't work, I struggled with it for a long time. The next day I continued to investigate until the customer told me that they had had a fault in their own systems - the server had run out of space. If I hadn't jumped the gun and systematically tested the issue, I probably could have counted one plus one and seen the connection.
Whether you're in the software development business as a supplier or a buyer, you'll find it useful to keep these in mind.
Go into the problem in a fully systematic way, so that you also verify what you "know for sure". In the event of a problem, don't assume nothing, but check everything, and eventually you will find the point where the assumption was not true.
A human face-to-face meeting will defuse the frustrations caused by the persistence of problems and allow you to concentrate on resolving them in peace.
Being able to calm your own mind can save you a day's work. Acceleration acts as a barrier to organization and insight. It's not such a small thing that it pays to rush in and bypass the process. Even with schedule pressures, it pays to be honest with the client. If you're just making quick fixes, you'll usually find it in front of you. That's where you can save money, but future improvements can be difficult. This is also worth telling the customer.
