You have received a new project which is started already and looks horrific. Either you have changed the employer or just switched to a new team, you can find yourself in a similar situation where things can support major improvements and they are still not enough to cover all the things that needs to be corrected. What should you do now?
I have asked myself the same thing a few years ago when I dived into a new company’s code base and I just said to myself Oh, this is some very disorganized application!
To give a little background, I’ve been working as a software developer at a medium company for a couple of years, was dedicated and advanced pretty fast in my career. Then I switched for a big IT industry player and I had been amazed by the shockingly bad maintained code. I was expecting to find the high quality applications that those kind of companies promise, but it was just utterly bad. A lot of code was duplicated, there were just a couple of code reviewers and the applications were all inconsistent, the unit tests were calling directly the private methods of other classes to name just a few.
At that time I remember that I have tried to change everything up. In a few weeks I’ve talked to people that I barely knew to convince them to change the way that the code base is written, I have had meetings with some of the leaders, argued on every change and refactored as much as I could. Then I thought about quitting and getting my old job back as I knew people were expecting me to return. Those were some dark days for me from a career and mental point and for the new project on which I had just arrived.
How it got here
The reasons why a very promising project ends up like this is because the company was having the teams that worked on it located in a competitive place when it came to the IT jobs. Programmers were never enough, the speed of development was very high and new people arrived in such a dynamic manner as others left. In a half of year I had to say goodbye to a good part of the team just to welcome some other bigger part. Basically nobody seemed to care for the project but much more about delivering what is requested and getting the paychecks until they find a new high paid job.
It was the classic quickly spawned teams for building a new big project from scratch, and it seemed not to give the results it was expected.
So, you see it is understandable why some projects may be poorly written, but whatever the reasons are in your case, you don’t need to panic and really just don’t do what I did, don’t start by trying to change the things up…
A slow turnaround
The people always find the best way of doing things even if they start by doing the worst mistakes. This is what my team mates and I have done. We agreed not to change anything just yet, and we started the other way around. We’ve let the project change us.
I’ve learnt the business processes, the corner cases, why some applications that were poorly written at the beginning were okay to be like that since that code was temporary. Of course a lot of issues were still there but as time passed we understood that we need to take things slowly and carefully change things up. We added more tests, we improved the deployment processes and security checks, we turned to a more optimal use of resources including asynchronous code and done a lot of improvements that I don’t think are worth mentioning. The most important aspect in changing how we build applications is that we reached a common ground.
Doing things on my own, as I believed was the right way and refactoring the project to match my way of thinking has the worst decision I could make. I was just a single man and it was simply unrealistic to think of rewriting the project. My refactoring attempt made it worse because it created more inconsistencies. Instead I should have learnt why the applications are designed that way, and ask people what am I missing. Plus, what is always wise to do on a new project: learn the business. You get used fast to the technologies because almost all of them are documented the internet, but the business knowledge will be a lot harder to find.
The key takeaways are:
- don’t try to rewrite the things your own way — it is almost impossible unless you are alone on the project;
- agree with others upon making changes;
- learn as much as you can so that your decisions will be the best one can make;
- be friendly — this one is the most important as you will spend a lot of time with the people you work with so make a great experience out of it.
That’s it, whish you a lot of luck and thanks for reading!
