Writing About Software Architecting

Can we write useful articles on software architecting when solutions are often too specific?

How do I do a thing? Well, it depends.

Introduction: The Opinionated Architect

This article is about my concerns about trying to write about software development and specifically software architecting. These are my opinions about software architecting: I am The Opinionated Software Architect.

Concerns About Writing

I’ve wanted to write about some of my thoughts on software engineering and architecting for quite some time. However, a concern of mine is being able to add value to readers without creating controversy. There are many ways to accomplish the same thing in software architecting, and the choices we make can be opinionated.

In software architecting, “How do we do a thing?” is often answered with “Well… It depends.” We can slowly remove the “it depends” by making the question more specific: “How do we do a thing using Typescript to create a Web Application backed by a GraphQL API using SaaS on Tuesdays when it is raining outside?”

But how helpful is an article when the question is too specific? In architecting, there are so many “it depends” to a question that once we’ve constrained the problem enough, aka removing all of the “it depends,” the article may not be helpful.

But engineering is about choice. What framework should we use? What language should we use? Which best-known practices should we follow? Every choice constrains our solution to a given problem.

And here is where things get even more tricky.

Engineering, in general, can become very opinionated very quickly. Some people like language X while others like language Y. Some people prefer ORMs, while others may like to do data modeling in SQL. Both solutions could be equally viable.

But choosing a particular approach helps us limit which tools and solutions are available. It helps us answer questions that aren’t too specific. If we can answer questions that aren’t too specific, then maybe the articles on architecting I write will be helpful.

So, I’m going to become The Opinionated Software Architect.

The Opinions

Here are some examples of what I will be applying to my articles when recommending solutions to a problem.

• I favor solutions that match a team’s experience.
• Architecting is often about effectively communicating solutions.
• I favor SQL and typescript/javascript for applications, ETL, etc.
• SQL is a beautiful language and, in my opinion, underappreciated.
• I favor solutions usable in multiple frameworks.
• I favor behavior-driven development over test-driven development.
• I favor data-driven programming in my designs.
• I greatly favor idempotent centric solutions in my designs.
• I favor frameworks that enable a very lightweight middle tier.
• I like to give other developers a fighting chance to succeed. I assume they have never used the framework I’m working in and document.
• I favor developing features based on UI and API mockups over requirements.
• I favor mockups and features based on the needs of the users.
• I favor snappy tools over full-featured tools.
• I favor a software stack that can spin up locally.
• I feel that having the ability to develop without being connected to the internet has advantages.
• I favor tackling pain points as early as possible in the software development process.
• I favor development environments that closely match the production environment.
• I favor placing “business logic” in the appropriate software layer over a sliver bullet approach of “business logic belongs in the middle tier.”
• I prefer leveraging a small set of tools and frameworks.
• When possible, I avoid code generators.
• I prefer non-technical solutions: aka, we design the problem away.
• It’s better to have less code as long as the code is easy to read and understand.
• I favor solutions that use the least number of tools and frameworks.
• I favor frameworks used by a lot of people.

Conclusion

I hope to write valuable articles on software engineering and architecting centered around personal opinions and experience.

* Photo by Christian Leu.