The Anecdotal Software Architect

You know this guy. He is the “smartest guy” in the room and has always something to say when there is a heated discussion about the new Architecture for the system.

His opinions are super-strong and based on “facts” and personal anecdotes from years of swimming in the field. He can always find an example from a financial system he developed with C# or a toy project he built with Ruby. He claims Node.js is for kiddies and Erlang is too exotic.

And Yes, he has 15 years of experience, so beware of his extreme knowledge. He is cocky since he built a “great” system few years back.

Here is the the Anecdotal Architect.

The Anecdotal Software Architect

The problem is that this guy has very few things on paper. No facts and measurements to prove his technology is a good choice for the context. No data whatsoever except an anecdote or two, but he is good to sell and verbalize his thoughts.

He is the Donald Trump of Software Architecture which sells lies and personal biases with a serious face. Diagrams, Data and Measurements are not agile enough. He does get lucky sometimes, and builds a winning system, like a drunk guy gets lucky on a Saturday night.

What is the opposite of the anecdotal architect? the scientific architect.

The Scientific Software Architect

The scientific software architect honors the principle show and don’t tell. Instead of only verbalizing his thoughts he supports his hypothesis with prototypes (code), diagrams, documents, data, measurements and insights. Everything is clear and documented.

The scientific architect reads a lot, and uses the power of research and questions everything, including his “common sense” and experience. His common sense might make him swallow “the blue pill”, so he is very cautious.

He doesn’t have to talk crap to persuade You. Just look at the code, diagrams and his numbers based on his experiments.

The visual architect will Show you a fitness function that is desirable for the system and the measurements that prove the architectural solution is a good choice, but still something to improve over time and evolve.

The visual architect has always something to show. He has a compelling story and removes his ego and biases in favor of strong data.

The visual architect makes tradeoffs just to make the right decision. He knows that he doesn’t know everything, so he uses divergent thinking, prototyping and measurement to come to a solution.

Parallel Prototyping and Measurement

His architectural choice is a great solution for the problem, and he proves it by comparing it with X different technologies and measuring the best option with performance, load testing and security tools.

He decides not to use his favorite language since it’s not a good fitness-fit for the high throughput system the team is building. He decides to use GoLang instead of Ruby because he understands the power of AsyncIO, the related hardware-resources consumption and he measured the superior throughput under load which fulfills the non-functional requirement and desirable fitness function for the specific system that needs to be built. He values language simplicity and conciseness for easier maintainability. He discarded other prototypes since they couldn’t fulfill the requirements based on his measurements, but he is open to revisit the decision at a later point in time.

He has a clear measurement and rationalization how the proposed solution affects maintainability, performance, scalability, reliability, fault-tolerance and other relevant parameters. He knows the goal of the architecture and why the proposed solution is a good fit, but he knows everything is a bet.

The final question is: What kind of Architect are You?