Big Software Contradiction

One of the renowned books in software industry is "The Pragmatic Programmer: From Journeyman to Master". This book offers acomprehensive set of practical guidelines for creating superior software. As I read each section, I contemplated how to implement the advise and what it would look like in practice.

 

The section on "The Evils of Duplication" introduced the DRY principle (Don't Repeat Yourself) - the idea of having a "single source of truth" for code functionality. My initial thought was to create functionality only once and reuse it wherever needed. This would obviously simplify maintenance and ensure changes are made in just one place if needed.

The following section discussed the concept of "Orthogonality." It explained that unintended side effects can occur when fixing software code. Orthogonality means that changes over some dimension will not lead to changes in other (orthogonal) dimension. In other words we need to try to create software in such a way where implementation of some functionality will be independent from implementation of other functionality in system.

When considering how to write orthogonal code, I concluded that the best approach is to make each system component self-contained, with everything it needs implemented locally. For instance, if two subsystems require a square root function, each could have its own implementation. Changes made to one function wouldn't affect the other subsystem.

 

However, as I pondered how to implement orthogonality in practice, a dilemma emerged. Orthogonality seemed to contradict the DRY principle. If I prioritize DRY by making code reusable, it might not be orthogonal, and vice versa.

 

Being familiar with TRIZ for many years, I knew exact name for such situations - "Contradiction" (For a deeper dive into "Software Contradictions," you can refer to my presentation on "TRIZ and Software" where you can find how "Software Contradictions" looks like).

 

I thought about this problem, is this truly a contradiction, or can we potentially combine these principles without significant drawbacks? I found that it's possible to resolve this problem in same way like we resolve contradictions. It does not fully eliminate problem, it just make it less harmful. It's same like we cannot achieve "Ideal Final Result", but still need to go toward it.

 

In my view, all software methodologies (like imperative programming, functional programming, object-oriented programing, ...) attempt to address this very issue. Interestingly, software engineers have already been approaching problem-solving in a way that closely resembles TRIZ methodology. In object-oriented programming, we have a concept similar to the TRIZ "Contradiction Matrix" called "Design Patterns." These even share some names, such as the "Mediator" principle in the "Contradiction Matrix" and the "Mediator" design pattern.

 

This problem is not just another problem in software like many others. It's actually the "core" of other problems. That's why I call it "Big Software Contradiction". Many times when you try to solve some software problem you eventually find that what prevent you find good solution is exactly that: "make code reusable and independent" or in other words "to reuse and not to reuse".

I'll try to illustrate it. Every programmer that write code for "long enough" time is familiar with such situation. Lets think in some software firm two programmers from two different teams meet in kitchen for coffee break.

programmer 1: what your team is working on?

programmer 2: we are trying to implement <some> functionality

programmer 1: Oh, really? We've already implemented it a year ago, and build it as reusable library. Don't waste your time on it. I'll give you access to this library, just use it.

programmer 2: Great! It will save us a lot of time!

Same two programmers some months later in working space.

programmer 1: Who changed code in my library? Now all of our tests are failing! Nothing works!

programmer 2: We made some small improvements in this library because of changes in the requirement of our system.

programmer 1: But you cannot change it! It's wrong change for our system!

programmer 2: But this what we need for our system!

Both programmers understand that it was bad idea to use same library in both systems.

Every big software project goes into one of the two bad states (many times into both of them):

• in case project reuse a lot of code it became "spaghetti" code and whole project became totally unchangeable
• in case project do not reuse code at all it leads to situation where required changes are spread all over big system and any change (even very small) require a lot of work, and there is danger that some code change will be missed and this part will stay buggy
  

From my experience I can say that most of programmers are not aware about this contradiction. While DRY principle is very known, Orthogonality is rarely mentioned by programmers. Most programmers try to write generic well designed abstract code (DRY) and start to decouple (Orthogonality) code and subsystems much later and not from the very beginning.

I think programmers should be aware of this contradiction, it will make them more creative, they will find better solution for their problem and will better understand harmful effects of their solution.

I thought a lot about "Big Software Contradiction" and in my opinion there is deeper contradiction (about contradictions levels you can read in Logic of ARIZ by dr. Vladimir Petrov), contradiction that is relevant not only for software systems but also for any technical system. I'll talk about it in next post.

Thanks!