I regularly help out our smaller customers with tasks that might be a thorn in their side, and which would drag them away from their normal business priorities. These tasks often involve that I have a cursory look at their Uniface repository, and a gain a general knowledge of their application architecture.
Whilst performing some of these tasks, I often see all kinds of objects that are dead wood in the application. There are the warning signs … objects that start with TEST, objects with developer’s first names embedded, last updated in 1998, obsolete objects (UVCS model), and so on. It is so tempting to delete these objects, but I act professionally, and wouldn’t load that kind of regression testing burden onto customers, unless instructed to.
So does anything happen to this dead wood? I do hope that the developers spend just a little time cleaning up their repositories, but inevitably this requires more than a little time, and developers are handed higher priorities. This I understand; our work has to be able to demonstrate added value to our masters. If the work does not obviously show savings or improved performance in some way; if there is nothing that visibly changes, why invest in the work?
This is the answer to that question: because you are building up “technical debt”, and it might be cheaper to fix it sooner than later. For a wider explanation, have a look at Ton Blankers’ white paper on “CONTAINING AND MANAGING TECHNICAL DEBT WITH UNIFACE”. Your masters may argue that they’ll never need to repay that technical debt, but there is a lot of current discussion on modernizing applications, and cleaning up your code, and understanding your assets, are important process steps in modernization.
I do know how dead code gets created, and there is a respectable amount of time that it can remain in the repository … “just in case”. Rather than put a use-by date on dead code, it might be better to schedule a little time when you can review your code, maybe straight after a major maintenance release you could get rid of last year’s dead code (as distinct from the latest dead code), or in those quiet weeks of the summer holidays. It also makes sense to do it whilst the original author can remember the code, or particularly whilst the author is still employed by your masters. It can only cost more to do it later. Besides, if a business case is drawn up for modernization, it would be great to start doing some new development ASAP, rather than spend a lot of time rediscovering the ancient history of your application.
I mentioned some of the obvious ways to spot dead code earlier on. There are tools for a more deterministic approach to code coverage analysis. You can turn on proc tracing and run it for a while. This should be avoided in production, but with a good suite of regression tests, it should be possible to capture the traces in a test environment. Don’t forget to add a line like this to the assignment file: $PROC_TRACING_ADDITION=”%%$componentname >>>>”. There could be more done to automate the examination of these trace files, but it shouldn’t be too hard to match trace files against a list of components. There will always be some manual investigation to be done, and the Uniface Cross Reference tools will be helpful here.
So, don’t shy away from pruning that dead code out of your application, even if it’s a branch at a time. If you have some ideas or tool strategies for finding dead code, please share them with us.