Skip to content

One Catastrophic Mistake to Avoid During Software Development

This is the 3rd post in the series highlighting the 3 Common Software Design and Development Mistakes That Cause Teams to Fail.  This is the title of my e-book and in this post, we will talk about the one mistake that can literally be the difference between success for an organization, or virtual bankruptcy.

Big Consequences

I have had the unfortunate work experience of seeing first-hand this problem exist in multiple systems.  I can say without a shadow of a doubt, most of the problems these software projects had were simply due to the lack of awareness of a good design. They had very talented developers building rapidly on a bad design which allowed it to go undetected until it was far too late to correct.

One system in particular had business logic in the UI, business logic in the database, and business logic where it belongs, in the business logic layer.  This system did have layers and had a reasonable amount of structure in the code.  However, all the benefits of those layers and code structure were circumvented with large amounts of use case specific business logic where it doesn’t belong.

Business Logic in the Database

The database is a necessary state store for many enterprise-class commercial software systems.  Under normal circumstances database procedures can be an asset to the performance and security of our applications.  Under abnormal circumstances it can become an anchor that holds back the growth and supportability of our products (and company).  Having business logic in our database causes us to be coupled to our database technology choice.  We cannot easily pivot to use another technology simply because so much of the application logic resides in technology specific language.

Another side-effect is the lack of testability of a change in the database code.  Since one change in a database procedure, which is called by source code, may work fine for one use case but cause bugs for another.  This traceability is severely limited, and we lack integrated Unit-Testing tools that we have in our software development IDEs.  In many cases, this database procedure is also called by other database procedures broadening the risk of bugs many times over.

Business Logic in the UI

In a very similar vein, having business logic in the UI can be just as disastrous. The UI is the single most volatile area of most software systems. Because this is where the user interacts with the system, they tend to suggest and even demand regular updates and improvements.  Many of these changes are generally cosmetic and don’t necessarily impact the use case business logic.  Unfortunately, the separation between business logic and UI can be thin and bugs may be produced with each enhancement.

Another argument against having any business logic in the UI (or presentation layer) is that we may evolve to have multiple front ends.  It is all too common now to have a web site and a mobile app available to multiple tablet and phone platforms. Now when a business logic change is required, we have multiple places to make that change.  We must replicate the business logic in several places and test each UI with every change. What are the chances that the exact same logic didn’t make it to each front-end platform?

The Path to Success (and Greatness)!

We must avoid the temptation to add any business logic to our database or our front-end platforms/UI.  As indicated, this can be a catastrophic mistake with wide-reaching consequences.  It may seem innocuous at the time and even a convenient way to fix a production problem. Nevertheless, it should be avoided at all costs.

Business logic belongs in its own layer within your system architecture where it can be unit-tested, integration-tested, and loosely coupled to your data store/database and front-end platforms/UI. This allows our business logic to change independent of the UI or database and promote separation of concerns.

This post covered the 1st mistake of the three covered in the 3 Common Software Design and Development Mistakes That Cause Teams to Fail.  To learn more about the other two common design and development mistakes (and how to avoid them), download my e-book!