I’ve been thinking a lot about schedules lately–software production schedules, deadlines, sprint plans, etc.–and I found this from my PauseOnError session 4 years ago:
Below, I’ve proposed 8 “blockers” that, if true, seem to reinforce my skepticism that you can’t really share FileMaker development: that anything bigger than “one developer – one project – start to finish” starts to break down pretty quickly.
1. We have no accurate way to quantify the productivity of a developer.
2. Yet we have a gut sense for “productivity” and the productivity of individual developers differs greatly, often by an order of magnitude.
3. FileMaker code is not legos, and no mater how adept we may be at making things discrete and reusable, the stuff just doesn’t plug and play.
4. We can’t run someone’s code through a spell checker, and we can’t look at the code and know what it does.
5. “In any sufficiently powerful system, failure is undetectable” – John Gall
6. “The key problem with software methodologies [Agile, etc.] is that, implemented by smart people, the kind of people who invent methodologies, they work. Implemented by shrubs, who will not do anything more than follow the instructions they were given, they won’t work.” – Joel Spolsky
And when you see a software project that did work, was the methodology the factor, or was there just one, really productive programmer at work?
7. “It may well turn out that one of the most important effects of open source’s success will be to teach us that play is the most economically efficient mode of creative work.” – Eric S. Raymond.
Can you have a consulting business that is mostly play? Is that why I’m drawn to the product side vs the professional services side of the software business?
8. Many of these problems were already fully articulated in the late 1960s. Thousands of very smart people have worked on this since then and I don’t think we have any real answers.
Having launched a ton of product since that talk, and done 2 years on Blueprint, I wonder if I’d say any of that differently.