Recently, the team I was on wanted to move our source code from Team Foundation Server to SVN for reasons that had almost nothing to do with source control directly. This would be a pretty simple operation, but we didn't want to lose access to the history when the operations team turned off the machine running TFS. We couldn't find any direct paths for moving history from TFS to SVN, so instead we chose to use git as an intermediary.
At a recent Utah Software Craftsmanship group meeting, I was asked to share my experiences using MSpec and explain how TDD is different from BDD. Since I have been using NUnit for years and MSpec since February, I was able to discuss some of the differences in the two styles of testing.
First, A DefinitionTDD is Test Driven Development. This means writing a test that fails because the specified functionality doesn't exist, then writing the simplest code that can make the test pass, then refactoring to remove duplication, etc. You repeat this Red-Green-Refactor loop over and over until you have a complete feature.
BDD is Behavior Driven Development. This means creating an executable specification that fails because the feature doesn't exist, then writing the simplest code that can make the spec pass. You repeat this until a release candidate is ready to ship.
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…