We like to use a metaphor comparing software design to building architecture. Some people accept that this is flawed. Others cling to this metaphor too tightly, seeing developers as little more than tradesmen installing carpet in a new skyscraper.

A Building Architecture project includes a Structural Engineer. Her job is to ensure the building stands up. Her job is to determine what materials are used in the wall interiors. Her job is to make sure the windows will withstand the forces of straight line prairie winds against the 30th floor.

She is active in the design. The architect defines taste, purpose, form, function, and values. The Architect’s role is to define the spaces where she works. This, in my mind, is a very different role in software. I posit that most conflict between Architects and development teams stem from misunderstanding the role of the Structural Engineer.

Lets look at a large system. I have a web application that is used to track employee time spent on projects and turn that in to purchase orders. We have concerns about using this tool on client computers exposing sensitive data. We need to manage project membership. We would also like to use that to build employee and company “résumés” used in explaining our expertise to our clients. I’m not picking this real example because I think our current incarnation of this tool is wrong, but because this tool is an example of a large system that has many responsibilities.

What should I as the Architect spend my time doing? Should I start mandating the use of certain threading patterns? Building the ERD for the highly normalized database? Or start determining the bounded contexts, core contexts, use cases, external constraints, target response times, and security requirements?

I would get my Tech Leads in to a room and discuss how each context needs to talk with the other contexts. I would focus on how the contexts are realized and coordinate with each other. I would let my Tech Leads figure out the internals.

How do I make sure I understand the design tensions between the contexts? I would need to work on several teams, pairing with developers who work deep in the code to find where our abstractions are breaking down. An building architect spends time on site during construction for just this reason.

But I would make sure the teams are still talking, and still hitting those request times. They are my system engineers. While I may or may not know better than them as a developer, my job is to teach them to make the right choices, not make decisions for them.

I told a friend of a plan. It was one of those crazy master plans that will probably change to world. He seemed nonplused. I said, “How about a writers workshop for blogging?” He said, “I don’t like writing. So why should I come?”

I won’t convince a veteran of the “Blog Battles” of ’aught 11 and ’aught 12 like him that writing is fun if he has already decided it isn’t. But maybe I can convince him, and maybe you, that blogging is important. And I’ll try by sharing with everyone why I blog.

To think things through

When approaching an idea that I may not quite completely understand, I don’t always consider it from all angles without some sort of framework. Blogging is one of the frameworks I use. By trying to think through an explanatory narrative, I come to understand what was a vague notion before.

To find later

I have come across the occasional hard fraught nugget of knowledge. Unfortunately, I have mind that is quirky about what actually sticks. Fortunately, I have referenced my blog myself.

As a shorthand for explaining to others

Nothing makes me happier when having a chat with my colleagues and being able to say, “Have you tried #{thing}?” Bonus points if I can point them to a blog post where I actually have something constructive to say.

To participate with the community

I look forward to the SEP blog battles. Not only is it fun to think about how I’m going to approach the topic, but I love reading the posts my coworkers write. It is wonderful to see a new perspective from the thoughts I’ve been having.

Because I have time

I used to spend evenings for a month at a time prepping presentations. I wrote code while watching TV with my Wife. I’m now a Dad. I would rather spend time with my Wife and Daughter than a laptop. But I still read. And since I have my phone at almost all times, I can write when my baby Daughter sleeps on my shoulder. Like now.

To improve my communications

The most important thing I do all day is communicate. Usually, it is written communication. I write for the compiler. I write to my friends in chat. I write to my team and company in email. I write code that needs to communicate to not only only my other team members, but myself when I come back to this code in the future Writing is a skill and blogging is a way to practice.

This is why I write. Your motive for blogging or not are your own. But I would recommend you occasionally write something.