So I’ve got a new side job.

So I’ve been working on my career as a programmer for quite a few years now. It’s been a long and tiresome journey for me, but I’ve seen so many things so far, and all those experiences are priceless to me, to be honest. And this time, I want to share another practical experience from my first year as a bachelor student at Ecole Polytechnique and my fourth year as a developer.

As you may not know, my current university, which is Ecole Polytechnique, has some kind of committee called “XForum”. To be fair, I’m not that kind of guy who wants to be a part of a committee or something similar. But about a month ago, I was invited to join XProjets as a new maintainer for one of their projects. For your information, XProjets is a group of students from Ecole Polytechnique participating in projects from organizations or companies. They have good admins, the clients are great and active, and everything is good to me so far. But that is just the management part. I’m working as their new maintainer, right? And this is where everything started.

How, when, and why?

Before joining the team, I was told that the need for new maintainers is quite urgent, not just for my current projects but for every other project in XProjects. XProjets teams focus on the stability of one’s commitment, which means that if I’m a first-year student, they will want to keep me working on the project until I graduate. This is not some kind of evil contract or bonding; the workload is not that much (at least, from their perspective), and I will not be exploited. And as a result, I was invited to become the new maintainer as a replacement for my senior, who graduated from the school this year and cannot work for XProjets anymore due to the policy of only allowing students from the schools, including engineers, masters, and bachelors, to work on the projects and receive compensation. I respected this viewpoint, as actively having new generations maintain a project is the right choice in order to keep the ideas and updates fresh and clean.

Another thing that I was told before participating in this is that this project is closed-source, every file should be protected, and access is limited between the team members. This means that I cannot share the code in any form. Even letting other people work with me on my tasks is not allowed if they are not on my team. This is for many reasons, but mostly because they are private ideas and intellectual properties of the organizations. But this kind of “closed-source” thing was taken in the weirdest way possible.

How bad is it?

First of all, the source code I know there are some projects that use French as their main language, and since we are in France, it should be normal to have French inside the project, at least in comments. But it is NOT OK to have BOTH English and French adjacent comments at the same time, randomly and poorly organized! They are comments; that’s OK; we can just skip those parts and move on to the real code. And then we have the class named Database, but the object name is baseDeDonnes! I know that we have both Francophones and non-Francophones working on this project, but at least please have some kind of agreement before typing anything!

Welp, I may have been too sensitive because I’m a non-Francophone and have a hard time understanding everything in the code (even though the previous maintainer, who is the senior guy, also complains about it). But while I was working on the project, I noticed one thing: everything is hard-coded. When I said hard-coded, it is not just a poor patch that fixes a bug or a weird implementation. If you remember the joke about a code that returns True if a number is even and False otherwise by going through hundreds of thousands of if-else lines, this might be the same thing as that joke. I’m not allowed to show the code here, but there was a part where they had to print the result out and return a PDF file to the user. The language can be English or French, depending on the user’s choice. Even though both languages return PDFs with the same style and format, they have to create TWO individual classes, one for English and one for French, with the class name for the English version being the French version plus an En suffix. And the content inside the two classes, from the method to the variables? They are the same! The only difference between those two classes is the strings’ language. Just by merging these two classes and adding some conditional statements to use the right string for the right language, I could have removed more than 300 duplicate lines of code! This is just one file; I haven’t checked other files yet, but I guess that they are also hard-coded.

The code is bad, but that is everything, right? Right?

So the code is hard to maintain, but I still have to work with it somehow in order to receive compensation. But the nightmare didn’t stop there. We had a server, which is currently serving not just our project but some other projects from other teams. I think this is fine, as all projects on that server are in PHP, and the implementation does not require much resource. We have a folder for the production branch, which runs separately from another folder for the development branch. This does sound pretty good; the testers and managers can test the newly developed features on the development branch while the production branch is being used by the customers at the same time, on the same server. The only problem here is that they are on the SAME server. Everything, for example, Python packages, is installed GLOBALLY, which makes any update on the development server that requires an updated package some kind of hell, as you don’t want that update to break everything in the production branch. We (yes, I’m not the one doing it, but the TEAM is the one doing it) installed the new version of the package fpdf2, which conflicted with the old package fpdf, which was being used by the production server. It is fine; I can just uninstall the fpdf2 package, and the production branch should be working as normal. I will find a fix for the development branch later with a virtual environment or something. But no, the packages were installed with ROOT access! A Python package can be installed globally inside the home folder with the --user flag, so why do we have to spam sudo every single time? And when I discussed this with the admins and my seniors, the only thing they could say was, “I will ask the system manager to uninstall” and “I think this needs root access.” So that’s it. I asked a guy to ask a guy to install a package, and now I have to ask a guy to ask a guy to uninstall the exact same package, which can be done by me and myself only, not with that “root access” thing! This is not just the end, because the content of the two folders for production branch and development branch is updated by hand with FILEZILLA! We have a GitHub repository for this, but so far, none of the files are synced with the repository.

This is the end, but also not the end…

There are tons of things for me to say about this project. But I can only come up with these problems to write about on this blog. So in the end, we ended up with complete spaghetti source code, a messed-up server, and a weird workflow. So yeah, I will find a way to fix everything, refactoring, changing the workflow, writing new guidelines for the newcomers, and other things that can at least improve this project. And that’s it. This is my personal blog about my new job as a maintainer.