Out of ten bullets on software architecture, this is the first: the realization that there is no silver bullet.The series emerged as s result of software architecture discussions in a variety of communities. Many people thought they knew how to always get software architecture “right”, and usually they were proven wrong over time: there is not the one thing that is always right. There is no one architecture or architectural style that always fits, no one methodology (not even the one sketched out in the “ten bullets on software architecture”) that always works.

That doesn’t mean that methodologies, styles and architectures aren’t useful. All I want to say is that they are not always equally useful, depending on project context.

To illustrate that deep and extensive study of architecture topics may even get in the way: More often than not, “architecture” is not just an engineering way of finding a good-enough solution to a problem, it is also a language to communicate in a team. If you end up with two different “my architectural style is universally right” people on the same team, assumed knowledge about architecture is your first roadblock to an informed discussion. Eventually, you want the entire team to understand the decision so that everybody will embrace the decision in everything that is done throughout the rest of the project.

We’ll dig into “what’s right, what’s wrong” more in the second bullet (Reminder: it’s “There is no good or bad architecture. There is adequate architecture.”), but the first step towards a civilized discussion on software architecture is this:

There is no silver bullet

Without it, everything else will work only accidentally.

Tip to the hat: Of course, title and content of the present article live and breathe the famous “no silver bullet” article contained in the 25th anniversary edition of “The Mythical Man-Month”. Thirty years after it’s writing, people still need to be reminded of it…