How we built Dojo Learning - part 4

This is part four of a series of posts about how we built Dojo Learning (part one, two and three).

Don't bite off more than you can chew

We've been developing internally at Dojo a bit like a traditional software project and a bit like a startup. It's much easier to push bug fixes to customers, since you're all on the same system. So bug fixes get fixed much faster, and more easily too since we only have to test against one server platform (although we still have to test in each browser, no escaping that one).

But the quick push model only scales so well for larger change sets, especially ones requiring changes in several areas or changes that need to be made in concert with each other. For those, we've adopted a more traditional "here's what we want to do for the new version, let's do it" top-down approach.

This removes a bit of agility at first, but gives us several benefits. First, we get to announce each major update as a new version. New versions are one of the few things bootstrapped startups can really use to attract attention from the press, so we benefit from that.

Second, it gives us a specific goal that we're working towards, which helps keep us motivated. And third, it gives us a chance to put the whole product into question and ask all those fundamental questions again.

Lastly though, it gives us a finite goal and limits so we don't get into a scope-creep rut or start adding things that are outside of our agreed upon features for that release cycle.

Break things up for easier digestion

You have to break things up into manageable sizes, or you'll end up with chaos, or worse, wasting time on the wrong problems. We try to break things up into the smallest components we can and then plan those out with wireframes, lists of actions, user interactions, database schemas, etc so that we have as clear of an idea of a feature as possible and how to implement it.

It also helps ensure everyone is talking about the same thing, and that you don't mean something different when you're referring to a feature than the rest of the team means.

Once we've broken each feature down into individual wireframes and tasks, those become the to-do list and away we go.

Set a date

We actually work towards specific release dates internally, and while they're not set in stone, they do help us plan how we spend our time and what we can fit into a development cycle. They also force us to think through our features so we don't over-promise and miss the date.

For me, even though I've done the planning and preparations, deadlines still create a bit of uneasiness early on, but once I'm into a groove I find they create a bit of excitement.

The key to realize is that unless you've already begun marketing or advertising efforts around your deadline, it can be adjusted. It's just an artificial date you've set, and pushing it back isn't the end of the world. And it's a good way to get everyone in sync, and to help give the marketing side of things something to plan around too.

If you liked this post, make sure you subscribe to our blog by RSS or email so you catch the rest of this series of posts.