Software estimates are out of fashion.

In spite of being out of fashion, many of us are asked (often for very good business reasons) to provide them.

Right or wrong, there are situations where you should not provide an estimate. I learned these the hard way, here are the ones I know:

1. R&D work
2. Highly complicated things you've never done before (even if you're 99% sure you can do them).
3. Things you can't break down into small pieces
4. System integrations where you don't control the flow of development (A vendor needs you to attend 10 meetings and then they want to certify your 1 line of code.)
5. System integrations where the system is still being developed or tested (Here's a great question I've learned to ask over the years: 'How many other people have used this API before?').
6. Collaborative Development - two teams working together, especially for the first time.
7. Co-development - sometimes this manifests itself as #5, but it can be other things, like working with an outside vendor in a novel way on the same codebase.

Pretty much everything else is feature work and you can estimate that. It might be a little scary or intimidating, but you can.

I don't mean to suggest there is anything wrong with the things the 7 categories above. Those things can be very important work that needs to get done, and those things might be very fun work (if you can get it).

But, fun as it may be, you really shouldn't estimate it.

Here's what to do with those 7 items above - don't estimate them. Break them out into separate subsystems or budgets or categories. Whatever you use to segregate work, put them in their own place and create visibility to how the work is progressing.

Some clients/bosses won't like it, but they also won't like budget/timeline overruns with no explanation either.

Make it clear up front. Use your estimate (or non-estimate in this case) to communicate and set expectations. Then use it to reset them later if you need to.

Many bosses/clients will appreciate the effort you put into managing the simpler parts. And they'll appreciate that you understand how to separate more complex things from the typical or mundane.