I liked this idea when it came out, and there was some software that implemented it. Mr Schedule by Andrew Pietschy added outliner functionality to Joel's idea, so you could see how much time a group of subtasks would take (and if you should maybe drop that feature group to make your deadline). It had some keyboard driven shortcuts that made it faster to move around in than Excel, while making things simpler.

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.

Was wondering how StockOverflow guy was doing these days and it turns out he sold the company for $2B in 2021. What's the saying? Time in the market vs timing the market. Good for him but imagine being one of the investors.

4) Only the programmer who is going to write the code can schedule it.

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.

For many of us, the way we manage software projects has changed has changed so much since the days when Joel wrote this.

It was a different age, with different products. I’m sure there are still products built the old ways, but Joel was writing before SaaS and CI/CD and endless roadmaps.

"When you have to pick fine grained tasks, you are forcing yourself to actually figure out what steps you are going to have to take."

That process isn't free. For many features, it's the largest share of the work.

> Netscape has seen its browser share go from about 80% to about 20% during this time, all the while it could do nothing to address competitive concerns, because their key software product was disassembled in 1000 pieces on the floor and was in no shape to drive anywhere. That single bad decision, more than anything else, was the nuclear bomb Netscape blew itself up with.

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.

It is always interesting to me how Joel’s writing is so relevant despite how long ago it’s been written.

It has to be interpreted through modernity sometimes to account for changes but overall his stuff feels really solid

Don Reinertsen did some nice work on what he calls lean 2.0. Part of that is basically doing cost estimations for work. Cost estimations basically just boil down to hours times cost per hour. The nice thing of thinking in dollars instead of hours is that it suddenly becomes a money game. Now there is a stake. Because companies are usually budget constrained and while they can pretend there are more than 24 hours in day, pretending there are more dollars in the bank is a lot harder. The tradeoffs get a lot more real.

One of the points he makes that a bad estimate is better than no estimate. If you have no estimates, you literally can't plan. Even if you are going to be off by 3x it's better than not knowing. A lot of the companies have no clue about the cost of what they are doing. So, he fixes that by making them predict cost of their plans. Which in turn forces them to do time estimates. Like Joel says, breaking things down helps making better estimates.

Another point he makes is that different people can come up with wildly different cost predictions for the same thing. That's still a lot better than not having any cost at all. Whenever you get wild divergence in cost estimates, that signals that there's no collective understanding of what a team is doing. That's a problem that needs fixing or somebody needs a reality check with their expectations (e.g. managers). If they are low balling an expensive thing, they are going to look pretty bad when that doesn't happen repeatedly.

And then he introduces a concept called "cost of delay" which is a simple potential revenue based mechanism for calculating what it would cost if feature X ships 3 months late. Now you get money based prioritization. We make more money if we do X before Y.

And a final point he makes is that empowering people to come up with money saving measures can actually be hugely beneficial. Some things get cheaper if you rethink a design, maybe re-implement some thing, etc. Instead of making people beg for permission to do that, it's much more cost effective to let people figure things out. Up to a certain dollar amount. That amount can go up or down as people gain experience. But the point is that rewarding people for things that are profitable is a very sane thing to do for companies. And usually the experts have the best understanding of where the potential gains are.

All very simple ideas conceptually. But the thing is, many software shops have no clue about any of this. They don't understand their own cost. They don't understand the dollar impact of choices they make; including important things like prioritization.

I don't actually practice any of this. But it's an intriguing way to look at estimations. Well worth checking out his work.

As always, the only way anybody has ever thought of to "plan" software is:

    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.

I really miss Joel writings. His wit was unmatchable

I miss his writing, I haven't seen a post by him in a while. His blog and Coding Horror are what I used to read all the time in my undergrad.

I actually did this (around 2006) after reading this article by Joel and I was skeptical but I used excel and wrote down all the tasks that needed to be done and kept breaking it down till each task was in hours.

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.

The article mentions milestones twice, and assumes their existence. But the scheduling methodology described has nothing to say about where these come from or how to think about them. So it’s missing something that makes it at least a little less simple.