System Architecture: Messaging Business Events

Originally published on April 14, 2017 at

When we started on our journey towards bounded contexts, we wanted to maintain the small-team, focused, feel that we had enjoyed with as a single team supporting a monolith. One strategy we adopted was to limit our dependencies between the teams and, by extension, the different bounded contexts. We did not want to introduce temporal runtime coupling between components developed by different teams because that would reduce the autonomy of these teams and limit our ability to develop the products that we wanted to develop in the ways we wanted to develop them.

For example, imagine one team is developing an API and they have a goal of a 50 millisecond response time for 98% of requests. If they have to take a runtime dependency on another team that has 20 millisecond response time for 90% of requests but a 200 millisecond average response time for the remaining re…

System Architecture: Bounded Contexts

Originally posted on Dec 2, 2016 at

Microservices architectures are currently highly fashionable. The question of how small a microservice can be is asked regularly. Is micro even small enough? Can we build pico-services? At Pluralsight, we have chosen to go a different direction. We are focusing on team size.

In order to maximize throughput, how big should a team be? One pair of developers? Ten pairs of developers? For the time being, we have settled on two to three pairs of developers with a Product Manager, a UX Specialist and a DevOps Engineer. Given this team structure, we ask ourselves how big of a chunk of our system can that group truly own?

We expect a team to own the discovery, design, development, delivery, and production support of their part of the overall system. This means that we have to divide the system carefully. If the creation of a new feature requires coordination across multiple teams, th…

Favor Feature Toggles over Feature Branches

As you may be aware, our development process at Pluralsight is a kanban style of agile. We limit our work in progress so that we can maximize the flow of new features into production. When you combine this with our focus on automated testing, use of a continuous integration server, a distributed source control system, and single click deploy/rollback, the result is continuous delivery. Even with a fairly small team, we almost always deploy new features more than once a week and occasionally two or three times in a single day.

Because of this style of development, we occasionally saw the Big Scary Merge described by Martin Fowler. As a team, we value continuous improvement, so we researched ways to address problems of merging when working on feature branches. So despite some skepticism, we have been experimenting with feature toggles. Many developers are familiar with the term, but there are few examples of how it is done, so allow me to share how we do it in our ASP.NET MVC web site.

Someone is wrong on the internet!

Unfortunately, this time is it me. I wrote about the differences between how I perceive TDD and BDD. Unfortunately, I didn't do my research. Instead I based my understanding on hearsay and assumptions. I knew that Dan North had coined the term and I should have looked for his easy to find blog post.

Instead, I got most of my knowledge of BDD from discussions at local user groups. This almost always took the form of "Tool A is a TDD tool while Tool B is a BDD tool." Because I found this to be a fairly uninteresting distinction, through the course of several discussions, I effectively invented a definition of BDD that I found more valuable to me and my team than "using Tool B means we are a BDD shop."

When I saw a discussion of the topic on Twitter, I interjected myself and asked for clarification. Luckily, I asked good netizens (Avdi Grimm, Angela Harms) rather than trolls and I got some helpful advice.

So, I was able to learn a valuable lesson this weekend: do …

Know Thyself

So you've probably heard this ancient aphorism, but what does it have to do with software development? Very few of us deliver software in isolation. We generally have customers, managers, testers, designers, operations, and fellow developers on our development and delivery teams. Because we have to interact with all of these other people, it is in our best interest to know who we are, what motivates us, and what our strengths and weaknesses are.

For the last couple of years, I have intermixed a few books and videos on psychology with my standard technical fare in an effort to get to know myself better. It appears that many in our industry are doing the same.

At the Agile Alliance 2011 conference, Dr. Barbara Fredrickson spoke about Why Care about Positive Emotions?. Linda Rising has spoken about The Agile Mindset at several conferences including Agile Roots 2012. At the recent WindyCityRails conference, Steve Klabnik spoke on Development and Philosophy. And many members of my loca…

Tales of Distributed Teamwork

What follows are three stories of actual distributed teams that I have been on. These are my stories and my version of events. Others involved may tell different tales.
· · · A Tragedy in 3 Acts Act I The Scene
It was my first agile project! I didn't know it though. None of us knew what we were doing, but we knew that anything that got in the way of satisfying our customers had to go. We were pretty good. We were so good, in fact, that our corporate entity took control of the project.
The Team
With two developers, our field-support/QA person, and our saleswoman/business expert, this was a small, tight team who enjoyed strong support from our executive sponsor.
The Tools
The developers employed a tactic of working together (we might call it pairing now). We released more than once a week and we all worked directly with our customers daily. We also met daily to discuss sales, installations, features, and bugs.
How it Felt
It felt amazing. We had many happy customers and we worked with them…

.NET web.config Transformations Revisited

I recently posted about how to use a custom MSBuild file to run web.config transforms in your continuous integration process. This is the methods we have used on a couple of my previous teams.

At Pluralsight, we use a different method. We do our 1-Click deploys through a custom web application that takes the output of our TeamCity builds as it's input. As we built our deploy tool, we chose to avoid calling shell processes. This meant finding an alternative to the MSBuild file for web.config transforms. What we came up with is the following.

using System.IO; using Microsoft.Web.Publishing.Tasks; namespace SiteDeploy.SiteConfiguration { public interface IConfigFileGenerator { void TransformWebConfig(string environmentName, DirectoryInfo sourceDirectory, DirectoryInfo targetDirectory); } public class ConfigFileGenerator : IConfigFileGenerator { const string webConfigFileName = @"web.config"; public void TransformWebConfig(string environmentName, Dire…