Mitch Wheat - Treat the cause, not the symptoms!

OK, hopefully that title got your attention! More about it later…

I’m starting to realise that a technique I’ve successfully used to build applications in the past is closer to Test Driven Development than I had imagined. Namely creating paper based screen mockups, acting these through putting yourself in place of the user, and then building live prototypes. Let me begin at the beginning…

Last week I purchased an e-book from 37Signals, “Getting Real: the smarter, faster, easier way to build a successful web application”. It cost US$19 (approx. AUS$25) and was well worth the money. But check this out; you can even read it for free here! Free! How cool is that?

It says ‘web’ in the title, but it is equally applicable to non-web based software. The idea is to minimise non-executable artifacts (i.e. not actually running in the application), such as doco, diagrams etc…This is very similar to the theme that runs through agile development.

• It’s about staying small (and agile).
• It’s about less of everything that’s not essential.
• You start with the interface, the actual screens that users will interact with.
• It’s about short iterations (just like agile), and reducing the cost of change.
• And more specifically, it’s about delivering just what customers need (just like agile).

Just like TDD, we deliver better results because we are forced to think about the actual problems we are trying to solve, rather than our ideas about how they should be solved.

[I did a short stint at a home loan company where they did things the opposite way: create a load of throw away, static mock up screens rather than real pages, and produce documentation that is out of date the minute you publish it. But I digress…]

I was amused to see a quote from the Elements of Style, on vigorous writing, as I blogged about the similarities in the process of software development and ‘good’ writing a while ago here.

One description that really stuck in my mind was: bloated, forgettable software dripping with mediocrity. Gotta love that for a put down!

OK, so we come to the central tenet of this eBook: you don’t need tons of money or a huge team or a lengthy development cycle to build great software. Less software, less code, less mass. More simplicity for your users. More user buy-in and more users who are passionate about your product.

Here is some of the condensed ‘Getting Real’ advice:

Use a team of three for Version 1.0
Start with a developer, a designer and someone who straddles both worlds. Starting with a small team will force you to make trade-off decisions early in the development process. Such a small team will communicate more effectively and efficiently than a larger one.

Let limitations be your guide to creative solutions
You are never going to have enough of all the things you would like; be it time, money, people etc. Don’t worry! Constraints are great for driving innovation and putting the brakes on ‘feature creep’

What does your application stand for?
What makes it different than other similar products? Why is there a need for it? Before you even think about coding you need to know the purpose of the product you are going to build - the vision.

Ignore details early on
Always work from large to small. Let the details reveal themselves as you use what you are building.

“Getting Real” continues for a good 130 pages more than I’ve briefly skimmed over here. It’s worth a read.