I'd expected to spend no more than an hour - it's work that I first did around 2000, so I'm familiar with it.
A friend jibed that "You should've used your I.T. project management methodology".
I do have stong views on managing I.T. projects, especially large one, and they are backed up by the solid research data from Standish Group. They do apply to exactly this task of writing. Unfortunately they offer no useful guidance.
- All new programs are research projects
- If you haven't got working code, you don't know how long it can take. If it's a complex task, then beforehand you cannotknow where the 'beartraps' are.
- At any point in a project, you can only see in detail a couple of weeks ahead.
- 'Scale' is everthing [Alan Kay's argument]. Don't take on any project more than 30% larger than one you've completed successfully.
- Everyone is an efficient, effective Project Manager - it's just the Domain and Scale that change.
- Production of new Software is Pure Research. It relies on Creativity, it will take unanticipated twists and turns, you can't order "breakthroughs" to schedule, seemingly simple things can be 'too hard' and it's only Done when it's Done (The Golden Rule of Open Source). And when you're done, you probably want or need to redo it - completely - and several times.
The Standish Group's rule is: Maximum of six people for six months.
That's a summary of 50,000 detailed case studies. I think it's worth taking on board.
So I feel happy about my little project taking as long as it did.
No comments:
Post a Comment