[java-man]

I think there is a way to give an estimate (have been doing it myself for a decade), even for dependencies that are not known from the start.

(I mean, reasonable dependencies. No one can account for unknown unknowns, but the software engineering field is not an art, more of a skill, we do have well established processes to minimize the surprises).

Is this something that HN audience is interested in?

[LyndsySimon]

> I think there is a way to give an estimate (have been doing it myself for a decade), even for dependencies that are not known from the start.

I agree with this. The problem is that estimates vary, and that management teams often don't understand the way they vary. It's one thing if your estimates are precise and are generally accurate within 20%; it's another if your estimate is "it will likely take between six months and three years", and a third of the time the actual required time falls outside even that range.

... and yes, there are many projects for which such a large estimate wouldn't be unreasonable; nor would it be unreasonable for there to be unexpected breakthrough or challenges that significantly impact the timeline.

> Is this something that HN audience is interested in?

I can't speak for the community, but I think the only way you can know the answer to this question is to post it :)

[justinpombrio]

> Is this something that HN audience is interested in?

Are you teasing? Yes, we want to know! Though frankly I'm incredulous.

[java-man]

No, I wasn't teasing, but I wasn't sure that people would find it interesting (at least, this was my expectation based on experience).

I tried to describe the process somewhere in this thread.

[justinpombrio]

It just sounded like teasing because it's a famously hard problem.

But having read your proposal, I actually totally believe that that could result in accurate time estimates. To summarize, remove the unknowns by planning things out beforehand, then count how many hundreds of small pieces you'll need! That sounds plausible as long as what you're doing is straightforward. (E.g., no crazy database optimizations needed to make things fast enough, no crazy ML techniques needed to make things accurate enough, no crazy algorithms needed to solve NP-hard problems, etc.)

[java-man]

You are right: non-trivial things are hard to estimate - as tasks may not even have an upper time limit.

But in the majority of software development projects the tasks are trivial, and it is possible to enumerate all the little details and their dependencies.

I was thinking of writing a tool to support the process instead of using excel, but unfortunately the dev has stalled due to lack of time on my part.

https://github.com/andy-goryachev/ReqTraq

[rhizome]

Fred Brooks would be incredulous.

[Bjartr]

I'd love to hear what you have to say in the topic.

[java-man]

Sorry, tried to answer and apparently I was "posting too fast".

One may start with enumerating the features that needs development (a.k.a. "user stories"). Also enumerate external dependencies, team overhead (more people working together means overhead is greater). For each feature enumerated in step 1, try listing as much detail as possible, also listing open issues and unknowns.

For example, list all the UI elements under development. List all individual functions / use cases that need distinct functionality (classes, functions) to be developed. List all the test cases. List external APIs, enumerate different ways the said API can be used. Enumerate failures and possible recovery actions.

I'll give you an example: a login dialog for an application. This starts as a two page requirements document, which balloons to around 120 items using this method.

This alone should give a good idea at the start of the project. Keep doing it (enhancing the level or detail), while keeping the ratio of initial estimate vs real value - that will help in estimating the remaining portion of the work.

The problem (the way I see it) is that we don't really have the tools to do this kind of tracking and analysis. Jira and similar systems don't even come close.

Here is an attempt to apply the methodology using Excel:

https://github.com/andy-goryachev/PasswordSafe/blob/master/F...

[silveroriole]

This is roughly how I was taught to estimate. It is accurate but takes time and everybody hates the result. Management halved my estimates without telling me, made fun of my mentor’s estimates, complained about needing to know everything upfront (not very agile eh!), etc. I think you are right and estimating is more of a solved problem than we think, some people just don’t want to admit it!

[java-man]

Oh yes, my experience as well. I just hope these companies do not manufacture aircraft or nuclear power plant software.

[stronglikedan]

And then the customer decides that they don't want to move forward with the project because it's too expensive. Oh, and they don't want to pay you for all the time you spent estimating because no one pays for estimates up front anyway.

[java-man]

Yep. 30% upfront.

But actually, once you show the customer what's involved, and give them a realistic estimate, it might reduce the chances of cancellation. The discussion might be steered towards what they really want, or prioritization of deliverables.

A mockup (and multiple iterations thereof) might be necessary as well.

[DougBTX]

https://www.microsoftpressstore.com/store/software-requireme...

That book is from this perspective, that you can work out what needs to be done for a project before actually doing it.