Big tasks are hard to work on. When we break a big task down into smaller tasks they become much more manageable. Suddenly, insurmountably large tasks become manageable as a series of smaller tasks, each of which is easily achievable on their own. Building smaller simplifies tasks making them easier to define, create, and verify. Here are seven strategies for building smaller.
1. Reduce iteration length
The purpose of time-boxing software development into iterations or sprints is to get us good at task breakdown so we are building in small pieces. Scrum says sprints should be 1-4 weeks. Most teams have 2-week sprints. Some teams tell me they can’t build anything of value in 2 weeks but that doesn’t usually turn out to be true when you get good at task breakdown. Generally, we should think about emerging features a little bit at a time.
2. Identify observable behaviors
One benefit of test-first development is it drives developers to write code that is straightforward to assert against. We start with a failing test that asserts a specific behavior and the go about implementing that behavior, which usually happens in a two-step process. First, we fake the behavior or create “an obvious” implementation. Once we have it working and our tests are passing we can safely refactor the code to be more maintainable.
3. Identify core behaviors
Sometimes we build a bunch of features because no one took the time to consider what parts were most important. Asking what’s the least we can do and still provide some value can give insights into the key pieces to build first. Getting core behaviors working first can oftentimes save redoing a lot of work in the future and provide value to our users more rapidly.
4. Create a “walking skeleton”
Alistair Cockburn coined the phrase *walking skeleton* to mean a system you get working on day one, although it may not do much, and then add to it incrementally. The key is that it may not yet do everything you want it to but it does do something. Building a system out in this way tends to be very efficient. It also gives us constant feedback as we are always able to build and run our automated tests.
5. Peel off exceptions
Another way to build out a feature is to start by implementing the happy path and then peel off exceptions, one at a time. Start by validating constructor arguments then move to validating method parameters. Create conventions for establishing tight contracts between service and clients so exception handling is done only once, generally either during mutation or just before it’s ready to be used.
6. Keep it testable
A task is a task because it is verifiable. A task is too small if it no longer produces a verifiable result and we can’t test it. A task is too big if it is hard to verify. Tasks that are easy to test tend to be the right size.
7. Reduce cyclomatic complexity
McCabe first described cyclomatic complexity as the number of paths through conditional code. Code without conditionals have a cyclomatic complexity of 1, one conditional is 2, two conditionals is 4, and so on. Cyclomatic complexity increases exponentially as conditionals are introduced so keeping as few conditionals as possible in each method is important.
Smaller is better. Building smaller is at the very core of Agile. When we build small we can focus on what’s most important first, get feedback faster, and make work more manageable. Enough said!
Previous Post: « Seven Strategies for Vanquishing Waterfall
Next Post: Seven Strategies for Solving Problems Test-First »