Let’s start with the subjects you are supposed to avoid at the dinner table, politics and religion. For ages politicians of any political leaning have promoted their philosophy of “change”. What to change is not really defined. The objective is fuel the feeling that because there is something you don’t like a change would be good. Of course once elected there will be some new who comes along with the same “change” message.

In the Bible there is constant reference to “truth” summarizing with “the truth will set you free.” Note that it is “the” truth and not “a” truth. The validity of the Bible is not the current subject but the concept of truth is. Some things are subjective and we can have different preferences for music, food, etc. However some things are objective and there is only one truth about them. Two plus two is four always. If I believe with all my heart that it is five, I’m still wrong.

Software is a product and just like any product there is a process to market it. The marketer must convince you that what you have is insufficient in some way and you need a change. What they may be offering is in reality more of a burden to you than an asset, but it is at least a change. Of course it may simply be new, and that is a change.

Change may be good for you and your organization, but there are also significant advantages to stability. What is the truth?

We can easily find some truth about software. It is true to say that calling a method that simply counts from one to a billion and returns is slower than not calling the method at all. Finding truth in language X being better than language Y for a given purpose is more difficult. These two extremes suggest that when the question is very simple, the truth of the statement may be easier to discern then when the question or subject is complex.

Large software projects can be massed into a single complex lump. Breaking out logical parts to become a simple entity and open the door to finding what is truly the best solution for that part. Often just doing the process of simplifying one entity opens your eyes to other parts that you can do the same.

Many pundits will invoke some derivation of “it is a good practice” to state their case and expect no challenge. Depending on the pundit a challenge could be job threatening. Some shops have a policy of “always write to an interface and the interfaces are in a separate assembly.” Try to run that application in a debugger and you will see some loss in development time. Interfaces are great tools to use, but just like salt, they can be used to an extreme.