4 ms·

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

hgsgm 4y ago
Some devs do work that could be replaced by software, but management doesn't know and the dev likes a paycheck.
yibg 4y ago
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?
- yamtaddle 4y ago
  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.
- bluesnowmonkey 4y ago
  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.

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

yibg 4y ago

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?

yamtaddle 4y ago
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.
bluesnowmonkey 4y ago
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.