Published June 28, 2020
by Doug Klugh
Keep It Simple
Avoid building software that obscures its intent, contains duplication, or provides hooks in anticipation of future extensions. Instead, build an architecture that exposes its use cases, keep your code base as small as possible, and do not over-engineer your initial design (YAGNI). If your code is rigid, you are likely to add a lot of anticipatory design elements to minimize the amount of changes you will need to make later. Evolve your software from a Simple Design that is flexible, reliable, and easy to understand.
A good software architecture is one that clearly communicates its intent. It should scream use cases. An accounting system should look like an accounting system at first glance. The first thing you notice should not be the platform it runs on, the frameworks it uses, or even the language it's written in. The names and structure of the folders, components, and classes should clearly indicate the purpose of the software — without even looking at a single line of code. You should have to do a little digging to determine if it is a windows, web, or mobile application. If your software is portable, the platform it runs on should be a detail that is easily changed. Your architecture should first communicate use cases — frameworks and tools should be buried within loosely-coupled modules.
Avoiding redundancy within your code will greatly enhance many structural qualities such as readability, maintainability, extensibility, scalability, security, and many others. As the DRY principle states, Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.1 This helps to keep logic loosely coupled so that a change in one method, class, or component will affect all related logic predictably and uniformly.
How many times has a user story ended up on your backlog only to sit there for years, eventually to be deleted? How often has your customer changed their mind after attending a sprint review? The fact is requirements often change. And work that is done in anticipation of customer needs often goes to waste. That is one reason why YAGNI is quoted so often in engineering circles. Because more times than not this type of work never gets done.
1Hunt, Andrew; Thomas, David (1999). The Pragmatic Programmer: From Journeyman to Master. Addison-Wesley. pp. 320. ISBN 978-0201616224.