threehv

I’ve been a fan of Basecamp for years.  Ever since I heard about it (all the way back in 2005) I’ve encouraged its use whenever possible.  It has pretty much become the de-facto standard for web-developers across the world.  Part of its appeal is its unstructured nature – it’s basically a series of messages with task lists and dates.  Use what you want, how you want.  Each task item has three variables – title, task list it belongs to and position in the list (and they recently added a comments stream so you can discuss the item).  

However, sometimes its laissez faire approach is too unstructured.  So you may move to a bug-tracker.  The big problem there is, no matter how simple you think things are, how many fields you make optional, there is always an issue about complexity.  What takes precedence?  The issue-priority or the version that it has been assigned to?  Or does something over due date take precedence over both of those?  

You see, adding anything increases the complexity exponentially – going from three variables in Basecamp to eight or nine in a bug-tracker (and that’s a simple bug-tracker, not like the beast that is Bugzilla) means you have to define what each of those fields means to you and how they interact.  

Even the most apparently simple piece of software has this inherent complexity – look at the massive variation in Twitter clients – despite Twitter being nothing than a single 140-character text field.  All of which shows why software development can sometimes be very very hard to get right.

This entry was posted on Wednesday, February 11th, 2009 at 10:23 am and is filed under Designing Great Software.