You have several large projects that have large code bases. Several software developers have worked in the projects, all adding a little of their own personal coding style. New developers are joining the team and the same topics keep coming up.
The code is too complex
After several years of code modifications, updates, features, and bug fixes your code base is probably pretty complex. The project manager calls all the developers into a meeting and says “it’s time to simplify the code”. What does that mean? What should the developers do?
One solution is that each developer will look at their part of the code and clean it up. However, the best cleanup you can get is at the level of the developer. You are still going to have several other developer styles, some still complex and some that seem too simple. A more advanced developer may have very complex code compared to an entry level developer. This didn’t really solve the problem.
Another possible solution is for the lead developer or manager to propose code complexity solutions. But the problem with code complexity is that many projects are broken into several smaller projects. These projects are maintained by small groups or individual developers. The solutions proposed may not apply to everything. Developers may go out of the way to implement the global solutions and end the end the code isn’t much better. The developers now feel like they did a lot of work but the problems still exist.
So what solution will work? You need a team effort and everyone on the same page. Then once everything is heard you can begin to work on the solution to each problem. The following steps will help:
- Ask each member of the development team to write down a list of items that frustrates them about the code. Tell them to include things that they don’t like, things that don’t make sense. Be sure to include things that make developers feel uncomfortable to touch or optimize because it could break the product. Each developer should have a few days to think over the list and jot down items. Make sure to tell them that it doesn’t have to be all about their codebase, they should have an open voice on any available codebase. Remember you are looking for symptoms not causes.
- Call a meeting and have all the developers bring their lists. Have a computer ready to view each codebase. To keep things simple you might want to work with smaller groups one after another if you have a large team. As you go over the lists, you will want to get the name of a specific directory, file, class, method, or code block to link to each item. If the topic is broad, you will want to ask questions like, “Tell me when this problem occurred?”, “When did this cause you issues?” You want to drill down each item to the root problem. Code is the only thing that can be fixed, so you will want to drill down to the exact parts of the code that cause concerns and bind a description of the problem to that code.
- Using the information from the meeting, you will want to file a bug or task describing each problem. If a solution was provided in the meeting you might want to note that in a description but you still want to note the problems.
- With all the issues out in the open, you are going to need to prioritize. You will want to look at the issues that affected the largest number of developers. These will be your high priority issues. Then you will need to arrange the items by an order of what relies on what, such as issue D needs to be solved before issue Y. This could mean that a lower priority issue might be fixed so that a more important issue can be fixed easier.
- Now you can assign each bug to a developer.
- Finally the developers have to figure out when to actually fix the issues. Good practice is to include some fixes with future work alongside one another. If the problems are documented well enough, then a developer should be able to stay pretty much on track with future work without falling behind. You don’t want to stop normal future development entirely just to work on code cleanup.
That’s it! This was a very rough overview and a general concept. But if done right you should be heading toward a cleaner codebase and easier long term development.