Three months have passed since I started working for ICAN. Life has moved quite fast during this time and the company has made a good progress. Last month we signed a new customer, and now we are working hard to deliver the product to the highest standards. We can say that all the efforts are now focused on the development of the new tailor-made application for this university.

As the back-end developer, my role in this project consists of dealing with all the server-side tasks: linking databases with the application APIs, while handling the network connections. And this is not an easy job, honestly.



From the beginning, I have been dealing with some modules that need to be changed, adapted and updated to meet the new requirements, and use the latest versions of some of the libraries they depend on. Equally difficult is to deal with code written by other people. Not only because you depend on the documentation –sometimes quite obtuse, sometimes quite exiguous when not directly inexistent— but also because it implies the effort of putting your mind in the same state as the mind of the author of the original code.

Taking into account that the development time for this project is a bit tight, you need to do all the work-outs quickly, so you do not fall behind and delay the project.

In this sense, now is when I am really understanding all those boring lectures at university on dealing with legacy code, and the importance of fitting to the standards and providing good documentation. Surely, the more your code follows the good practices, the better your code is (even if is not the most efficient implementation for a particular algorithm).

For example, the in-line comments and meaningful variable names help to understand the flow of the execution. Using the right idioms for the programming language you are using also makes the code cleaner (what it works for C or Java does not necessarily works for Haskell or Python). Not to mention indentation: structuring code in the right way helps the reading flow and quote the scope of functions and other structures. Little details like these improve maintainability and robustness of the code, which in most of the cases is even more important than extreme performance.



Legacy code is always problematic to deal with. Of course, this is part of the job and it will always be: software is quite organic, in the sense that it is continuously evolving. For this reason, when writing programs it is important to bear in mind not only the program itself but also that someone else will use or look after that piece of code. So I guess these are the lessons I have learnt during the past weeks working for this company.

Thus, help others in your team –or the community if you are developing for an open-source project— by abiding the standards and documenting your code. If you do so, your colleagues will thank you while your code always excel. Too simple, and too complex at the same time, right?