7 July 2009
What can you build in ~40 hours?
My biz partner and I were relaxing over a few beers the other week and discussing recent trends in software development, agile methodology, etc (and our use of these trends over the past 7-10 years). At some point in time, we started talking about how little time 40 hours (i.e., a ‘typical’ work week) really was, and generally speaking, how often little got done in most shops– best intentions aside. We decided to stage an experiment to see what we could accomplish by building an application in 40 hour chunks/sprints.
The rules:
We quickly came up with some general constraints to govern the experiment:
- The application should be web-based and ‘modern’ (AJAXy, friendly URL’s, etc)
- It should be reasonably non-trivial (no ‘hello world’ applications), but should seem achievable from an initial gut check.
- We would endeavor to rigidly follow the KISS principle– a surprisingly challenging goal in its own right.
- It should be developed as it were going to someday become a Software As A Service type of application.
- It should involve grappling with some new/untried/unfamiliar technology– just to make things more realistic
- From a software development microcosm, the world would be divided into three types: Business Stakeholders, Geeks, and End Users. The stakeholders would own the requirements, the geeks would own the code, the users would (eventually) close the requirements feedback loop.
- The project would be generally governed by agile tenets
- Where possible, we’d explore some geeky ‘bells and whistles’ just — well, just because.
- Each sprint would be ~40hrs (worked time, not wall clock time.)
The challenge:
Now that we had a mission, we needed a business goal. We decided on trying to build a software application that realized a simple time management system that my biz partner had recently adopted for himself. The systems initial basic requirements are as follows:
- Life is divided into two lists of tasks: Work Tasks and Personal Tasks
- Tasks have two priorities in life: do this week, sometime in the future
- Each task list has a maximum number of hours associated with it. By default Work gets 40 hours and Personal gets 10 hours (my partner is uncommonly ambitious with his personal hours).
- Each task would be assigned an estimated number of hours it would take for completion.
- The sum of all the uncompleted tasks in a list cannot exceed the maximum number of hours
OK. That’s the gist of it. Subsequent posts will lend details to the architecture, technology stack, challenges, and ultimate (hopefully!) success of Sprint #1.
Technorati Tags: agile, software development
3 Comments currently posted.
ALTERthought Blogs » Building A Grails App in 40 hrs says:
ALTERthought Blogs » Grails Task Management App (part 3) says:
[...] part 1 and part 2 of this series we introduced a challenge to build a reasonably non-trivial application [...]
ALTERthought Blogs » Grails App in ~40 hrs (part 5) says:
[...] Part 1: We introduce the basic challenge: Build a non-trivial app in about 40hours. [...]


[...] In a prior post, I talked about an experiment — to build a working task management application in about 40 hours. [...]