Accelerating Agile: Small, separate pieces

Puzzle-piece

My favorite programming approach of late is code a little, deploy a little. I've adopted this approach partially because I get interrupted a lot, but also because that's how software is being maintained once it comes to production. Namely, there's rarely a time to do extensive refactoring and whatever new functionality you want to develop, you must squeeze it into existing code base using only local refactoring. Additionally, when you're developing a component from scratch you have the entire model of it in your mind just like pieces of a puzzle together make a picture. But after a few weeks or months, the big picture gets distorted and you're left scrambling your head how individual pieces fit into overall system. If you start with little pieces instead, you are forced to develop individual pieces in such a way that you can put them together only based on the local information without too much reliance on the big picture. Code a little, deploy a little approach requires having a continuous deployment infrastructure in place that is capable of quick and frequent deployments. In my experience that's only possible if your system is composed of small, separate pieces. If your system is monolithic, you always have to wait five minutes for all the unittests to run on your system before you push code, five minutes to run unittests on production, and five more minutes for the whole system to restart. And that's the optimal case because more often than not your coworker has messed with a master a bit and you have to wait for him to resolve merging conflicts or there are pending database migrations that you shouldn't run just yet.

Having a ton of small, separate pieces is a nightmare on it's own, so the trick is to strike the right balance between having a big monolithic monster or a million annoying mosquitoes swarming around you. The rule of thumb that I'm using when deciding on granularity of a system is this:

  1. A deploy should in most cases be a concern of a single developer only.
  2. A developer should in most cases concern himself with deploying a single component only.
Enhanced by Zemanta