Old Code

en in code • 3 min read

Old code which doesn’t look good can reveal more light on the management of time it was written than the incompetence of computer programmers. Bad code doesn’t mean necessarily computer programmers did 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 very long 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 have also deprecated code in our new code base. 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 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. Old team was a team of PHP guys and they wanted to switch to Python. Problem is, they haven’t had time to do it properly and every attempt to do new 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 limitation. Language, framework, library, operating system, anything. Even knowledge limit 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 own 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 maybe 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 project like that, try instead to think about what could go wrong beyond programming to not repeat the same mistakes. And don’t be afraid to comment specification. Say no when it would go the wrong way you could see in the past.





You may also like

en What Makes Good Program?, November 20, 2018
en Fast JSON Schema for Python, October 1, 2018
en Open Source Responsibilities, September 6, 2018
en Deployment of Python Apps, August 15, 2018
en Nginx X-Accel Explained, July 31, 2018


Popular from code

en Makefile with Python, November 6, 2017
en Deployment of Python Apps, August 15, 2018
cs Jasně, umím Git…, August 6, 2014
cs Checklist na zabezpečení webových aplikací, March 1, 2016
cs Pokročilé regulární výrazy, August 17, 2014