ETech day 3: Building Basecamp
Writing about web page http://www.basecamphq.com/
This is a talk by Jason from 37 Signals, who make subscription-based web applications. I really enjoyed the session, and I have a sneaking suspicion that that's because these guys are exactly like us; my notes from the session bear a striking resemblance to the sort of philosophy that we try to embrace at Warwick.
- Reduce mass
- Embrace constraints
eg. 37Signals had prior commitments, a 7-hour time difference, a lack of proximity, they were self-funded, they were a small team. So the time difference, for example, means that they get some time when they can communicate but also some time when they can't bother each other. Lack of proximity means they can't have meetings, so they have to communicate via IM and email, and that forces them to be precise, to be specific, efficient.
- Get real
Start with the UI so that you can sit in front of the app for as much of the development time as possible. Functional specs achieve nothing - they're an illusion of agreement (that's a nice sound-bite about specs).
- Manage debt – debts in terms of hacks in your system, code that needs refactoring, features that are overdue.
Especially in small teams, you need people who are positive, well rounded, a quick learner, trustworthy and a good writer. People don't talk as much as they used to; they IM, they email, they publish to the web.
I'll take someone who is happy and average over a guru who is disgruntled and frustrated.
Doing smaller, more focussed and specific software gives you:-
- Lower cost of change
- Less room for error
- Less support required
- A basis to encourage human solutions – encourage people to find their own way to use the product, to be imaginative and flexible (eg. TaDa lists, where people use their own keywords and tagging to support dates or categories or whatever – nothing built in to the software to accomplish this.)
Build half of the software:-
- Say no by default
- Listen to the product
- Ignore details early on because you have scope to change
- Improve what you have
- Decisions are only ever temporary, especially if you are keeping the cost to change small.