Slashdot Mirror

I don't see anything in there anywhere about swearing.

http://www.systemsguild.com/GuildSite/TDM/Professionalism.html

I've read two really good items on the subject of estimating software schedules. The first is Painless Software Schedules by Joel Spolsky, the Joel in Joel on Software. It's a quick read, and a lot of the comments here are giving the same advice all spread out. Even more useful is Waltzing With Bears by Tom DeMarco (ISBN 0932633609) (very talented author, I strongly recommend Peopleware to everyone), which is about managing risk on software projects, especially as it relates to time. This is one of the fundamental errors in the question "How long will it take?"--the inquirer wants an exact amount of time, so if you say it will take four hours, it should take exactly four hours. The problem is, you may luck out--someone may have had that feature in the program once already, and it was removed, so all you need to do is call some fully-tested code from a different place, or there may be high coupling, so that what looks like a really simple, straightforward change is insanely hard. Those two factors put together means giving an estimate should be something like "No more than forty hours, 75% probability of finishing within twenty-four hours, 50% chance of finishing within six hours, 25% of finishing within four hours, no quicker than an hour." As part of Waltzing With Bears, Tom DeMarco (and I assume others) put together a Riskology spreadsheet, intended to allow you to estimate schedule probability curves, which allows combining multiple probability curves to get an estimate more like "No faster than eight months, 75% within six and a half months, 50% within five months, 25% within ten weeks, no faster than four weeks." And always make sure the first number people hear is the worst case scenario--that's the one they're going to remember.

Other reading:
Coding Horror, How Long Would It Take If EVERYTHING Went Wrong?
Software Estimation: Demystifying the Black Art by Steve McConnell
Google on Estimating Software Projects

Tom DeMarco has a nice book about this called Slack.

By being busy we fool ourselves into thinking that we are being more efficient.

Waltzing with bears by Tom DeMarco and Timothy Lister. And yes, they provide spreadsheets to calculate probabilities.

I'm amazed to see so many suggestions regarding promotion possibilities -- I wonder if you all work in a different IT industry to me. I'm only 30 (don't laugh), but I'm already as high up the technical career ladder as it's possible to be at my workplace (and changing jobs would be a demotion based on the job ads I've seen). To get any higher I'd have to become a manager, which doesn't yet excite me. Isn't there more to a career than just climbing the ziggurat?

Anyway, if you are a manager, the best advice I can give is to find a copy of Peopleware: Productive Projects and Teams, read it, and use its advice. It's a thin book, but it is +100 Insightful when it comes to employees. Some links on the book:

• Publisher's info at Dorset House
• Slashdot review from some time in the past (can't find a year on the page).
• Freshmeat review from 2002.
• Atlantic Systems Guild, consulting company run by the book's authors.

The big problem is that different people learn in different ways. Check out this description of the various polarities in preferences and how they affect the way people learn.

Personally, I have found the traditional "skill-based" training to be largely a waste of time - I just don't enjoy working through a bunch of exercises with canned explanations, esp. if the trainer is a professional trainer as opposed to a professional developer/manager/architect or whatever. The IT training business (certainly in the United Kingdom) is pretty much industrialized, and geared towards turning out as many Microsoft-certified whassnames as possible. Attending a course with one of the big training shops is in my experience a case of working through a bunch of thick books with more-or-less real world examples with doctrinaire solutions. There is rarely an opportunity to explore alternative solutions, and the goal seems to be acquiring a bit of paper saying "MS certified whassname" rather than learning anything new.

On the other hand, I have attended a bunch of excellent "training" events such as those run by the Atlantic Systems Guild which includes Tom DeMarco and Tim Lister, where there was an agenda of topics to discuss, but little or no "here's a book, read it, and we'll do a bunch of exercises" nonsense. The format was "here's an idea, or a story that happened to us once - let's consider what it means for you", along with a bunch of hands-on sessions exploring some of the topics.

So, all this comes down to - work out what your learning preferences are (there's a questionaire here, and make sure you tailor your training to it if at all possible.