Posted by MonkeyClub 1/26/2026
Unfortunately Mr Schedule and the pietschy.com website disappeared. I made my own recreation using REALbasic / Xojo at the time, but never released it and faded from using it.
Joel Spolsky expanded the idea later with Evidence Based Scheduling:
https://www.joelonsoftware.com/2007/10/26/evidence-based-sch...
That takes the estimates from Painless Software Schedules, but runs a Monte Carlo simulation using your estimates & data on actual time taken, to create a confidence distribution curve graph of when you'll be finished.
The most important is that the team needs to actually use the task board (or whatever data source you use to get your inputs) to track their work actively. It cannot be an afterthought that gets looked at every now and then, it actually needs to be something the team uses.
My current team kind of doesn't like task boards because people tend to work in small groups on projects where they can keep that stuff in their own heads. This requires some more communication but that happens naturally anyway. They are still productive, but this kind of forecasting doesn't work then.
Jira is excel for task management. OOTB setup works absolutely great, and then someone comes along who wants a custom field on tasks to support <something that they read about elsewhere> and now you have to fill in that custom field. they leave, and someone else comes in and adds a new one. 5 years later you have 11 new fields that partially overlap, some are needed for some views, some are needed for other, but you can't use default boards because person Y decided that they wanted to call Epics Feat's, and made a custom issue type.
And in the end, the people who actualy use those boards just export a filter to excel and work there...
People. The problem is people.
It took me a few hours to do and as Joel says in the article, it was not a fun thing to do (jumping right into code was more fun) but I stuck with it and did the whole thing.
Then I followed that list of tasks and kept track of when tasks started and ended and I was pleasantly surprised when after a few weeks the project was done right on schedule as predicted by the excel sheet. So my experience (data point of 1) was that it works if you do it exactly how he says to do it in the blog post.
I did it only that one time so take that for what it is.
That process isn't free. For many features, it's the largest share of the work.
Even for features that stay on the cutting-room floor. Especially for features that stay on the cutting-room floor.
Usually whole subtasks need to be junked and others created.
This post from spolsky is always amusing to me because it came 6 months after Microsoft was convicted of antitrust violations to crush Netscape. So it's funny that he claims Netscape killed themselves, when the courts actually said that Microsoft killed Netscape. Obviously Netscape made critical bad decisions, but Microsoft's illegal behavior was what actually killed them.
So I'm not sure about that loss of market share being just due to MS. IE at the time was just better than Netscape. You had to be a masochist to use Netscape. It would crash badly at the silliest little things, and since websites were made with even less professional standards than nowadays those silly little things were quite frequent.
You might have gotten IE preinstalled, but even for devs who went and installed Netscape it just made more sense to use IE, because it was better.
MS preinstalled IE, but Netscape made sure only the truly dedicated would actually download and use it.
Without Netscape's mess-up I can totally see them only losing 30% of their share, and being in a good place to recuperate when MS got slapped down in court.
1) write down everything you're going to do
2) write down how long that's going to take
3) add them all up and voila! You have a schedule!
The ways this breaks down in practice would be comical if not for the fact that everybody takes it so seriously. The biggest problem is that step 1 takes longer than the actual software development task all the time, every time. That might not be _so_ bad other than the fact that it's also always completely wrong.http://scribblethink.org/Work/kcsest.pdf
https://news.ycombinator.com/item?id=13731975
https://www.amazon.ca/Limits-Software-People-Projects-Perspe...
This item makes Joel's scheduling idea a no-go at most companies. Schedules are set by management or sales and programmers are expected to meet the date or get PIP'd.
I had my first programming job around this time, and there wasn't scrum and all that crap. I was a Jr engineer, still in the last semesters of univ. And yet, we were treated like you read in the post: We were handed a feature and asked to do it. First estimate it , then ask the Design guys for UI and finally start coding it.
Now Software dev feels like sweatshops, business people think we are sewing jeans. And Software Developers became code monkeys.
Its quite sad.
Seems like he managed both.
It has to be interpreted through modernity sometimes to account for changes but overall his stuff feels really solid