Maintaining the high quality of code can be a hard task. When doing a project, everything can happen: time pressure, client’s urgent needs, poor introduction of new developers, lack of code reviews. Generally, every flaw in the development process can leave unwanted code smells in a project. On the other hand, code can be well written in technical terms, while there can still be space to apply some changes which can positively affect a developer’s efficiency.

We can agree that whenever something bad happens with code, we need to take some countermeasures. Also, it’s great to constantly increase the quality – we are always learning something new that can be nicely used in old code. Here is some advice on how to start with such changes. We’ve already introduced bigger and smaller code improvements in different projects (you can even read about the one in ASP.NET MVC project), each with a different history of code smells, and we want to share some thoughts for other developers.

1. IDENTIFY IF A CHANGE IS NECESSARY

Often when we learn about something new, we come across many new ideas which we’d like to use somewhere. Of course, it would be the easiest to apply such changes in a project we’re working on right now. But first, think – do you need it there? Will it make coding easier? What will you, other team members, and the client gain? What’s more, won’t this change be too big? Ask yourself and other developers these questions and see if it’s a good idea.

Advice: try to seek only improvements which are known to work well and for which there is a place in the current project. Don’t do anything by force. If you’re not 100% convinced or it’s just an idea which you’ve heard about somewhere – investigate how much work has to be done in your case and how it will affect not only you, but also others as well (developers, management, clients, users…).

2. DISCUSS WITH OTHERS

It was hinted at in the previous point, but it’s an important enough issue to warrant its own section. Never decide on your own when there are other people involved in a project. If a change is quick and small, but can make work more comfortable - discuss it with other developers. If the change will take a bigger amount of time and can affect what is already working, your manager should know about it and also be a part of the discussion. Remember that time is money and increasing code quality doesn’t give instantly visible benefits for the business, which brings us to another point…

But first, a piece of advice: remember that every team member should be happy with the change. Don’t force anyone. If someone doesn’t like it, if you weren’t able to convince someone, you should consider once again if it’s a good idea.

3. FIGURE OUT HOW THIS CHANGE WOULD GENERATE PROFIT

When we work at a software development company, we are a part of a business and we have to generate outcomes. Be it for our bosses or our clients, money is almost always involved. In our (developers’) ideal world, businesspeople should understand that we want to use the most recent frameworks and we need time to develop things in the proper way. In businesses’ ideal world, they care about meeting targets within a given deadline. For example, let’s say the project is a photo gallery working on old ES5 code with jQuery. Most JavaScript developers would like to refactor or rewrite it – write in at least ES2015 and use some popular modern framework like React. But from the business side – what they will gain from it? Remember that it may be understood as a developer’s whim which can only break something, not make anything better. Try to be the salesman - sell your idea by using proper arguments.

Advice: non-technical people like to see visual changes. If it’s a change that can be presented in a visually attractive ready sample or can be easily prototyped – do it. If it’s the other kind of change, think about how implementing this can shorten the time for new feature development and try to go this way. Also, it’s vital to be sure that these changes won’t negatively affect what’s already working. Another thing – don’t hide anything. If there’s a possibility that something may go wrong, your management should know about it – after all, it’s their money.

4. PLAN THE CHANGES

OK, you’ve discussed the idea with other developers, you’ve sold it to the business, now it’s time to implement it. But remember – if you’re not the only one person working on the code, you need to plan the changes. Again, talk with other team members. If you want to do as many changes as possible at once, ask others if they aren't planning to work on the same parts of the code in order to avoid unpleasant merge conflicts. If the changes are big, plan with others how to make them incrementally, so you won’t fix their new code. Even more, let them help you, they also can make similar changes at the same time or at least write code that will be compatible with the new approach.

Advice: it can be a bit annoying, but always let others know about every major change you make. When you start development, synchronize frequently with others.

5. IMPROVE

So, when everything’s ready and steady, it’s time to go. Make the improvements you’ve discussed according to the set plan – don’t do anything more or in a different way. Seek advice from developers who’ve already done it. This may sound a bit like motivational mumbo-jumbo, but even when you don’t succeed, you haven’t wasted time. You and the other team members have learned something new, and that’s important.

And our advice here could be the same as for the previous point: synchronize with others. Don’t be that guy who stays quiet for a few days and later sends a pull request with over 100 files changed. I did something like this and my colleagues’ reactions keep haunting me at night (all right, it isn’t so dramatic, but it certainly wasn’t the wisest thing I’ve done).

6. DON’T REPEAT MISTAKES

Also remember that after implementing the changes, it’s vital to make sure that the things which went wrong won’t happen again. You can’t continuously improve the same thing. Teach others, and keep on guard yourself. If there was a faulty process – maybe you should talk with management about it? Bad code can be seen as a sickness, and improving code quality in many cases is just a fight with the symptoms. The most important thing is to find the real causes of the problem and do something about them.

TO SUM UP…

Improving code quality is not only a technical process. If there’s money involved, it’s also a business process. Never make it a secret, always inform everyone involved about all the changes. Also, it shouldn’t be just code improvement. Primarily, it should be improvement of your skills and development processes so something like that doesn’t happen again.

This post was also published on Medium.