How to keep code maintainable after original programmer quit

Question

Say if it's a 10 people project, 2-3 of the original programmer quit after the project has been release a stable version for a while. How to have the code maintainable in this case?

My imagination is reviewing the code after the project goes to release version and keep review it afterwards? Maybe split into 2-3 small groups and have each group review part of the code. So at least 3-4 people are familiar with part of code. Does this work? How do companies deal with this issue?

Usually how many percentage of time spent on reviewing the code? Please advise, thanks to community.

Answer 1

You make the code maintainable BEFORE the programmers leave. Define coding standards, write good code, write good comments, and of course, peer-review the code often

Answer 2

I think the most important things is get maintainable code is to write Unit Tests for the code, before the programmer leaves.

Answer 3

It sounds from your question that you are trying to increase your project's "bus factor". A reasonable way to achieve this is to require that each piece of code gets multiple pairs of eyes on it before it ever goes in the repository, or -- at the very least -- to periodically review each other's code so that multiple developers are familiar with each other's parts of the code. In addition to that, one should require that every single class and method be documented using Doxygen, Javadoc, or some other standard documentation tool, as well as require a standard set of coding standards that result in the code being intuitive and understandable to developers who have never seen it (for example, requiring that class names be TitleCased, that functions be camelCased, that names be descriptive and self-explanatory).

In addition, it is reasonable to require that unit tests be created for each and every component. Unit tests not only detect bugs early, but they also provide an example of the way the code is to be used.

Answer 4

What you can do depends totally on how the programmers, who quit, have been doing their job. If their code is "clever", and there's little or no documentation and tests, then the best you can do is to separate the modules they've made, throw them away, and rewrite them with better coding standards. It may indeed be way less work than trying to get your head around the existing code.

Answer 5

The problem with simply teaching your remaining programmers how to read the existing code is that, should they decide to go to greener pastures, you are once again back at square one.

You just end up wasting more and more time with your workers having to learn how to read different coders' work (which can be like reading unique and foreign languages)...

As some of the other respondents have said - the key is having everyone write code according to standards (meaning that you just have to teach new employees the one set of standards), and have everyone reviewing each others' code regularly to ensure that everyone is adhering to the standards, and are all headed in the same direction.

Answer 6

If you have a stable build then what are you worried about. The code can be put under source control. Before the original programmers left did you take full knowledge transfer from them to new resources. Or was it unplanned.

Anyway unless you have bugs to fix in those related code i dont think there is anything to worry about.

Answer 7

Assuming the code has no unit tests this would be a good start, normally unit tests are wrote before the code but I find in cases without them and I add them it forces me to understand the code I am testing. I have never been able to test code without first understanding it and this seems to be your concern. People can only maintain code they understand.

Another advantage is unit tests are for life they don't leave the company :)

With your code tested(at least the important sections of it) people are less afraid of maintaining the code as the risk of changing code is lowered. If a coder wants to change a less than ideal piece of code you know that once the unit test still passes all is ok in the world.

Answer 8

Hi,

Like others said, it is indeed essential that the code is maintainable BEFORE the programmers leave. I will not repeat all the other posts as they are all true and all mention important things.

I will just add one more thing which worked good in a couple of situations I have been in: Create a wiki page for the project, describe the important design decisions, the important classes, the architecture and maybe a couple of entry points (start in this class when you want to achieve this etc). Also include maybe a couple of "how to's": if you want to add new functionality, these are the extension points and this is the best way to do it ...

Yes, I know it is a lot of work. But it is a great source of information once it's done.

Regards, Jan

Answer 9

You have to start writing documentation, creating unit tests and publish javadocs.