In my previous article on Pragmatic Software Architecture, I wrote about the need for grounding software by defining a set of rules. Those rules make up the software’s architecture. In this article I want to explore the types of rules that can be used in an architecture to satisfy its fundamental role of grounding software.
Definitive Proof
The longer you work in software - be it in development, design, quality assurance, management, requirement analysis, or any other role or domain, including their modern “cool” names, e.g. scrum master, principal engineer, domain owner, product owner, scrum master, automation engineer, etc. - the more you learn that the only rules that ever succeed in getting followed are blocking rules such as compiler errors, deployment failures, and production incidents.
Whatever set of rules or framework people have tried to impose or implement in a software organization - be it Agile, Automation, Security practices, etc. - we always seem to find a way to work around them, not through them. Agile nowadays is an excuse for late or incomplete deliveries, Automation an excuse for moving development work from software engineers to QA or other roles not trained in writing code, Security just another bottleneck of bureaucratic checklists dedicated mostly to having good excuses for when there is a breach rather than preventing one in the first place.
We are creative people, and we are very good at using this creativity to work around rules rather than with them. That is unless we have definitive proof that those rules help us make our jobs easier and our work more remarkable and useful. And only if we are given a powerful role in choosing and defining these rules.
The Importance of Choice
In all my years in the industry, no matter how good an idea was, if significant work was not put in reverse engineering it and redefining it in a new group’s way, by the members of that group, the “not invented here” syndrome always won in the end.
Because of this, no matter how many sets of rules I could present to you as the best ones to use for defining your software’s architecture, you will never use them anyway. I would just be listening to and reinforcing my own thoughts and ideas. The only way I have found to work in the many projects I worked on, either directly or as a consultant, is to explain to you first the principles that I use, the way of thinking, and let you define and choose your own rules for your own software and team.
This is why at ProgSquad every project is unique. We have never held the same training, workshop, or any other activity twice - every time they are unique Every time we work with a new company, a new team, a new product or service, we start anew the discovery and definition of the best rules and practices in the new context.
The Only Rule for Progress
The only rule that I would ask you to follow, to have a common language, and as such a way to communicate, is the rule of the scientific method: the rule of proof. We all have our own experiences, opinions, and beliefs, but the only way to work together to cocreate a better future is by only working with what we can prove.
The “x” technology is the best one to use - prove it. This new “way of working” is better - prove it. We absolutely need to increase our focus on this domain - prove it. We must do automation - prove it. We must implement Agile - prove it. We need to focus on security - prove it.
And by proof I mean undeniable scientific demonstration, not word of mouth or statistical evidence. Do this and progress becomes inevitable - just look at how well that worked out for the scientific community around the world.
Want to Learn or Apply Software Architecture in Your Projects?
I’ve been developing and teaching what I believe are the only Software Architect hands-on learning programs in Romania for several years, teaching a variant of SEI’s Architecture Trade-off Analysis Method (ATAM), adapted and redesigned by me based on my practical software architecture and technical management consultancy experience.
It is not an off-the-shelf, one-size-fits-all training. It is more like a mentorship or apprenticeship. As such I have no links or slide decks to share. If you are interested in such a learning program for yourself or for the people in your organization, don’t hesitate to contact us at This email address is being protected from spambots. You need JavaScript enabled to view it. and we’ll help you find the best way to train you in the ways of Pragmatic Software Architecture.
If you need some help starting off a new software project or need help evaluating, upgrading, or redesigning an existing product, please contact us. ProgSquad’s consultants can be your strategic partner for every step of the way, offering quality, trust and pragmatic results on all change management, product management or technical management capabilities required for your projects. Read more about ProgSquad Consultancy Services on our dedicated website.
Looking forward to the challenge of your unique journey!
If you liked this please also check out my previous article in the Pragmatic Software Architecture series: Pragmatism in the Software World
