371–380 of 420 posts
Earlier quoted context omitted.
Well, standup is also terrible. In addition, there's the general agile assumption that developers are capable of consistently producing X hours of work per day. Maybe it's just me, but I'm a bit more burst-y with my work habits than that.
Shouldn’t it average out over 2 weeks?
In addition to the difficulty in making a meaningful estimate, I'm frustrated by how often management really wants to hear a particular answer and won't settle for anything but that answer. It can go like this: 1. Developers size development of X and says it will take roughly 12 months. 2. Management says the rest of the organization is going into system test in 9 months and needs X finished by then. Couldn't there b…
> -- suggest reduced functionality for X Limiting the scope in a reasonable matter should reduce dev time, no? Assuming it's a true reduction in scope and not just lipstick on a pig..
Usually, lightening the ship by throwing functionality overboard in a panic doesn't happen until around half way through a project, but what I was referring to was the sort of impractical proposals that come from non-developers about how to reduce development time.
"Couldn't we remove the ability to customize user icons--everyone in the icon based user view can have the same icon." Okay, why have icons at all if every icon is identical?
"Deadlock, what's that?, do we really have to detect it in the first release?" Hmm...
"Can we leave out distributed shared virtual memory segments?" They weren't included in the original sizing
"Do we have to do persistent client caching?" Well then we will be no better than competing products.
"Does X have to run over both UDP and TCP?" That was originally a requirement. We can go back and examine that in light of other parts of the system depending on X.
Earlier quoted context omitted.
I have experienced Agile being quite successful. Maybe that is an uncommon experience, but it is certainly possible.
Curious if you had success with "generally following the Agile manifesto", or some specific framework like XP, Scrum, Scaled Agile, etc.
For what it is worth, I have also seen classic waterfall be successful. But I have also seen several big-scale disasters with waterfall, and in my experience waterfall carry much larger risk and is much harder to salvage when it goes off track.
Earlier quoted context omitted.
> Can we stop pretending we can forecast the unknown Within reason. Ive worked in orgs where there is no estimate at all, and that bring a different set of problems (unbound projects and no work getting done because of the complete lack of pressure). Now you're totally right: software engineers rarely do the same thing (or even similar things) twice, so estimating is somewhere between "very hard" and "impossible". "S…
I feel as you should be able to provide an estimate even if it something that you have not completely done before. One should spend some time to gauge how much of this new thing is really "new" and what parts should be easy to figure out. Then, try to look at resources about those unknown parts, and that should allow to provide a rough estimate. And when road blocks come up just communicate early, and then if PM/boss…
But downvoting you is just as counterproductive as burning the devil's advocate and you have my upvote. I hope people will get a hold of their emotions.
I've just spent a month doing a script I thought I could do in a weekend. I didn't realize several of the difficulties inherent in the data, I didn't realize I'd have to up my game with regard to techniques in shuffling data and I didn't know I'd run into so many quirks in the programming language.
I didn't know what I didn't know. That's why I guessed wrong.
In everything you haven't done before, you don't know what you don't know - and only a small portion of those things could have been realized by spending some hours researching the work I needed to do. Those didn't pop up on my radar until I had to solve them :(
But that knowledge isn't without value. Knowing that it is doing stuff you haven't done before that is risky (timewise) means you can underscore when you have a high-risk assignment.
Earlier quoted context omitted.
I'm not a nuclear aircraft carrier refueller, so maybe the domain is different in a way I don't understand, but it's ridiculous to need a five year plan to just refuel something, people refuel cars in five minutes everyday. I simply do not accept that it is impossible to refuel in a week or so, assuming it's a couple orders of magnitude more complex than refueling a car. Thats about how your comment sounded.
+1 However, your comment didnt help me understand. It doesnt help because even if i embark on something i have no idea about, even in total ignorance i can _bound the problem_. I dont understand how a professional coder can approach even a problem and have no idea - you have to DO the problem, so what is your approach? Just start coding and somewhere between 5 days and 5 years you stop? Planning meetings dont happen…
The spell for floating an object is Wingardium Leviosa. It usually takes an 11-year old a few days to become proficient at it.
Please give an estimate for a modification of this spell that will make the object lift, complete two vertical circles (720 degrees) and then go back to the starting point.
(Before you ask: yes, we're doing magic. We're combining words in specific ways to create significant effects in the world.)
Earlier quoted context omitted.
+1 However, your comment didnt help me understand. It doesnt help because even if i embark on something i have no idea about, even in total ignorance i can _bound the problem_. I dont understand how a professional coder can approach even a problem and have no idea - you have to DO the problem, so what is your approach? Just start coding and somewhere between 5 days and 5 years you stop? Planning meetings dont happen…
Software development is filled with fractals. To do A, you break it down into A1, A2, and A3. To do A1, you break it down into A1.1 and A1.2. To do A1.1, you break it down into A1.1.1 and A1.1.2. In even a small project, that means that your moment-to-moment work might be something like "do task A4.1.2.3.5.3.2.1.5.4". Not literally, but conceptually, that's what's happening. Every task involves a bunch of other tasks…
Especially this part:
Professionals have found it's often easier to refuse to provide estimates than to fight over high-confidence estimates or educate stakeholders in interpreting probabilistic date ranges. Not estimating saves lots of time, too.
Earlier quoted context omitted.
Im not a coder, so maybe the domain is different in a way i dont understand, but I agree with you 100%. Refueling nuclear aircraft carriers have projections start to finish, a half decade long. There are countless pre and co requisites with interrelated projects, not counting the mundane issues like material and manpower. I simply do not accept it is impossible to project a timeline for software. If someone stops you…
I will say that in sfortware you can estimate but because there are many unknown things it's difficult. Is a bit like "How long it will take to discover the cure for cancer?"
"We have this problem, you see, where cells sometimes start to multiply aggressively instead of doing their job. That's a bug, the customers are complaining. How long will it take to fix it? What do you mean you don't know - not even a ballpark estimate?"
I've been developing software for over 20 years, and I still can't estimate how long something will take me when I've never done it before. This uncertainty needs to become more than just a stick to beat developers about the head and shoulders with. Most of the time the PMs understand this, but there have been many projects where they just don't get it. I have suffered great anxiety from being forced to give estimate…
Most time estimates aren't necessary in the first place and it's aggravating that we need so many of them. Yes it's mostly a stick to beat devs with. But since folks reading this will probably need to make estimates anyway, this tends to be accurate: Estimate it'll take as long as the most recent similar thing you've done (real time, not heads down time). Resist the urge to trim out parts of the previous task that ar…
Earlier quoted context omitted.
I feel as you should be able to provide an estimate even if it something that you have not completely done before. One should spend some time to gauge how much of this new thing is really "new" and what parts should be easy to figure out. Then, try to look at resources about those unknown parts, and that should allow to provide a rough estimate. And when road blocks come up just communicate early, and then if PM/boss…
Im not a coder, so maybe the domain is different in a way i dont understand, but I agree with you 100%. Refueling nuclear aircraft carriers have projections start to finish, a half decade long. There are countless pre and co requisites with interrelated projects, not counting the mundane issues like material and manpower. I simply do not accept it is impossible to project a timeline for software. If someone stops you…
Refuelling a nuclear aircraft carrier may be a complex operation but it's one for which the plan was already developed quite some time ago.
To compare to software development is missing the point. Building a PC, installing Windows and all the apps you need might take half a day if you're experienced, and it'll take half a day each and every time: it's labour and you can't reduce the time taken to zero. That's like refuelling an aircraft carrier: executing a plan.
But software development isn't like manual labour where you execute a pre-determined plan. It's more like researching how to build the aircraft carrier. Once the plan (the software) is built, installing and executing it is trivial and takes very predictable amounts of time, which means software developers are almost always doing "research" even if it doesn't seem that way.
How long did the first nuclear aircraft carrier take to design? Well, literally the first sentence of the Design section of the wiki article for USS Enterprise says:
Enterprise was intended as the first of a class of six carriers, but massive increases in construction costs led to the remaining vessels being cancelled
So I guess ship designers suck at estimating about as much as software developers do.
Earlier quoted context omitted.
Start with the HUGE failure rate in software development. There is no provable reliability and/or costing, nor is there any form of standardization beyond RFCs and "best practices." One might even doubt that it's even possible for there to be standards like you see in capital-E Engineering due to the unique and complex nature of general computing systems. To sum up, software development requires too much trust, way m…
What about Engineering (or, construction, say) being hundreds of years old vs software development only 50? Not arguing with your main point, but curious to hear your thoughts.
Projects usually go wrong, or are "late" (relative to estimates engineers didn't want to give in the first place), when they're being closely controlled by people who are not engineers. The recent article on Berlin's new airport being a case in point, where the politicians tried to double its size after it started being constructed and the entire project collapsed in a heap.
Now imagine that happening all the time, every day. That's the enterprise software world.