in Old code, which doesn’t look right, can reveal more light on the management of time it was written than computer programmers’ incompetence. Ugly code doesn’t necessarily mean computer programmers made a mistake, but with higher probability, there was a problem in communication in the whole team behind the code.
For example, I got a project. It was a Django web app. Some parts looked like PHP style. It was made of a few large files counting thousands of lines. Almost half of the code was marked as deprecated—a total mess.
As the first step, I recommended to start over. Untangle that mess would be much more work than to start again. There was no documentation and no support from the previous team. And a client wanted to split that system into two pieces anyway.
The result? It’s better, cleaner, more secure. But! We also have deprecated code in our new codebase. Piece by piece it’s a bigger and bigger mess.
How is it possible? Well, several times, we got new priorities changing the product from the core. We were discussing everything in detail. We had regular meetings on site. We were going to places to see it used by end-users (the community it’s built for) and see them in person. We are, kind of, part of that community as well!
But it didn’t help. It’s a democratic community, and the product manager wanted to please everybody. So when someone wanted something, we got new priorities. There was no strong vision. Unfortunately, we didn’t notice.
Now I understand better what happened to the previous team. The old team was a team of PHP guys, and they wanted to switch to Python. The problem is, they haven’t had time to do it properly, and every attempt to do newly requested features ended soon as a deprecated code. Also, the company doesn’t have a lot of money, the old team could use only one man-day, and without vision trying to please everybody, they were better off to do nothing.
In Czech, we have a saying I would translate as “when you do nothing, you spoil nothing”.
Today, it looks similar. Even when we are not afraid to say no to request, which doesn’t make any sense, I can see what I did with the best intention in mind today doesn’t look so well.
Because of this experience, I realized we shouldn’t immediately blame old computer programmers. As I did when I got the project. The problem could be somewhere else. And even when programmers are behind it, they don’t have to do it on purpose. Their bad output could be because of some limitations. Language, framework, library, operating system, anything. Even knowledge limits or lack of experience, which is very common for junior programmers.
Don’t feel bad to find a bug in the code of your boss. He or she should know everybody is evolving and take it peacefully. Ideally, next year we all would write a much better version of our code than today. Don’t be afraid to read your code after some time and explore which bugs or not good architecture you can find. Or how you could write it better. Ask yourself, why haven’t you saw it then as well?
Don’t be afraid of it and refactor.
Also, don’t be afraid to say no. Maybe someone will not be pleased, and perhaps even someone will yell at you. I have this experience. But only when you are not afraid to step down from your position, you can achieve something. You have to give feedback to specification.
The specification cannot be done at the table with managers only. The specification is created on the way with the code, language, operating system, and the team. Each has its limits, and therefore each has its part on the creation of specification.
If I wouldn’t comment requested features and was afraid to say no to some of them, we would end up in the same situation as the team before us. Right now, we wouldn’t even do any work on that project anymore.
To summarize it, don’t blame former programmers of the team right away. When you inherit a project like that, try instead to think about what could go wrong beyond programming not to repeat the same mistakes. And don’t be afraid to comment on specifications. Say no when it would go the wrong way you could see in the past.
feed