Clean Architecture — Two values
A chapter in which Uncle Bob tells us what are the true values of software systems.
About this article
This is a part of my series of articles where I go chapter-by-chapter through the “Clean Architecture” by Robert.C.Martin and share my thoughts, analysis and pieces of knowledge I’ve gathered. Previous part can be found here.
The two values
What are the values which any software system provides?
Well, the first one for sure is the profit which stakeholders make or save thanks to programmer’s work. It can be anything, from money to some functionality or time saved by automatizing a mundane task for example. This kind of profit is called behavior value.
And so you may ask, what’s the other one if the first one is so general? According to Uncle Bob the second one is what he calls the structure value. It’s defined as the ease and promptness of creating and changing features in an existing system. Because as it has been explained in the previous part of this series, technical debt and swampy code base are a bane of all bigger software projects.
In real life projects the requirements are constantly changing and expanding. Programmers have to choose all the time between creating new features (behavior value) and maintaining proper structure and architecture of code (structure value). Obviously stakeholders would love for new features to be applied almost instantaneously, without wasting time for some design-mumbo-jumbo which they neither understand nor care about. Developers should be the ones who create pressure to maintain standards of code care. Good design is the only way for programmers to stay productive in face of the ever increasing system’s complexity.
Obviously there is no fit-all type of architecture, every type of it has it’s own drawbacks and favors specific types of projects. But as Uncle Bob put it:
Architectures should be as shape (type) agnostic as practical.
Which one is more important?
Ok, now we know what are the types of provided values. But which one is more important? Which one should have more focus put on by the project teams?
When you think like most people would, short term benefits in shape of working features are more important than some fairy-like ability to change things later, which may or may not come in handy sometime in the future. Even as the great Mark Zuckerberg once said:
Move fast and break things. Unless you are breaking stuff, you are not moving fast enough.
Well, it’s not really true. In our theoretical world of articles on one hand we have a program that works perfectly but cannot be changes without breaking something. And on the other we have buggy program which can be easily change, programmers work with it like it would be a breezy greenfield project. From this point of view it’s obvious that the structure value is more important as it ensures that our project will be profitable long into the future.
I know that the quote by Mark might be a little bit misplaced in this context, fast iterations and quick changes do not necessarily equal bad architecture. But at the same time I know quite a few people which use an approach similar to Mark’s as an excuse for low quality design and blind-ish code creation with no regard for the future of their projects.
Urgent or important?
I assume that everyone has at least once seen the Eisenhower matrix, which assigns all problems two statuses. First one is it’s urgency and the other is it’s importance.
As President Dwight D.Eisenhower has stated himself:
I have two kinds of problems, the urgent and the important. The urgent are not important, and the important are never urgent
If we translate this quote into the software world then we can come to the conclusion that behavior is urgent but not important and structure is important but not urgent.
The mistake that business managers and developers often make is their failure to separate the urgent tasks by their importance. Only few tasks are ever truly both important and urgent. These assignments should be taken care of before anything else obviously. These assignments are even more important than the architecture.
The problem arises when all the tasks suddenly become both important and urgent. That’s when architecture is being left behind and the whole project suffers. It’s the responsibility of developers to put their feet down and to separate tasks that really are important away from these which seem to be but in reality aren’t.
Architectural struggle
When developers fulfill their responsibility of tasks separation, often the struggle arises. Management, marketing and sales teams push importance of all the features to be sky-high. It’s not easy but that’s the time when software teams have to make other teams realize that good architecture is not something that can be taken lightly. Time spent on it now will save the project ten or even hundreds times that in the future. Without this struggle, the whole system will become a buggy mess of unrefactorable swamp, and it will be a fault of development teams, for they did not fight hard enough.
Summary
I encourage you to share your feedback and point of view with me, it’s the best way for all of us to learn and grow. Also, check out the complete book, it’s a really wonderful source of knowledge for any developer. My articles are just a shallow summary of information that can be found in this book, do yourself a favor and read it whole! Next part of this series can be found here.
