legacy enhancement development: why and how

It has been for a while since my last blog, because I have been doing legacy enhancement development (or, you may call it support-level-3 development). Why not rewriting it -- you ask; well, you cannot rewrite everything all at once, can you?

From the perspective of an individual developer, there is actually an advantage of doing legacy enhancement development. It is that you can cover a much larger amount of code base – you can “own” a subsystem in a short period of time. If we are talking about working in a stable company and therefore it is about a few years time range, then, it is the best way to gather requirements about a subsystem. You may say, I can read the functional spec. My answer is: who writes those functional specifications – often those things are not accurate, not detailed enough, and not updated – if they are available at all. In other words, if you are a good developer, then, the support-level-3 development is making you into a good business analyst and a good architect, simultaneously.

Of course, I realize that some support developers are not motivated to learn new technologies; but that is another issue.

OK, so much for motivation speech. It is the time for the question of how.

I heard about people talking about that to change a legacy system, you should first develop a suite of unit tests; only after that, should you change the system.

It is a good strategy -- if the legacy system is pretty modern. However, if the legacy system is a real “legacy” system, then, very likely it is not cost-effective to do that. You may ask, why? Simple: if the business logic is interwoven with UI, then, it is very costly to develop a suite of unit tests.

Even if developing a suite of unit tests is practical, there are higher level things that need to be considered first. There are three items:

(a) Collect and be diligent about software inventory info. Legacy system tends to be in a status that it does not have basic inventory information. The most fundamental two are: where the source code is located and where the installation kits for third-party packages are located. Other questions can be derived from those two.

(b) Have a high level (“power-user” level) understanding of the system. Legacy system tends to be in a status that it does not have user manuals and any other documentation. So, developers must identify “power-users”, and, communicate with them often and effectively. Often peer developers are also helpful. However, it is important to note that in most cases, peer developers should not be held as the definitive source.

(c) Add systematic yet quick changes to make the system easier to maintain, without “intimate knowledge”. For example, a typical example is to add database access logging to the system. Another example is to identify existing regularities, eliminate “outliers”, and articulate some “coding standards” to make the regularities explicit and enforceable.