As a software contractor, and previous employee at many software shops, I have seen some amazingly well built code, and unfortunately my fair share of the horrible. To steal a quote from one of my favorite movies:
“I’ve seen things you people wouldn’t believe…”
– Roy Batty, Nexus 6 Replicant, Blade Runner
I’ve seen the use of design patterns for the sake of having used a design pattern, with interfaces so generalized that types have been thrown out the window so as to refer to all parameters and return types as simply java.lang.Object. I’ve seen applications written in C++ where pointers to proper objects have been re-cast as unsigned long, totally stripping type information (and the fact that the value is a pointer), passed around and then re-cast to a (hopefully appropriate) object type elsewhere. I have seen Translator objects, written to perform translation between DTOs and general Beans meant to be consumed at the User Interface level, that also including translation from HTML form attributes to both DTOs and Beans. I’ve seen hard-coded character buffers in C/C++ applications that are easily overrun when std::string was readily available.
I have seen the Big Ball of Mud up-front and personal.
It is easy for us to sweep these, and many other, examples of poor practices under the rug and claim that these are examples of mistakes made by junior developers, and that by hiring a lot of senior developers, a company may avoid these pitfalls. Unfortunately, I can attest that many of these mistakes that I meniton above were made by some very smart and senior individuals (or groups), many of whom have looked back and wondered exactly what they were thinking. Perhaps it is lack of thinking that has lead to these missteps. Regardless, mistakes or flat-out bad architectural choices get made by very smart people every day.
Code is business. Code is money. Code can make it easier for you to make more money more easily, or it can drag your organization into the never-ending mire of constant bug fix releases. As a coder, intimately in tune with whatever code I am working on, I’d like to believe that the decision is mine on what and how to fix the code under my gentle guiding fingertips, but the reality in many software development environments is quite different. Business drives release cycles and feature sets. They have the budget which may be spent by development for certain features in a given amount of time, and for the Quality Control people to verify that everything is working correctly as per the requirements.
In this type of organization, where development is not seen as source of revenue, but as a cost center, it can be argued that if there are fixes to be made that are not congruent to the current release, they need to be made “under the radar” or as part of some manner of “skunk works”. But regardless of how many off-hour unpaid altruistic coding expeditions that you may be willing to undertake, your fixes for the code blemishes may not make it to release. If your development team’s lead is vigilant in watching commits to source control, and is code-literate enough to notice that your changes do not appear to be contributing to the officially mandated requirements, all your hard work may be for naught.
Some that I’ve talked to in the past suggest that you should engineer enough time into your estimates so that you can correct wrongs in an area of code while delivering the feature set at the same time. This can work if you have buy-in from your development lead, but more often than not, those dev leads are being watched as well.
In the end, in this manner of organization, you need to be able to raise the importance of code-craft and “making it right” to the attention of the business teams that control the budget. And that can be tough.
While the article The Big Ball of Mud does not suggest how to fix the simple issues I mention above, it does offer multiple nuggets of wisdom between the lines as to how one may approach the powers that be in order to suggest time and/or budget to be allocated to fixing the blight that may be festering in your code base. The article provides some excellent ammunition.
And, if nothing else, it is a great read that draws from a number of sources and suggests some wisdom which may allow you to avoid becoming mired in mud in your future projects.