Wednesday, February 10, 2021

The Yin and Yang of the architect

The role of a software architect varies between companies as do the qualifications for the title. Having carried the software architect title for years, I've recently had cause to reflect how I've operated and what that implies about my philosophy on the role.

Much criticism is levied against ivory tower architects who produce "dreamy architectures that are detached from IT, business and budgetary realities" or the title inflation that makes architects indistinguishable from "most senior engineer".

For me, I've found balancing both to be the most effective. The architect needs to be able to develop architecture, designs and plans that are both forward thinking but also constrained by what's practical, and what's truly needed. A good way to know what's practical and required is to spend time in the trenches, likely as the most senior engineer.

Playing both roles creates an evolutionary feedback loop from design to implementation and back. This can result in discovering standards that need updating upon recognition of confusion, it could be finding a need for additional templates or libraries to smooth out the difficulty of a working particular technology, or the need for enforcement mechanisms to keep developers coloring within the lines. You feel their pain. It also establishes the credibility of the architecture, since the architect is the most senior engineer.

There are lots of things that can be discovered in the course of development, using the same tools, processes, templates, libraries as the rest of the team. But you can't spend all of your time there. At some point you need to step back out and build those standards, libraries, prototype the use of new tools, etc, i.e. be the architect.

 

The image that best represents my thinking is the yin and yang symbol. The architect and the "most senior engineer" are balanced forces, forever cycling with a fuzzy boundary between the roles. Additionally, there are seeds of each within the other. When acting as the architect you carry the seed of the engineer (how will this be applied, used, misunderstood), and when the engineer there is the seed of the architect (where can this be standardized, re-used, baked into a framework, replaced with something better).

Depending on your environment, and the size of your team, it may not always be possible to operate like this, but I find it a compelling model.

Sunday, February 7, 2021

Best in shows

It may have taken me a while to get on the binge watching bandwagon that everyone else seemed to start with the first of the lockdowns. I’ve watched some pretty good shows lately, which reminded me of many of the other shows I’ve really liked. 

Here’s my recommended list, in rough chronological order, of when I saw them not necessarily when they aired.

  • Warrior
  • The Boys
  • The Mandalorian
  • The Expanse
  • The Watchmen
  • Kingdom
  • Vikings
  • The Walking Dead
  • The Last Kingdom
  • Boardwalk Empire
  • Justified
  • Game of Thrones
  • The Wire
  • Entourage
  • True Detective (Season 1)
  • Marco Polo
  • Sons of Anarchy
  • Breaking Bad
  • True Blood
  • Deadwood
  • Battlestar Galactica
  • Farscape
  • Spartacus
  • Rome
  • Firefly
  • The Shield
  • The Sopranos
  • Six Feed Under
  • Babylon 5

Friday, January 29, 2021

Tuesday, January 26, 2021

RIF Notes #65

RIF Notes #64

"A management obsessed with productivity usually has little patience for the quiet time essential to profound creativity." —Gordon MacKenzie

RIF Notes #63

"My code can’t be tidier than my thinking. The purpose of my tidying is to clarify my thinking by manipulating the code. The code ends up better, but because I understand more not because I somehow forced it to be better in spite of my confusion." -Kent Beck

RIF Notes #62

“teams at Amazon are long lived service teams. Amazon does NOT do “projects”. Funding is continuous. This ensures attention to operational quality, reduces tech debt, avoids lock-in to legacy technologies” – Adrian Cockcroft