Rise and fall of SOLID programming principles

I am a fan of continuous learning. So if possible I go to meetups, conferences, seminars and open space meetings to listen and learn of peers in the digital space. So I went on an evening in September 2019 towards a talk regarding SOLID programming principles. From the very well organized meetup this evening by the company Working Spirit I left with some hard questions and some observations.

A few observations that hit me are:

  • A lot of programmers still struggle with the value of programming principles. Yes the talk was balanced that principles should not be followed blind and context always matters. But the struggle filled the room.
  • There are still (at least in the Netherlands) large amounts of Java and C# or .NET programmers who create a lot of hand crafted code. So despite the rise (and sometimes fall) of 4GL and nowadays ‘low code’ generators, software programming is still seen has the art of creating lots of lines of code by hand.
  • SOLID programming principles are still taught at schools and in interviews new hires are requested to expose their knowledge of these principles.
  • Innovation and real new paradigms regarding creating software solutions withing the Java programming ‘world’ are still hard to find. Hybernate for ORMs and programs depending fully on the Spring framework is still a common practice at large.
  • Some programmers really see their profession as black art that needs years of practicing and experience before you can reach some senior level. Anyone who has not hand crafted code for many years on a daily bases should not be taken too seriously.

So these observations were input for the following critical questions regarding SOLID principles in 2019:

  • Businesses require more demanding software products nowadays. Using old programming principles and construction frameworks will not bring faster, cheaper and more innovate state of the art solutions within reach easier. How is it possible that apparently many programmers keep on embracing old software paradigms when it comes to creating software products?
  • SOLID principles were created more than 20 years ago. In those days Object Oriented Programming was still seen has a dominant way for solving problems in software at large. However currently we know that OOP is better suited to some problem domains than others. Explaining SOLID without explaining some of the controversy around the use of OOP is a great omission. But how is it possible that many programmers in the Java world still have no balanced view on using OOP in practice?
  • Using SOLID principles can make software slow, the process of software creation is slower and it gives rise to serious questions on maintainability. So why are the SOLID principles still taken so seriously?
  • The IT architecture and Software Architecture world is too full of principles. The pain is that bad principles always have something good in it. However good principles used for software creation should be formulated as MUST and not as a SHOULD. Why are good software design principles still not formulated using RFC 2119 , in order to be more explicit how to use principles.

SOLID principles were good to have. 20 years ago. Or when you still hand craft OOP code in Java EE on a daily basis. However far more important is choosing the right architecture to solve business problems, select the right technologies and dependencies. How much software is needed to solve business problems? What type of decencies will you use? Do you choose a cash cow dependency so that you and your software company are requested back for every new feature the business needs? Or do you create an open architecture with open information flows where new functionality can be easily built upon by anyone?

From an innovation perspective there is far more than hold on to the OOP style with using SOLID principles. There is still increasing interest in functional programming. But when you really want to create business value always answer the question how much new programming is really needed? Software not created does not have to be maintained. But real large complex systems created in a simple way are very hard to achieve.