IN CONCEPT
When we develop our business functions we need to automate things. Automation means software. Software is cool. Software is called ‘soft’ because there’s no hardware, no hard things involved … BUT software is hard to develop. Here’s my Triangle of Software Development Principles.
Long time ago I learned the quote: There’s only one constant in software development: CHANGE. And it’s true. While we strive to build perfect software for perfect business functions with perfect teams … there’s always a reason for change. We gain new insight on our business function so we would like to have new features. So our business was not so perfect as we had in mind. Even before a new feature is released to our customers technology has evolved and our solution has ‘technical debt‘, a lag with the latest state of technology stack (which our competitor might use already). So our technology stack and software is not as perfect as we would like it to be. And even the team might strive for perfection we will always be learning and become more equipped than before to develop and optimise the way the team supports the business function.
So our software needs to be flexible, changeable, like clay. It should have a high level of Changeability.
On the other hand users might not be pleased with ever changing user interfaces. Other systems the business function needs to integrate with is not changing at the same pace and at the same time. There’s also some need of stability in our software. But in a way it does not frustrate the changeability. There’s a huge amount of books, blogs, website about good software design and principles and here are some examples:
- Design patterns like
- Open Closed Principle from Uncle Bob’s SOLID principles: Open for extension but closed for modification
- Dependency Inversion Principle and the example of this in Inversion of Control / Dependency Inversion: Modules should depend on abstraction not on details (or ‘Programming to an interface’ in very short 😉
- And DRY, Don’t Repeat Yourself, of course …
- API First; thinking in APIs which are versioned and steady so decoupling is maximum and change is less likely to break things
All these principles are about how to design what should be changeable and what not. Therefore you need to think about the changeability of your software for things that need to change much. For the ‘harder’ parts you need to think about the Extendibility of your software. How to set it up that it can be stable but still open for extension and thereby still supporting change. This will generally be visible in abstraction, interfaces and such.
And while you have all this flexibility and stable parts going around and be changed the only way to prove the business function is still doing what it’s supposed to do is by testing. And the design should support the Testability. If it’s hard to test there’s a smell to it. You should rethink the design, the structure of the software and refactor it to improve. And support a higher level of changeability and extendibility which still supplies the business function in a stable way.
On the other hand tests will also make change harder. The way the tests are proving the business function are binding the changeability. So even the tests are eligible for these principles in itself.
So there’s a balance between the goal of changeablity against proving the product is still doing what it is supposed to do by the tests and to be able to still change easily we strive for extensibility which in turn downgrades the changeability. It’s a balance of a triangle, the Triangle of Software Development Principles.
Part of the Triangles Architecture