The Buckblog

As I mentioned in my last post, I am recently returned from the Building of Basecamp workshop in Seattle. The last few days have been spent (besides nursing my sick one-year-old back to health) in contemplation of the things I learned in that workshop, and I’ve decided something.

I want to give 37signals’ process a try.

More than just the three mantras they named in the workshops (“Less software”, “Say ‘no’ by default”, and “Done”), they also described in great detail the process they employed in developing Basecamp. My notes on the workshop aren’t complete enough to be able to describe their terms for each of the steps, but as close as I can remember, it went something like this:

• List the high-level “features” (“ideas”, really) that should comprise the product. Don’t be too specific, and don’t try to describe an implementation.
• Take one of the features and sketch-on paper-a rough interface for it. Draw the different components of the corresponding screen.
• Once you feel good about the paper sketch, build the interface in HTML. Don’t write any code-just describe the interface in HTML and CSS (and Javascript). Leave the implementation for later-for now, all we want is a mock-up.
• When the mock-up looks good and demonstrates all the necessary functionality, plug the code into it.

The above list is bulleted instead of enumerated on purpose—this is not a roadmap, to be taken one step at a time, in order. Rather, you should feel free to throw away the deliverable of any particular step and start again if it turns out to not be acceptible (this all goes back to the “less software” mantra).

The process feels right to me. It rings true. Will it really work for me in practice? I think so, but there’s only one way to find out.

I’m going to start blogging about my progress on my financial program, Budget-Wise. I’m going to completely start over, using the process described in the workshop. And I’ll try to live by the Three Mantras.

Step One

So, step one is to list the features I need. (Not want, need. “Less software”, remember? My criterion here is “if the application is still usable without this feature, it doesn’t need that feature.”)

• Secure access
• Allocate funds to and spend from budgets, which are subsets of accounts
• Reconcile transactions against bank statements

And that’s it, I think. Lots of things the application could do (reports, graphs, charts, savings goals, and so forth), but the application fulfils its primary purpose without those things. (Naturally, there is plenty of wiggle room in the interpretation of the above list, but that’s the idea. It’s the mock-ups that help solidify what the feature set of the application will really be.)

Next step (for another day) is to pick a feature and sketch it out. I’ll start easy, with the interface(s) for securing the application. (An added bonus: you lucky readers will get to see exactly why I’m a programmer and not a designer!)