Posts

System Architecture: Bounded Contexts

Originally posted on Dec 2, 2016 at https://www.pluralsight.com/tech-blog/system-architecture-bounded-contexts


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…

Are we Agile yet?

TL;DR
It doesn't matter what process you follow, the people involved will cause the success or failure of a project.


In the beginning, there was chaos. Developer were making software, but business couldn't really manage it.

Then came waterfall. This was nice because it was easy to manage. And luckily, we now had computers to manage the schedules, because they were always slipping.

When it was realized that developers are virtually incapable of estimating how long it takes to do anything longer than a few months (or more often days), clever managers came up with a solution: shorten the cycle! It was called the spiral method, and it is an iterative waterfall. Sure the schedules still slipped, but they didn't slip as much because the iterations were shorter. Thus was the Spiral method born.

While the managers were trying to fix waterfall (because they loved it's predictability) other smart people were trying other ways to solve these problems and learning from their exp…