Blog > The pros on working on bad code

It is good to ask whether or not solving the problem brings significant benefits to the application

I am writing this article after yet another analysis of badly written code to which three of us still cannot find a solution, after a whole day.

In itself, the problem to be solved could be considered simple, but the way to solve it is unexpectedly tangled and intricate. We move from file to file trying to understand how logical events intertwine making the solution impossible to develop. It looks like a dead end, a maze of messy instructions and algorithms. It's easy to lose patience and get frustrated.

Why is there some badly written code? Often it happens because the tight deadlines have not allowed a more thoughtful organization, or because a junior has never been followed sufficiently by someone more experienced than him, or again, because the developer does not care enough for his work (and should change job, for real)

However, there are a few points I would like to keep in mind when working on "bad code".

Not all evil comes to harm

Isn't it because I love solving logical problems that I chose this job? Isn't it because programming itself is a constant problem solving? Working on a disordered code, from this point of view, represents the quintessence of this trend, and creativity is strongly tested by this type of problem. Finding a solution to apparently unsolvable problems, even if it is not very "clean" or "tidy", is still a pleasant practice. If you love solving logic puzzles lying on the couch, why shouldn't you love finding a solution in poorly written code?

No repetitive patterns

All in all we can say that the average development uses more or less standard patterns that we can easily remember by heart and use. Conversely, poorly written code almost always does not meet any standards, and this is where our ability to create new paths comes into play. This is a great workout that needs to be done every now and then.

Can be funny

Seriously, our skype call was luckily a lot of laughs, since the code literally did "weird things"

In practice, how do I handle it?

The first thing to do is obviously to inform your colleagues and superiors of the status of the program. Secondly, it is good to ask whether or not solving the problem brings significant benefits to the application (solving a problem, especially under these conditions, takes up a considerable amount of time that could be spent differently) and, if so, understand if alternatives can be identified. Then it is obviously important to analyze the code as much as possible, trying to be as astute as possible in carrying out the necessary tests in the areas most intuitively useful for gathering information about the problem.

As far as possible you must absolutely avoid making the code even more incomprehensible or unpredictable. This is because if you are the one who has to deal with software again, you may sooner or later find yourself dealing with even more difficult problems. If, on the other hand, your colleague will have to get their hands on it, well, respect him ethically.