I realize that just about anybody reading this will immediately think “but we can have both.” I understand that. This is just an example.
At a client once, I came aboard with a bunch of other consultants around the same time (sometimes organizations do these weird things like letting entire groups of consultants go, along with their gained knowledge, and then have to pay the cost of having that knowledge needing to be relearned. There are ways that organizations can learn to do such things better, but I digress). With a large installed base of applications, various consultants were given various of these applications.
It’s always fun to think that your inherited application is the worst written application of all time. It isn’t always the case, but there are certain things that always jump out at you. I wonder if there is a term out there for an application that appears to want to violate Separation of Concerns in as many ways as possible. Let’s posit that some of these applications we inherited followed that ‘pattern.’
One developer decided that, in order to promote the long-term health of their application, it needed to be significantly refactored, in the usual sense of the phrase: Adding little to no new functionality while fixing the broken internals to increase its maintainability (in some sense of the word). Since I don’t want to debate their refactoring ability, let’s go ahead and accept that what they did was a significant improvement. There were actual ‘metrics’ available, such as a reduction of the size of the code base by something amazing like 90%, a consolidation of the various random technologies used to a consistent few, and other things that from most perspectives can only be viewed as positive.
Another developer focused on the ‘business state’ of the application. In particular, he knew that the business users were very frustrated at what they viewed as a lack of progress in the progression of the application. Business requests were stagnating. This developer decided to focus on identifying the highest priority business requests and implementing them, even though the ‘nasty’ state of the application made that, well, difficult, to say the least. Can anyone say ‘copy and paste?”
Now, everyone knows where I’m going with this. In six months time, the refactored application had zero releases, while the nasty application had three.
One of the things that has always struck me is that ‘unmaintainable’ applications actually are. It sucks to high hell to have to do it, but it is remarkable how much bad code is fairly supportable.
Delivering high-quality code often is an admirable goal to strive for. When starting ‘from scratch’ it is much much easier to achieve this. When supporting a ‘legacy’ app (meaning, any app I didn’t create), sometimes you may find yourself making choices you wouldn’t otherwise make, and justifiably so.