I am writing this on a Saturday afternoon after having spent several hours going over Java code that is about a year old, needed only occasionally, and has not caused issues for quite a while. Still I spent personal time to improve or, shame on me, even add the Javadocs. Also, some additional error checks were added and the code structure simplified.
None of this had been asked for by anyone else. And probably quite a few people would call it a terrible waste of time, given the various new features still needed so badly. So why did I do it?
It was an experiment, a successful one from where I stand. In the beginning I merely wanted to see in how many ways the code could be improved with sufficient time gone by after the initial writing. I ended up doing the following things:
- Renamed class
ServiceWrappertoServiceWrapperManager, because the class is not an actual wrapper but creates and deletes them. - Renamed variable
adapterServiceNodetonode, because via a wrong user input it could point to a node object of a different type and not an adapter service. (The same was done in two other cases.) - Added multiple checks that would throw an
IllegalArgumentException, if the user had provided wrong input. So rather than having to wonder why the creation of a wrapper had failed, I would be “shouted” at early in the process. - Added and improved multiple Javadoc entries. This, in turn, made me look at the code more closely where I discovered multiple things to improve or even fix.
When I look at the code now, it is cleaner, more robust, and easier to read. And the latter is the most important aspect on my case, because it reduces technical debt. So here you have your argument.
And for business people this means that I “keep my head above water level”. Or in other words: It is an absolute prerequisite for fast time-to-market that my code base is tidy and well-structured. Only then can I react quickly and change things without having to think hours what might break in other places, should I now add this or that new feature.