Developer Drain Brain

April 7, 2010

Straightening out the development cycle

Filed under: Development — Tags: , , — rcomian @ 12:04 pm

This is me trying to get things sorted in my head.

Know your features

Features are your lifeblood. Organise them, manage them, combine them into stories. Process them with great care. Tuck them in and sing them to sleep at night.

All features are great. It’s the organisation of them that gives you the edge. A small set of coherent stories that each stand on their own will be far more useful than a complex network of micro abilities. A well managed, complex set of micro-abilities will be far more use than a vague idea that something might be good.

Don’t go mapless

It’s usually a good idea to have a high level idea of what the overall solution can look like. This lets you communicate the overall idea, discuss how things can be done and ensure that the whole idea is indeed possible. This map may include all the normal good things, asynchronous message manipulation manifolds, distributed data denegrators, partial parallel processors et al.

Keep the map light

Rather than follow the waterfall model of expanding this map until it’s a thousand page document, use a lightweight method to convey the idea. If that’s a block diagram on the back of an envelope scrawled in a coffee shop, or a powerpoint presentation, that’s fine, but convey the whole idea.

Implement features, not the map

Ignore the map. Pluck a single feature from your carefully tended garden. Build the feature as if it was the only thing that existed in the world. Don’t look to the other features to see what they need, look just at what you’re working on right now. Don’t look at the map and decide that you need the main message manipulation manifold if a simple web service will be more than sufficient for this feature. If you’re working with a single, simple document, save it in a file. Don’t add that database just because it’s on the map, follow what the feature needs.

Finish the feature

When a feature is complete, it looks like you knew what you were doing when you started writing it. It looks like you had the same thing in mind all the way through, and weren’t flip flopping from one way of doing things to another. Of course, you didn’t know what you were doing when you started, and you did flip flop all over the place. But don’t let that show on the finished product.

Lock in the feature

Have a way to automatically confirm that the feature works. Confirm this on many levels, from the outside (feature tests) to the actual code (unit tests) and inbetween (integration tests). Once a feature is locked in place, you can rest in a comfort that you know it’s not going anywhere, it’s not going to be broken and you can leave it alone and work on other things. It’s very hard to properly lock in a feature after it’s finished, so start locking it in before you start the feature. Put a lock in place for each part of the feature, then put that part in place.

The locks are part of your feature too, shoddy locks do a shoddy job of locking your feature in place.

Check your locks

Make sure you know when locks are broken. Run continuous builds on all branches of your code. Keep stats: build time, unit test code coverage, static analysis, build warnings, anything that lets you see trends in how the software is progressing. Check them.

Rearrange from the ground up

After you’ve added a new feature, the whole solution should look finished. As you add new features, don’t just bolt new code on top of the old, but make it look like the whole solution was written with the intention to have all the features that are available from the start. No code is sacred, no code is untouchable.

Lean on your locks to ensure that you’re not losing functionality or breaking a feature. Lose any locks that aren’t needed any more.

Keep learning

Use what works, find what doesn’t. This doesn’t need any special discipline, it’s what you’re bitching about as you’re writing your code. Your product has a lot to teach you. Learn it. Change things.

Advertisements

Blog at WordPress.com.