Earlier this year I attended the O’Reilly Software Architecture Conference in NY. One of the keynotes was presented by George Fairbanks on the concept of Intellectual Control. Incidentally, George is the author of my favorite software architecture book, Just Enough Software Architecture. You can find the keynote here. He argued that software developers no longer maintain enough reasoning about their solutions with the focus on automated testing which provides more statistical control. He reviewed software development from the past (think 80’s and 90’s) and that teams were regularly deploying on a short, regular cadence without any automated testing. …


I was looking through some old notes and found this great quote that I had captured from an InfoQ presentation on agile mindset by Shane Hastie:

“If you don’t change the way you do work the day after a retro then you have failed.”

I’m a big fan of retrospectives. When I teach agile principles and practices I always stress that, in my opinion, retrospectives are the most important agile ceremony. A key principle of agile is continuous improvement. Retrospectives facilitate this principle by providing a regularly scheduled time to assess the team’s performance, identify improvements, then assess those improvements…


Martin Fowler recently released a new blog describing the concept of Integration Tests and how the term is used in different ways. It is a good, short read. Martin advocates using “narrow integration tests” which:

  • exercise only that portion of the code in my service that talks to a separate service
  • uses test doubles of those services, either in process or remote
  • thus consist of many narrowly scoped tests, often no larger in scope than a unit test (and usually run with the same test framework that’s used for unit tests)

In general I think this is a good idea…


I started this topic thinking about all the time technologists spend in meetings and how they impact agile delivery. I’ve come to believe that most meetings are hindering rather than helping delivery. They don’t facilitate what I would consider to be agile collaboration. Don’t get me wrong, not all meetings are bad. I’m not advocating all meetings should be abolished. But wouldn’t that be nice? But in the context of an agile delivery, we do need to understand why meetings are called and the boundaries they establish.

First, let’s look at some general definitions:

meeting — the act of bringing…


I enjoyed this article on the importance of removing dead code as part of managing technical debt. In the article, which is an interview with Kevlin Henney based on a talk he gave at the European Testing Conference 2017, Kevlin gives the example that some of us may have heard about where unused code in the New York Stock Exchange system caused $440MM of losses in 45 minutes when it was mistakenly awakened by a 3rd party high-speed trading system.

Obviously an extreme example, but the root cause was something that any developer can relate to: code that is unused…


Architecture option for the Denver Art Museum

I’ve written lately about driving architectural simplicity. One driver of simplicity that I covered in the article was understanding decision trade-offs. This implies that you have more than one option from which to choose when making architecture decisions and that you’ve identified the trade-offs for each option. Just ensuring that you consider more than one option provides you a path to actually make a decision, and then, hopefully, consider simplicity as one criterion.

When identifying solutions I try to consider at least two options for anything more than a basic problem. Rarely is one option the only possibility. Identifying more…


Dan North had a great tweet the other day regarding opportunity to learn from code reviews:

Asking questions moves the conversation from contentious to collaborative, from directive to contemplative, from assuming to understanding, and from judgement to mutual learning. Though Dan mentions that junior developers might consider using questions as part of reviewing code, I’d actually extend that advice to the entire team, regardless of seniority. Using questions can take (some of) the defensiveness out of the interaction and puts everyone in learning mode. It also sets the stage for the code writer to consider the reason behind the…


I just posted a new article on InfoQ:

https://www.infoq.com/articles/driving-architectural-simplicity

I’m a big fan of simplicity. Simple architectures are generally easier to communicate, build, deploy, operate, and evolve. However, I’ve found that simplicity as a system quality is often underappreciated. The article dives into the benefits, challenges, and specific practices of designing and maintaining simple architectures.


I saw a great metaphor for technical debt the other day in a presentation on agile architecture. The speaker likened technical debt to a messy kitchen and I wanted to explore the idea further here.

I am a big believer in the concept of technical debt. And like any good technical concept, it must have one or more associated metaphors to help drive home the idea. If you aren’t familiar with the concept of technical debt check out this link for an overview which uses the “old faithful” metaphor of financial debt.

In the messy kitchen metaphor, the mess of…

Brandon Bryson

Software engineer, tech lead, architect blogging about my thoughts and experience with software development, design, architecture, agile, and security.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store