Specs & Schedules
August 25th, 2005I just read two excellent articles by Joel Spolsky which I wish I found earlier. He explains how good specs are essential, and why keeping them updated is a must. Actually, this is a series of 4 articles, every article is gold. I made up my mind to create meaningful specs for my next project. The next article is about how to maintain schedules properly. It has been an issue of major head-scratching for me, and Joel proposes a great way of doing specs. I’m gonna copy that too. This guy rocks!
Specs: http://www.joelonsoftware.com/articles/fog0000000036.html
Schedules: http://www.joelonsoftware.com/articles/fog0000000245.html
These two are very good articles; I would like to know your views on 37signals/svn approach of NO SPEC documents what so ever?
Hi Lalit, sorry to respond late, I’m really busy with the FOSS.IN stuff.
Actually, I had the same doubts after I read about 37signals’ stance. I agree with Joel on maintaining proper schedule – and his scheduling method is pretty agile – incorporating slippage of dates, which happens all the time. But I’m not so sure about the specs. I wouldn’t say we don’t need specs at all, because having some kind of scope & specification documents is important in dealing with customers.
Maybe not as detailed as Joel posits. I certainly won’t go to the pain of creating paper prototypes except in the initial stage, to give a feel of the website to the customer. Because, as we all know, such nicely-prepared specs inevitably grow obsolete in a few months. I think this is where wikis are a major help – you note down your specs, get the customer to agree, and start working. Any changes, you ask the customer to add to the wiki or you do it yourself.
The advantage is that, our specs are not obsolete as soon as we get the first release out, and we have the history of what changes are made so far (all decent wikis support versioning). We can use this as the evidence when inevitable disagreements with the customer show up. More transparency, more agility. Both the service provider and the customer win. What do you say?
Thanks for appreciation.
Wiki for maintaining specifications sounds cool to me; though would be bit difficult for customers who have not worked with wikis -
? Which wiki you prefer?
1. Mostly people prefer to read hardcopies and collaborate through emails
2. Taking printouts would be require another how-to
By the it seems your working on plenty of wikis aren’t you
Not right now, but at one point of time I had to evaluate a lot of wikis before deciding on what to use at work (at my day job). We decided on Mediawiki, which is the easiest to install and quite a good wiki. MoinMoin was a royal pain to install, and the community support was quite bad (basically, no body cared about my problem when I posted in their user list). Only Apache.org seems to have got it running smoothly.
Trac is nice too, it has a built-in wiki with it’s issue tracker and svn browser. Yeah, I have to say, of all these, Mediawiki is my favorite. Never tried the perl-based ones, though.