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.

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.