I suppose you came across a situation when a software problem occurred and you heard „that’s the system that’s faulty”. But, have you ever wondered what exactly “the system” is? Maybe “the system” is a catch-all term that includes a wide variety of decisions?
True life story: I ordered a train ticket using a mobile app. All good, I was good to go! But when I arrived at the train station, on the information board I see that the number of the train, EIP 6502, doesn’t match the one I have in the app: EIP 6503. According to the departure board, the train with the number from my application was going in a completely different direction. I decided to ask at the information desk which number applies to my train. I was told it was probably a glitch in the system.
We encounter such situations all the time. Whenever I call the helpline of my bank to report problems with their mobile banking and hear that the system is at fault, I am laughing up my sleeve. Such excuses remind me of Carol Beer, a character from “Little Britain” series, who always responds to a customer’s enquiry by typing it into her computer and responding: “Computer Says No”.
Recently, I began noticing when someone says „it’s a system error”. We can say that a number of interconnected programs exchanging information could look like a system. Then who should we blame? Usually an error (or a bug like we, developers, use to say) is caused by a tiny piece of code. Ok, so who wrote that code? A developer. Usually, just one.
Ok, so we’ve found the guilty one – the developer. The truth is that the developer is the last one in the chain. And, of course, he or she wrote that faulty piece of code and probably didn’t test it thoroughly. But why shouldn’t we just blame the developers for this? Because, behind them, there are others who share the same, or even more, responsibility.
Maybe it’s the tester’s fault?
The code needs to be tested. Many applications now work in a tough environment exchanging information between each other. Not all of them (or should I say, none of them) are written by a single developer who was working on a code in a closed test environment and assumed that other systems should work exactly as specified (sometimes they are not specified at all, but that’s another story). At that point, we include testers in the process. A tester is a person who’s responsible for checking what the developer actually did (not wrote) and if this works perfectly with the rest of the code, with the external solutions and lastly, with the final consumer. Testers do a lot of very necessary testing (black box, white box etc.). Some of them even create special automted tests (using programming language, so they become developers themselves). And now we see the obvious: developers write code and testers test it. What could go wrong?
What about the client and the budget?
Very often developers or/and testers have limited time because the client wanted to cut his costs. The desire to save money can be counterproductive. If the app isn’t made with high standards from the beginning, it will probably need to be improved later, which will only increase the final production costs. There is often a misunderstanding that testing is so easy and anyone can do it, even an intern. Don’t forget that testing requires a great deal of knowledge of design techniques necessary to create good tests that bring out the defects in the software during the execution. Besides the usual challenges of the labor market, we also face a problem of finding experienced IT professionals who will be able to produce great digital products. We need to give them proper remuneration for their work and abilities. It is important to find a software house with an open-minded team that will provide the best solutions tailored to the needs of the client.
I think we shouldn’t blame a single person for malfunctioning code. However, we need to think a little more often why the low-quality or buggy code was created in the first place, and what was the reason behind this problem. This may be the sum of many people’s decisions, time constraints and short-sighted savings. I hope that after reading this article, you won’t blame “the system” anymore.