Friday, February 17, 2012

Design (a Little) Ahead

One of the fun topics developers and architects like to throw around is "emergent design". It's shown as a counterpoint to "big up front design". The fundamental idea is sound: don't design for the next two years since it's likely to change. Instead, design for your current needs. For many of us, that translates to designing for the current sprint or iteration.

But then the next sprint starts. And someone groans, "Oh, shoot! We're going to have to rework that!" Reworking and refactoring is fine. When you're doing it every sprint, though, it starts to be a little ridiculous.

Let's take an example. Suppose we're building a recipe sharing application. During this sprint we're putting the basics in place, and at the end of it we have the ability for users to sign up and to create a recipe. We haven't yet specified what goes into a recipe, so for now it's just a free text box that is an attribute of the user. Hooray!

Now sprint 2 starts, and our stories include such surprises as "Users may have more than one recipe", and "Recipes have two components: ingredients and instructions".

"Oh, shoot! We're going to have to rework that!"

If we had looked ahead just one sprint, we would have seen that recipe is a separate concept from user, and we would have designed it accordingly. We would have saved ourself some time.

I'm not advocating for huge designs. But look ahead just a little bit, and design for that. After all, it's highly unlikely that absolutely everything will get changed between sprint N and sprint N+1. Some things will, but for the most part, it's safe to design a little ahead.

Build for this sprint. Design for this sprint and one or two after. Looking just a little bit ahead can save you a lot of time.

No comments:

Post a Comment