4 ms·

> Instead, figure out which tasks have the highest uncertainty – those tasks are basically going to dominate the mean time to completion. From the technical si

> Instead, figure out which tasks have the highest uncertainty – those tasks are basically going to dominate the mean time to completion. From the technical side of things, uncertainty can mean a few things here: (A) I've never done this kind of task (or I don't remember or didn't write down how long this task took in the past) (B) I don't know how to leverage my historic experience (e.g., implementing an XYZWidget in React and implementing the same widget in Vue or Elm for some reason take different amounts of time) Considering (A)... Rarely does a seasoned developer in the typical business situation encounter technical tasks that are fundamentally different than what has been encountered before. Even your bleeding-edge business idea using modern JS' + GraphQL' is still going to be built from the same fundamental pieces as your 1999 CRUD app using SOAP and the estimates are going to be the same. If you disagree with this you are in the (B) camp or you haven't done the work to track your estimates over time and see how ridiculously accurate estimates can be for an experienced practitioner. Even "soft tasks" like "design the widget" are estimable/repeatable. This whole you-can't-estimate-software accuracy position is entirely a position of inexperience. And of course all bets are off there. You are talking about estimating learning in this case, not doing. And the bets are especially off if you aren't modeling that these are two different activities: learning and doing.

afarrell 8y ago
> is entirely a position of inexperience There are a lot of inexperienced software engineers and very little good guidance written for them. What is a new CS grad to do when asked for an estimate? How can a new grad learn to produce accurate estimates within 3 months?
- wellpast 8y ago
  A problem with our industry in this regard is that we don't understand the difference between learning and doing. A new grad entering industry is going to be doing a lot more learning than doing -- or rather learning while doing. I know from experience that explicit doing is highly predictable/estimate-able for the experienced software practitioner. I have a suspicion that the learning side would be predictable, too, if our industry could do a better job of articulating what the practitioner skill set actually is -> then a pedagogy could develop and it could be said that learning X-Y-Z takes on average this long for a set of students. Etc. But we as an industry do not seem to be near this level of clarity -- in large part because we don't even have the vocabulary to frame it this way... in terms of learning vs doing... Now what this means for the new CS grad is not the best story. You'll rather have to play the chaotic game a little bit, which includes a mess of things like doubling estimates and working weekends or what-have-you depending on the work culture you find yourself within. That ^^ in the short term. In the long term what you should do is practice on your own: 1) ALWAYS privately plan and estimate your tasks to the best of your ability--on your own, you may not get benefit by exposing your "practice" to the higher-ups 1a) hint: your tasks should be as scoped/small as you can make them and they will look pretty simple, like this: "design widget X", "design API interface", "implement API interface", "test API interface", "implement widget Y", "learn how framework X lifecycle works" (yes! even learning tasks can be estimated!), and so on. The key is that you try to keep them under a day and ideally even smaller on the order of hours. 2) RECORD the time it takes and compare to your estimates. --> LEARN from this. 3) REPEAT If you do this conscientiously you will find that your estimates improve dramatically over time and you'll be able to out-estimate your peers to their own wild confusion. This skill set will pay off in your ability to deliver AND have weekends and hours with your family. Because you will be able to "see time" and protect yourself. You'll have protection and ammo even in the worst pressure-cooker environments because you will be able to say "No" with confidence. Or rather you will learn how to say "Yes" and what to say "Yes" to. (Ie. you will get really good at priority negotiation etc.) And you'll cultivate delivery trust with superiors and everyone will be happy. The main reason you get these claims that "business just doesn't understand software" and "they put too much pressure on us" is because "business" side doesn't trust us. Once you get good at estimates and delivering on them, that trust is restored and everyone can be made happy. BUT -- and here's the rub -- it takes time and conscientious effort and variety of experience to reach this level of confidence. My advice: Ignore all the philistines who say it can't be done....because they'll just try to talk you out of the effort that they weren't or aren't willing to do themself.
kansface 8y ago
> This whole you-can't-estimate-software accuracy position is entirely a position of inexperience. There are other sources of uncertainty. NASA is probably the only organization that fully specifies product requirements before building stuff - often, even the customer doesn't know. Some problem domains preclude you from knowing in advance! When building the thing, complete understanding of the existing code, frameworks, libraries, and infrastructure is not possible. All of these abstractions eventually leak and break down at scale. Every one of these parts is also continually changing! Even if you could solve all of those problems, you'd still have to deal with people problems - incentives never align, budgets change, and alliances shift. I don't have a formal proof, but I'm strongly suspicious that the only actual way to know how long something takes to build is to actually build it, which of course, may be impossible.
caseymarquis 8y ago
If the task is to reverse engineer an undocumented binary communication protocol to replace a poorly implemented proprietary file server, building the UI isn't the portion with high levels of uncertainty. I think the advice was good.
- wellpast 8y ago
  With the context you've provided here, this is still an estimate-able task. The steps to do this task are enumerable and would be similar across similar tasks. I believe that the conclusion "software estimation can't be reliably done" comes from a standpoint that claims tasks like these ("reverse engineer X-Y-Z...") are somehow completely novel each time we encounter them. In my experience, they are not... even "soft tasks" like "design a Thing" and tasks with unknown details like "reverse engineer X-Y-Z..." -- when you do them more than once -- will be seen for the predictable beasts that they are. But only if you approach them with the attitude that they aren't these novel beasts. That almost all of the work of the working practitioner is NOT like that of the researcher on the bleeding edge of some novel discovery.

afarrell 8y ago

> is entirely a position of inexperience There are a lot of inexperienced software engineers and very little good guidance written for them. What is a new CS grad to do when asked for an estimate? How can a new grad learn to produce accurate estimates within 3 months?

wellpast 8y ago
A problem with our industry in this regard is that we don't understand the difference between learning and doing. A new grad entering industry is going to be doing a lot more learning than doing -- or rather learning while doing. I know from experience that explicit doing is highly predictable/estimate-able for the experienced software practitioner. I have a suspicion that the learning side would be predictable, too, if our industry could do a better job of articulating what the practitioner skill set actually is -> then a pedagogy could develop and it could be said that learning X-Y-Z takes on average this long for a set of students. Etc. But we as an industry do not seem to be near this level of clarity -- in large part because we don't even have the vocabulary to frame it this way... in terms of learning vs doing... Now what this means for the new CS grad is not the best story. You'll rather have to play the chaotic game a little bit, which includes a mess of things like doubling estimates and working weekends or what-have-you depending on the work culture you find yourself within. That ^^ in the short term. In the long term what you should do is practice on your own: 1) ALWAYS privately plan and estimate your tasks to the best of your ability--on your own, you may not get benefit by exposing your "practice" to the higher-ups 1a) hint: your tasks should be as scoped/small as you can make them and they will look pretty simple, like this: "design widget X", "design API interface", "implement API interface", "test API interface", "implement widget Y", "learn how framework X lifecycle works" (yes! even learning tasks can be estimated!), and so on. The key is that you try to keep them under a day and ideally even smaller on the order of hours. 2) RECORD the time it takes and compare to your estimates. --> LEARN from this. 3) REPEAT If you do this conscientiously you will find that your estimates improve dramatically over time and you'll be able to out-estimate your peers to their own wild confusion. This skill set will pay off in your ability to deliver AND have weekends and hours with your family. Because you will be able to "see time" and protect yourself. You'll have protection and ammo even in the worst pressure-cooker environments because you will be able to say "No" with confidence. Or rather you will learn how to say "Yes" and what to say "Yes" to. (Ie. you will get really good at priority negotiation etc.) And you'll cultivate delivery trust with superiors and everyone will be happy. The main reason you get these claims that "business just doesn't understand software" and "they put too much pressure on us" is because "business" side doesn't trust us. Once you get good at estimates and delivering on them, that trust is restored and everyone can be made happy. BUT -- and here's the rub -- it takes time and conscientious effort and variety of experience to reach this level of confidence. My advice: Ignore all the philistines who say it can't be done....because they'll just try to talk you out of the effort that they weren't or aren't willing to do themself.

kansface 8y ago

> This whole you-can't-estimate-software accuracy position is entirely a position of inexperience. There are other sources of uncertainty. NASA is probably the only organization that fully specifies product requirements before building stuff - often, even the customer doesn't know. Some problem domains preclude you from knowing in advance! When building the thing, complete understanding of the existing code, frameworks, libraries, and infrastructure is not possible. All of these abstractions eventually leak and break down at scale. Every one of these parts is also continually changing! Even if you could solve all of those problems, you'd still have to deal with people problems - incentives never align, budgets change, and alliances shift. I don't have a formal proof, but I'm strongly suspicious that the only actual way to know how long something takes to build is to actually build it, which of course, may be impossible.

caseymarquis 8y ago

If the task is to reverse engineer an undocumented binary communication protocol to replace a poorly implemented proprietary file server, building the UI isn't the portion with high levels of uncertainty. I think the advice was good.

wellpast 8y ago
With the context you've provided here, this is still an estimate-able task. The steps to do this task are enumerable and would be similar across similar tasks. I believe that the conclusion "software estimation can't be reliably done" comes from a standpoint that claims tasks like these ("reverse engineer X-Y-Z...") are somehow completely novel each time we encounter them. In my experience, they are not... even "soft tasks" like "design a Thing" and tasks with unknown details like "reverse engineer X-Y-Z..." -- when you do them more than once -- will be seen for the predictable beasts that they are. But only if you approach them with the attitude that they aren't these novel beasts. That almost all of the work of the working practitioner is NOT like that of the researcher on the bleeding edge of some novel discovery.