All these software principles and practices can be hard to keep up with when developing applications. They can be even harder to implement. One thing that makes it difficult is figuring out when not to follow them. Like a good database architect would say: it takes experience knowing when to denormalize data.

One problem that I admit having is prioritizing software practices and principles over what should be the true purpose of writing code: to make a great product.  Why did I, and other developers, sometimes fall into this trap?

DIM Thinking

In the book The DIM Hypothesis: Why the Lights of the West Are Going Out, Leonard Peikoff outlines 3 different fundamental modes of integrating new ideas/data into a whole: Disintegration, Integration, and Misintegration.  They are defined as such:

• Integration: data is integrated through rational means.
• Misintegration: data is integrated through a prism of ideas.
• Disintegration: data is integrated through no means. (nihilism)

The one mode that affects us is Misintegration. Misintegration has its roots from the philosopher Plato concept of Idealism.  This states that “Eternal truths exist in the realm of Ideas rather than in what we would call the natural, physical world.”  This type of thinking places a priority in ideas over reality.

There are some big problems with prioritizing ideas over reality. Leonard Peikoff shows in his book that the Misintegration mode is linked to the outcome of the Medieval period, the rise of the Nazi party and Stalinism.

Placing Principles ahead of Product

Software principles are ideas.  They are ideas that help us make better maintainable software.  But, they are not the reason we make software.  If by following software principles we make more complicated software to maintain in certain situations (yes, this does happen), then we probably shouldn’t follow it.

Following software principles blindly without rationally assessing context and/or situation is a great example of Misintegration mode of thinking.

Unfollowing Principles Example

Our main frontend application is an AngularJs application. We needed to create a badge input where one can type a string and the control would see if the string is in a valid list of badges.

When creating the control, I pushed that the control should be as reusable as possible: a badge-input control.  The control should know nothing about what its data is and where it got it.

The developers did a great job creating the control!  It was a very well made control that was easy to use.  However, AngularJs doesn’t make it easy to practice inheritance and polymorphism with components/directives.

Later our product owner wanted the new component to allow the user to add a badge to the database.

Our beautiful reusable control wasn’t created to do that.  Well, do we try to keep it generic and have some very confusing configuration options for doing this?

After a short talk we all decided to make the control specific to the database entity.  So now its a badge-label-input instead of a badge-input.  If AngularJs provided a better way to practice inheritance and polymorphism, then we would have kept it reusable and extended it.  However, since the framework limits us, we decided not to follow the very good Object-Oriented Principles that I preach, even in my blog.  The irony is is that the application is still very easy to maintain and pretty easy to enhance, even when we purposely didn’t follow OOPs.

Overview

Creating great applications that are maintainable and extensible should be a higher priority than implementing software principles and practices.  Knowing when to not follow them is a sign of great experience.