clickbait title => will not read
Why Development Teams Struggle to Deliver on Time, on Budget, or at All
131–140 of 239 posts
Re: Why Development Teams Struggle to Deliver on Time, on Budget, or at All
#132Earlier quoted context omitted.
Yet if I ask you how long it takes to buy icecream in Japan, based on your experience grabbing milk in the US, your guess will be "less than half a day". Which is good enough for me.
But then you say go for it and get upset about all the time I spend getting a passport, booking flights, and figuring out how to transport the ice cream back. I’m kidding, of course. It really depends on how well business and development understand each other.
> I’m kidding, of course. It really depends on how well business and development understand each other.
Yup. This is the crux of the whole issue, and it's being completely blown out of proportion. There's always going to be details the estimator (dev) won't know, but the more clear a picture you have in your head, the more confidence you can have in an estimation.
This is directly related to the size of the project too, of course. If it's a 12 month project, a single developer is massively unlikely to have a reasonable understanding of all the potential roadblocks that the project will take. However a 1 day task, with tools you know/etc, you can have a pretty good idea how long it'll take.
There's always some unknowns, but that's literally what an estimate is for - attempting to plan for the unknowns. I can write an add function and I'd bet a lot of money that it won't take more than a day.
Unreasonable management seems to be giving developers PTSD here. As I'm having trouble understanding why the idea of an estimate, by definition exactly what we're doing, somehow doesn't apply to software development.
If you're being pedantic you could say the same about a lot of things. How long to dig a 1foot hole in open ground? Well who knows, there might be a massive rock - but that doesn't mean you can't give an estimate. It's literally what an estimate is for, an approximation based on assumptions and expectations.
Re: Why Development Teams Struggle to Deliver on Time, on Budget, or at All
#133The reason that planning software development is bullshit is that you simply cannot know all the little details because in software development you're always doing something you've never done before (because if you did you could just copy-paste your previous work). To use the 'going to the supermarket for milk' example. I could make a fairly accurate estimate for that because I've gone to the supermarket hundreds of…
Yet if I ask you how long it takes to buy icecream in Japan, based on your experience grabbing milk in the US, your guess will be "less than half a day". Which is good enough for me.
And when he returns with the ice cream I’ll tell you I wanted Hokkaido ice cream.
Re: Why Development Teams Struggle to Deliver on Time, on Budget, or at All
#134Earlier quoted context omitted.
Did you write this yourself? It's very good.
No, it's an age old poem that was passed around on the internet. I happen to have kept a copy of it, but the authorship has been lost i m afraid.
I believe this is a translation from the original Sumerian.
Re: Why Development Teams Struggle to Deliver on Time, on Budget, or at All
#135The reason that planning software development is bullshit is that you simply cannot know all the little details because in software development you're always doing something you've never done before (because if you did you could just copy-paste your previous work). To use the 'going to the supermarket for milk' example. I could make a fairly accurate estimate for that because I've gone to the supermarket hundreds of…
> you simply cannot know all the little details
This is the reason big design up front hasn't been the gold standard in planning. Most modern methodologies acknowledge that there'll be a lot of changing requirements and learning-while-building.
The point is, given this information, you could a) run around like crazy doing all manner of reckless and crazy cowboy programming and putting out fires b) carefully plan a relatively short period of time on a small, achievable, well defined goal (not "build the project"), then making a note of what worked and what didn't, and readjust before you plan the next short period of time
Re: Why Development Teams Struggle to Deliver on Time, on Budget, or at All
#136The reason that planning software development is bullshit is that you simply cannot know all the little details because in software development you're always doing something you've never done before (because if you did you could just copy-paste your previous work). To use the 'going to the supermarket for milk' example. I could make a fairly accurate estimate for that because I've gone to the supermarket hundreds of…
> you simply cannot know all the little details This is the reason big design up front hasn't been the gold standard in planning. Most modern methodologies acknowledge that there'll be a lot of changing requirements and learning-while-building. The point is, given this information, you could a) run around like crazy doing all manner of reckless and crazy cowboy programming and putting out fires b) carefully plan a re…
This is often taken to an unhealthy extreme.
You need to have some fairly specific goal in mind to start doing anything. AKA are we building a PS4 game or a self driving car?
Methodologies like Scrum are all about transitioning a long term objective into short term progress. But, you really do need some fairly well thought out goal.
Further course corrections quickly get very expensive. Sort of like sailing from Virginia to Europe then deciding 1/4 of the way in on France then changing your mind to Spain at the midway point is probably fine. However, changing your mind to Australia is a much bigger deal.
Re: Why Development Teams Struggle to Deliver on Time, on Budget, or at All
#137Earlier quoted context omitted.
> Development time estimation, and every methodology that attempts it (I'm looking at you, Scrum), are little more than desperate attempts by managers to feel in control and relevant. More charitably, they're an opportunity to introduce system 2 slow thinking on the team. There are certainly novel engineering problems that simply won't yield to estimation, but there are also lots of well-solved problems that will. Ma…
> but there are also lots of well-solved problems that will. Certainly when you're writing a double-linked list a third time you can estimate how long will it take you. The problem is that in real life you never solve sufficiently the same well-solved problem. Feature details, matters of integration with other pieces of the system intervene - and in practice those errors introduced by new circumstances are significan…
So you integrate with a few systems, you learn where the gotchas tend to be, you call those out as things you'd like to know more about when making your initial estimates, etc. Today's software dev has probably integrated with more systems than they have written linked lists. We just have a habit of forgetting all the little details.
If you're looking for a formula that lets you estimate once and then move on to the "real work" now that that tedious BS is out of the way, there isn't one. But you can still do something. There's ground between "I can't estimate that in 30 minutes" and "I can't estimate it at all" and it's up to you and your stakeholders to come to terms on how to balance the risks in your estimates (in broad terms: too inaccurate estimates vs too much time wasted estimating requirements that have since changed).
(There's a parallel theme in some other comments: "if it's a well-understood problem why am I not using the existing solution?" Similarly, there's a difference between "well-understood" and "perfectly abstractable and automatable", otherwise almost none of us would be employed these days. :) )
Re: Why Development Teams Struggle to Deliver on Time, on Budget, or at All
#138Earlier quoted context omitted.
But then you say go for it and get upset about all the time I spend getting a passport, booking flights, and figuring out how to transport the ice cream back. I’m kidding, of course. It really depends on how well business and development understand each other.
> I’m kidding, of course. It really depends on how well business and development understand each other. Yup. This is the crux of the whole issue, and it's being completely blown out of proportion. There's always going to be details the estimator (dev) won't know, but the more clear a picture you have in your head, the more confidence you can have in an estimation. This is directly related to the size of the project t…
> Unreasonable management seems to be giving developers PTSD here.
It's inexperience all around. Also, most places have no clear long term track, so people bounce after 2 years rather than growing to understand each other.
Managers are generally free to cut estimates in half, and move to a new role or move to a new organization when things fall apart. They're not trying to be villains, they have a lot of pressure coming from a lot of directions and think that estimates are bogus anyway, thanks to star trek and the occasional miracle that happens. (sometimes things really are much easier than they seem)
Developers are optimistic, wildly underestimate, and feel bad when they miss them. The overreact and start massively overestimating. When they progress to the next stage they take the time to give a good thorough estimate to have it slashed by a manager, who knows they overestimate.
Nobody sticks around long enough to really understand the state the other is in, so you get this vaguely Kafkaesque world that makes everyone a little crazy.
Re: Why Development Teams Struggle to Deliver on Time, on Budget, or at All
#139If you __really__ don't get to set the deadline, is it still reasonable to held accountable for that miss? Even if you give worst case and best case the only one anyone else focuses on it best case. Personally, I prefer the 80/20 rule. That is most of the work will go fair quickly, or at least uneventful. It's the last bit that's always the killer. The devil is in the details, as they say. When asked for an estimate…
I also like the 90/90 rule:
The first 90% of the work takes 90% of the time. The remaining 10% of the work takes the other 90% of the time.
Re: Why Development Teams Struggle to Deliver on Time, on Budget, or at All
#140Earlier quoted context omitted.
But then you say go for it and get upset about all the time I spend getting a passport, booking flights, and figuring out how to transport the ice cream back. I’m kidding, of course. It really depends on how well business and development understand each other.
> I’m kidding, of course. It really depends on how well business and development understand each other. Yup. This is the crux of the whole issue, and it's being completely blown out of proportion. There's always going to be details the estimator (dev) won't know, but the more clear a picture you have in your head, the more confidence you can have in an estimation. This is directly related to the size of the project t…
Estimates in software are effectively experienced guesses. This is in contrast to other industries, such as construction, where planning is done for months to ensure the estimate of time and materials is accurate. If you attempt to treat one as the other, you run into huge problems.
Software isn't like building a bridge; it's like planning to build the bridge.
I'm pretty good at software estimating; I can roughly tell when something will take an hour, 2 hours, 4 hours, a day, a week, or month, 3 months, or 6 months -- in those intervals. It's more difficult and time consuming to get more specific than that.
I've also had a 1 day task blow out to entire week more than a few times. At that point, you have to start questioning the predictive value of estimates.