How to navigate working with a development process that is not supportive of clean code?

Question

I started working at my current job just over a year ago. When I started the code base was a complete mess. All of the code was in one file, it was not maintainable and best practices were not considered. There was no separation of concerns, single responsibility principle, and some major best practices for the AngualrJS framework were ignored.

While working on it, I managed to pull the code into separate files and make it more manageable. However, when I bought the poor code quality up with my peers and my supervisor they were not supportive of refactoring it even though I could not really work with the code in its state. I did it anyway.

It turned out that before I started at least 4 different people had worked on the project. The person who wrote the code was very junior and was left to his own devices without any code reviews. The subsequent developers quit the role after 8 months each. One of my current coworkers did work on it for a short time but I am not sure what he did.

Every time I have brought up in the past that this code base is not following best practices my colleague has gotten very defensive, resistant and emotional. He even says things like 'oh well even though it's a mess at least it works'. He seemed to have his pride picked because I said a project was not in good form.

The problem is I am going on maternity leave in September and my difficult colleague will be covering for me while I am away for 6 months. I am concerned that he will not follow the best practices while I am away and I will come back to a mess again.

How can I address this with my supervisor? This company does not do code reviews, unit testing and code quality is not on the minds of supervisors.

Answer 1

This is your answer right here.

This company does not do code reviews, unit testing and code quality is not on the minds of supervisors

So the only person doing anything in a structured way is you. Even though the code is (in your opnion) a mess, the other developers know it, and understand it. You fixing things up breaks their view of how it all hangs together.

So, just carry on working the way that you want to, but don't take extra time to refactor everyone elses code (you've already seen that they don't like that).

If someone screws up your part of the codebase while you're away, then schedule some time to fix it back up when you return.

If you can't live like this, then you may need to explore other employment options - you're not likely to change the way this team works without being a team lead.

Answer 2

An emotional approach to work related issues is not at all productive, but it is very usual. You mentioned in a comment that the change-resistant colleague is not the same person who wrote the code in the first place. This means that he might get defensive because he didn't try to fix the code himself, therefore he perceives your recommended change as a challenge. Or maybe he's just lazy and doesn't want to refactor the code.

I am sure you have used arguments such as: badly written code may work but it's bug prone, not understandable by new employees, cannot be maintained easily and all these lead to loss of valuable time. If these didn't work, you should try to use emotionalism yourself.

• I know the code works, that's because you did a good job on the implementation/maintenance, but it is very difficult for me and potentially to any new member of the development team to understand and work on it (this can also ring a bell as to why all your predecessors quit).

• I know you have done a good job and I respect your opinion, but I feel mine is not as respected. I am trying to help everyone with a change that will benefit us in the long run.

You can also arrange a meeting with the developers, team leader AND project manager/supervisor to make a brief presentation of the beneficial nature of clean code and testing.

• Bring as many examples as you can as to how this will help you in the future.
• Make an effort estimation.
• Most importantly ask for their recommendations on how the code can be optimized and how you can work together to implement the changes.
• Make a plan as to when this can take place.

In other words, make an organised and well documented effort in order to introduce code optimization to the project. Educate them.

Good luck!

Answer 3

When viewed from the point-of-view of management, a huge code refactoring

• Burns hundreds of hours of staff time,
• Adds no new features to the code,
• Risks adding new bugs that weren't there before.

Requests to stop everything and just refactor are unlikely to be met with enthusiasm by anyone other than the person who wants to do it.

A more realistic option is incremental improvement. Whenever you add a new feature, or fix a bug, then leave the code in a better state than when you found it.

Answer 4

This company does not do code reviews, unit testing and code quality is not on the minds of supervisors.

If you want to change this, it's up to you to come with good arguments why it should change, backed up with data. Remember that code reviews and writing unit tests take time of the programmers, and that's a cost. Any hour spend reviewing someone else's code is an hour in which you're not writing code which brings in money. Any unit test written which never fails (that is, never catches a potential bug) is a waste of resources which will never pay itself back.

Management will know how much it cost to do X hours of code reviews, and Y hours of writing tests, and an additional Z hours to "improve the code quality". A statement of "but we'll have less bugs later" or "it makes writing code in the future easier" is vague, and it's not quantified; it will carry little weight with management. Can you quantify how much time is lost due to bad code quality, lack of code reviews and lack of unit tests? Take into account how long code survives. In the company I work for, a lot of code lacks unit tests -- but a lot of code will also be either discarded or rewritten within 6 to 12 months.

Unit tests and code quality are good things to have (code reviews OTOH, I disagree with), but so are fast laptops and an in-house coffee bar with free, quality coffee. They will improve productivity, but they also come with a cost. Only if the gain of the improved productivity exceeds the cost, it makes sense for management to implement those.

Answer 5

Just move on, you are not a tree !

As a developer, you know you cannot work at the place like this, and you know that you cannot change anything (change your boss's way of thinking), so, just move on ! Find another work at the better place !