Off Topic: Naming the Software Design Bad Practices
During maintaining a code base for software, developers have to deal with what we mostly call "legacy code". Beside its original meaning, legacy code mostly refers something that you do not want to touch or change because it is a mess. Mess in the code can be caused by a number of things. First few reasons I can name are:
- Lack of time to develop software
Most probably some unrealistic deadline is the underlying problem. It can also caused by finding out a design failure as a bug in your customer installation. There is no time to fix it properly but it must be fixed.
- Lack of personal experience
Developer is lazy or did not experienced the consequences of developing unreadable code yet. Software source code is not a place to show how complex you can think. The hack, which is showing how complex you can think will cause unreadable code. This is a trouble for your future yourself.
- Lack of community knowledge
In this case software we are dealing is really legacy code. At the time of this piece of source code is written, probably software community did not yet developed the knowledge for design principles and other concerns. A wheel that is not invented yet can not be used of course.
Regardless of the story behind, there is a high possibility that you came across with source code, which should not be like the way it is. That could be developed by you in the past, your teammates or someone else. I have a small list of "names" that I give for the software abnormalities that I came across below:
Hack Driven Development
In case of there is a design failure in the software, bringing the new feature or correcting the software behaviour can be done by patching your software in an unexpected way. This unexpected way is what "hack" refers in this term. In case of your software product has many design failures and not properly refactored to fix those failures, then you run into a new development strategy: Hack Driven Development!
Surprise Driven Design
Any software that is actively used by users needs to be maintained for satisfying the user expectations. This expectations can be about correction of the behavior or a request for a new feature. Of course there are unexpected expectations came into picture. At the beginning of every new user story developers needs to discuss about the "is state" of the software and "future state" of the software. When this is not done, then design of the software develops by unexpected and unmaintained decisions of individual developer which is probably only focusing on current "suprize". In case of software development is not really managed by any architectural decisions, then you run into Surprise Driven Design!
Three Digit Versioning Schema
or: Heisen Versioning Schema
Semantic versioning is mostly accepted way of versioning the software artifacts. Basically it is based on three parts, which are major, minor and bugfix numbers. In case of the "semantic" behind the three digit is not followed or considered, than you run into a Three Digit Versioning Schema! Since the version of the artifact does not mean anything about the content, your stakeholders which needs to integrate that software needs to take a look into the artifact to see what is really changed. In the long term this brings always an uncertainty about the compatibility of the artifact with previous versions, like Heisenberg's uncertainty principle. Therefore it can be named as Heisen Versioning Schema as well.
Beside its funny, I think giving a name to the wrong path or "bad practices" is also important for having a better understanding about how better software design should be. It helps us to identify the failure and builds a common terminology to communicate about these failures.
