Image for post
Image for post

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. …


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:

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. …


Image for post
Image for post

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 in that it focuses the testing resulting in fewer tests with faster execution. It also fits better within a deployment pipeline. However, this approach of narrow integration testing carries one major assumption: both the consuming and providing services (but probably more so the providing service) are well designed such that the integration does not affect any state that may impact future, independent API calls. For example, suppose I have three services, provider service X and consumer services Y and Z. Provider service X exposes APIs A1 and A2. Consumer service Y calls API A1 and consumer service Z calls API A2. …


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 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:

— the act of bringing two or more people together to execute some shared agenda and accomplish some shared…


Image for post
Image for post

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, in this case for years, but not removed from the system. Dead code is something I specifically look for during code reviews. When I see that a new method is created and some code is changed to call this new method, I always look to see if the old method was deleted (often it wasn’t because developers are focused on the new functionality only). That old method might still be used, and if so it is good to stay. But if the caller was the last reference to the old method then I request that the old method be deleted. …


Image for post
Image for post
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 than one option puts you in the mindset of considering alternatives. I’ve found that just forcing myself into this mindset improves creativity. However, I also rarely end up with more than three, or maybe four, alternatives. If I do find more than three alternatives I’ll try to apply a high level litmus test, depending on my solution constraints, to quickly eliminate the outliers and try to leave me with two or three primary contenders. I’ll then do a slightly more exhaustive examination of the benefits and challenges of each option. …


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. …


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 the kitchen represents the debt. When you start a project (think greenfield), your kitchen is clean and orderly. Pots, pans, and utensils are put away where you would expect to find them. Working surfaces are free of clutter. Then when you start cooking (or coding) you start to make a mess. A small project probably makes a small mess. Like cooking an egg. You might need one pan, a spatula, maybe a bowl into which to crack the egg. Maybe when you crack the egg it spills a little. You end up with a few dirty utensils and a small mess. …

About

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