That programmer should be kicked
Who hasn’t found something “bullshit” when reviewing the code of a project or the operation of a program and has cried out loud?
Especially when the project should already be finished (or supposedly already is).
What to do about it?
This happened to us recently while reviewing and modifying the code of a project for a client. There was a programmer who evidently did not even know how to join two strings of characters in the project language (C++) and used another much more complex and expensive operation to do so.
Although it is too late to correct that specific point in that project (without modifying hundreds or thousands of program lines), How can this type of situation be avoided in the future?
Why does the programmer fail?
That programmer obviously has something that he has not understood when learning to program or has acquired a habit thinking that this was the “correct” or “good” way to do it.
Plus you will repeat that mistake over and over and over again in this project and all the following ones. Because? Because no one verifies or corrects the programmer!
No one would think of driving a car that we never serviced. It’s not just about getting us from one place to another – we also have to make sure that it will work correctly, without hidden defects, when doing so.
The remedy
The remedy is to establish a developer review and correction function as part of our quality assurance function. A faulty machine will not produce good results. Neither does a “defective” programmer.
There is a relatively simple way to do it, which is code reviews by expert programmers, who in turn have been properly corrected and/or have great capacity and experience.
It is not about making in-depth corrections of each line, but rather about reviewing parts of the code and seeing errors and defects and correcting the programmer. This raises the quality of the programmer and the other programmers reviewed, little by little, until projects are completed with much more ease and fewer problems.
We don’t have time to do it
Nor will there ever be. Why is there no time? Because the errors of the programmers (and analysts…) have to be corrected in a very costly way.
Why not prevent this situation by gradually establishing this correction function?
The only “risk” of doing this is that one day we find ourselves with an efficient programming team, that the projects turn out well, at least on a technical level, and that we have no one to “blame” on that team.
But perhaps this is an acceptable “risk”…