Hacker News Reader

Comment by davidivadavid | Hacker News Reader

That begs for supporting evidence. I doubt most software is open-ended research.

Frederick Brooks' "Mythical Man-Month" book is the classic answer. For my own evidence I base it on 50 years experience. I just wrote a piece of code that I had all working, but then I discovered a new method (requiring rewriting it all) that greatly improved it in every respect. So was I 90% done before that? Coding is just a very non-linear and never-ending process.

You were 100% done. And then you discovered an opportunity for new work.

I know many developers enjoy the art of software development and want to continually improve it, but that isn’t always the task you are being paid to do.

This exactly.

There are many ways to remodel a bathroom. Some more optimal than others.

Now imagine your plumber tells you he discovered a better layout for the plumbing just after finishing his work, then he enthusiastically asks if he could tear everything out and start over (and pay him for it).

If it's not you copy & modify a snippet from StackOverflow, or call a library.

It's not strictly correct that most software is open-ended research. Most economically valuable software is open-ended research, because otherwise a solution already exists and you don't need to pay a software developer to write it.

Software is a somewhat unique industry in having zero cost of replication. The only other industry like this is creative & artistic pursuits (writing, artwork, music, film, etc.). That industry is also notoriously difficult to estimate and tends to be an area where the the greatest works of art are done when they're done. (How long have people been waiting for George R. R. Martin to finish A Song of Ice and Fire?)

> I doubt most software is open-ended research.

No, just all software that provides any sort of tangible benefit to anybody. I’m sure you could estimate fairly accurately how long it would take to implement quicksort - but nobody’s going to ask you that.

An argument is that it is open-ended research by definition. Else we would just reuse something that already exists.

Some devs do work that could be replaced by software, but management doesn't know and the dev likes a paycheck.

That same argument can be applied to home renovations then. The carpenter has build many cabinets before, but perhaps not YOUR exact cabinet. So then no estimate is expected in that case?

The carpenter rarely discovers a few days in that the screwdriver they have to use on this project only works every other week. Or that literally every measurement on every component is off by 20% because "that's how it's done" with whatever garbage you stuck them with.

Vendors and even open-source libraries are often liars or just missing what seems like it ought to be obvious functionality. Sometimes tools are just broken. I once was assigned a Java AWS Lambda project, which, great, supported, right, says so right on the website? Except half the CLI tool functionality just didn't work, at the time, for Java projects, and I mean the official tools. It was alpha-tier supported at best. Usable, sorta, kinda, but you're gonna lose some time un-fucking the situation, and the whole thing would be slower to develop than it needed to be. You'd not know that unless you went and did a focused search on their issue tracker(s), which isn't really reasonable to do for all the stuff you might use in a typical project (some of which you might not even know you need until you've started work). "Great, so now you know that for estimating next time, if you get assigned a task exactly like that one" well, no, not really, because that was like four years ago and the situation's probably totally different now (maybe better, maybe worse, who knows?)

That's why I think giving 4-8 weeks of development time with some basic t-shirt sizing or pointing for tasks and just seeing how it's going is better, before estimating. I think if you can't afford that, before getting the estimate, you can't afford a half-decent estimate at all and just need to deal with the fact you're going to get a terrible estimate with an absolutely huge range ("six to eighteen months"). Which, fine to ask for that up front then refine it after some dev time! It just needs to be clear and expected that those early estimates are going to have some wild variance—but they can definitely tell you "is this more a 1-year project, or more a 5-year project?" which does have some real value.

Commercial software isn't generally an artisanal crafting process. If you're a programmer who solves variations of a problem, analogous to a carpenter building varieties of cabinets, then you have parameterized tools. When the client asks for maple instead of oak, you don't pull out a maple board and start sawing. You'd just go to your cabinet_template.yaml file and change material=oak to material=maple. You don't have to estimate how long it will take to build the cabinet because it's already done, you just ran build_cabinet.sh.

Reply on news.ycombinator.com