andrew burke
dot
me

about

contact

blog

rss

Putting the Soft back in Software

Posted on: 2006-05-12

Here is a slightly adapted excerpt of an email I sent to a prospective new client. I think it's a good summary of how I'd love to do most projects. We're still in the early phases so I don't know if this project will work out as planned - but which ones ever do? At least with this approach, I'm assuming things will change.

Also, this project has a simple core that can be extended, and the client is a single person who has a strong sense of her own business - this approach may not work if you're building guidance systems for spaceships!

Can you tell I've been reading Getting Real and Practices of an Agile Developer?

A few parts discuss application-specific details - these have been changed to a fictional content management system to protect the project's and the client's privacy.


For a long time, people have assumed that software should be done like the way that buildings are built: things are sketched out and planned with the client and the architect, then precise blueprints, schedules, and budgets are made, and then the building is built to exactly how the blueprints and specifications are set up - and since everything has been specified up front, there are no surprises and everything comes in on time and on budget.

Well, if you've ever had your kitchen renovated, let alone seen the 'success' of projects like the Sydney Opera House or the recent repairs to the Pickering Nuclear Plant, you know that even in the real world, construction doesn't work like that. Most Big Traditional Software Projects are planned up front, like the old Soviet economy, and often end up as successful.

Software has the advantage of being, well, soft. And modern web-based software, that doesn't require being burned to a CD, shrink-wrapped, or even compiled, is even softer. They way i build software is more like working in clay: build a general shape, make sure it looks okay, and then start putting in the details, checking for correctness and making adjustments as necessary. Applications usually have a core piece of functionality - such as creating a page and then displaying it - and then a lot of other functionality around that - such as how to manage the content, ways of navigating around the content, ways to import or export data, etc.

So here's how I'd like to proceed for our application:

  1. We'll work out a basic outline of what the application needs to do - only being specific where it's absolutely necessary. Since we're both on the road a lot right now, I'd suggest we do this with email. We'll alternate written descriptions of what we think the application should do, starting with basic 'stories' of how you hope the system would be used in real life when it's done. Eventually, we'll have a pretty good idea of what we want to do. In this discussion, we'll want to break out what things are part of the core functionality, what things are extensions of that core functionality, and what things would be great or interesting to have - these can be pie-in-the-sky things that may not even be possible, but it's good to get them all out there.

  2. At the end of our initial 'conversation' I'll come up with a pretty solid description of the core functionality and I'll get you to approve that.

  3. I'll build a simple version of the program that actually does this core functionality and runs on the web. This is the heart of the program, but is usually not actually the part that takes a long time to do. With no frills, it should be pretty easy to make sure we're not going astray yet.

  4. Once we've got an agreement on the core functionality, we'll figure out what we should add next, and I'll go away and put that together as well. We'll then repeat this step as many times as necessary. What often happens in software development is that people don't usually know what they really want - or more importantly, what could be done - until they have a real program to play with and try out. Also, requirements have a habit of changing in the middle of things - new customers, pesky lawyers, changes in the competitive environment, etc. Changes can be simply be added to the next round of updates, without having to restart everything. At the end of each cycle, we'll have a functional application. It may be ugly, boring and inefficient (I think I've worked with people like that), but at least it's a complete application with no loose ends. Each cycle will produce a better version of the application, running faster, looking better, and having more features.

  5. Eventually, we decide that the application is 'done' and we stop cycling - for now. As the application is used, we'll probably come up with other features we want to add or enhance - and that just cause another development cycle again.

What about deadlines, deliverables and money? Well, instead of planning everything up front and having it be too much or not enough (usually not enough time for me and too much money for you), we'll work out dates and costs for each development cycle. There will be a certain amount for the first deliverable (step 3), and then we can just keep incrementally building the application and we'll agree on the cost each time. Since at the end of each cycle, there will be a completed application, you can stop at any point that you feel the application does enough or you don't want to spend any more money. By working incrementally, the 'horizon' for the next deadline and the next invoice amount is measured in days or weeks and hundreds of dollars, rather than months and tens of thousands of dollars.

Previous: Things I learned at TRUGHat
Next: At BarCampTDot