Dear Agile, I’m Tired of Pretending (2018) • Hacker News Board

Re: Dear Agile, I’m Tired of Pretending (2018)

#391

Post by thwarted » Tue, Jul 02, 2019, 1:49 PM UTC

rramadass wrote: post #360

kryogen1c wrote: post #303

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…

>i can _bound the problem_ This is the nub of the problem when it comes to software. I understand your skepticism but software development is really very different from other activities. It is "mind-stuff" (and thus quite unstructured) which needs to be expressed in very precise language to solve an [almost always ill-defined/constantly redefined] problem. The inherent complexity involved is huge due to the number of…

The top answer to "Why are software development task estimations regularly off by a factor of 2-3?" on quora is a great analogy.

https://www.quora.com/Why-are-software-development-task-esti...

Re: Dear Agile, I’m Tired of Pretending (2018)

#392

Post by gilbetron » Tue, Jul 02, 2019, 2:10 PM UTC

rufflez wrote: post #386

snarfy wrote: post #270

Earlier quoted context omitted.

You go to the mechanic and tell them your car won't start - nothing happens when you turn the key. You ask them how long it's going to take to fix and how much it will cost. They don't assume it's the starter and tell you it will be $400 for parts and labor. They tell you it will be $150 diagnostic fee and the diagnostic will take two hours. Then they call you and tell you the cost to fix and time it will take. For w…

Often, you think it is a car, and then when you start to work, you realize it is actually an octopus

I love this comment!

The analogy I've been using lately is that it's like estimating how long it will take to pack your kitchen when you are moving, except sometimes you open a cupboard door and there's another kitchen inside.

Re: Dear Agile, I’m Tired of Pretending (2018)

#393

Post by goalieca » Tue, Jul 02, 2019, 2:13 PM UTC

madeofpalk wrote: post #219

Bartweiss wrote: post #123

Earlier quoted context omitted.

> One side is signed up for incremental delivery, and one side is set up for a fixed scope and deadline and the result is misery. This is a brilliant summary, thank you. The best 'agile' experiences I've had are situations where the 'clients' are directly involved, often within the same organization. Instead of a hard scope or deadline, there's just a shared interest in producing a valuable product efficiently, and t…

> waterfall contracts, developed by an internal simulation of agile. We call this wagile

I just call it agile. It’s the common form.

Re: Dear Agile, I’m Tired of Pretending (2018)

#394

Post by java-man » Tue, Jul 02, 2019, 2:22 PM UTC

justinpombrio wrote: post #370

java-man wrote: post #319

Earlier quoted context omitted.

No, I wasn't teasing, but I wasn't sure that people would find it interesting (at least, this was my expectation based on experience). I tried to describe the process somewhere in this thread.

It just sounded like teasing because it's a famously hard problem. But having read your proposal, I actually totally believe that that could result in accurate time estimates. To summarize, remove the unknowns by planning things out beforehand, then count how many hundreds of small pieces you'll need! That sounds plausible as long as what you're doing is straightforward. (E.g., no crazy database optimizations needed…

You are right: non-trivial things are hard to estimate - as tasks may not even have an upper time limit.

But in the majority of software development projects the tasks are trivial, and it is possible to enumerate all the little details and their dependencies.

I was thinking of writing a tool to support the process instead of using excel, but unfortunately the dev has stalled due to lack of time on my part.

https://github.com/andy-goryachev/ReqTraq

Re: Dear Agile, I’m Tired of Pretending (2018)

#395

Post by GFischer » Tue, Jul 02, 2019, 2:50 PM UTC

snarfy wrote: post #270

bougiefever wrote: post #88

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…

You go to the mechanic and tell them your car won't start - nothing happens when you turn the key. You ask them how long it's going to take to fix and how much it will cost. They don't assume it's the starter and tell you it will be $400 for parts and labor. They tell you it will be $150 diagnostic fee and the diagnostic will take two hours. Then they call you and tell you the cost to fix and time it will take. For w…

For whatever reason, software engineers don't have the luxury of doing a diagnostic.

That´s not necessarily true. I´ve worked with very good, serious consultancies, and I´ve seen a quote for thousands of dollars for exploratory work to give an estimate. Of course that was for a million dollar project - smaller projects might not have this opportunity.

Other companies had some interesting approaches where they gave order-of-magnitude estimates and then refined the estimate iteratively.

Re: Dear Agile, I’m Tired of Pretending (2018)

#396

Post by rch » Tue, Jul 02, 2019, 3:33 PM UTC

ScottFree wrote: post #284

rch wrote: post #274

Earlier quoted context omitted.

Because if they launch on the original schedule with Partner X they get Massive Benefit Y that could make or break the product. For example.

This. Most developers either don't want to or can't understand that there are real and valid reasons for wanting a predictable software production schedule. That said, I've only ever seen one software project consistently meet production deadlines. Is there benefit to committing to the original schedule with Partner X if there's no way you can deliver on schedule? Or is it one of those things where Partner X has comm…

In the example I'm thinking of the partner wasn't really bothered that the schedule slipped, but the ideal marketing window came and went before the product officially launched, which certainly affected sales. They were really excited that all the planned features made it to market though.

I'd say that some aspects of the capability maturity model make sense, even for engineering groups that practice agile day-to-day.

Re: Dear Agile, I’m Tired of Pretending (2018)

#397

Post by elindbe2 » Tue, Jul 02, 2019, 3:42 PM UTC

bb88 wrote: post #262

xwdv wrote: post #199

Earlier quoted context omitted.

No. Even bad estimates are better than no estimates. If you are having meltdowns your reputation is being tied too closely to your ability to give estimates. You must never turn estimates into a promise, always remind people they are estimates. Want to give fast estimates? Here’s how: 1) first determine the scale of the task? Is it a year, month, week or day kind of task? 2) Then, it’s just 3 of those units. The smal…

> Even bad estimates are better than no estimates. No estimate is clearly better. Here's a common story I've seen across multiple companies. 1. Marketing management asks Engineering management how long it takes to do feature X so they know when to launch the online ad campaign. 2. Engineering management then asks potentially good coder how long it will take. Coder replies with a time and "it's just an estimate." 3. E…

It's even worse in my organization. Funding is based on projects so the amount of funding you receive is based on exactly how long your estimate is (if they choose to fund your project). Often projects are estimated based on "here's how much money they are willing to spend, so we'll just figure out the number of man hours that amounts to and give that as an estimate."

Re: Dear Agile, I’m Tired of Pretending (2018)

#398

Post by omikun » Tue, Jul 02, 2019, 4:24 PM UTC

matthewhartmans wrote: post #162

bougiefever wrote: post #88

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…

I think this is where a 'spike' solves your problem. By creating a spike, you can do some initial investigation into how the code is written, what's involved, how long it will take, etc. Once you have completed your spike, you can come back to the original piece of work and give a better estimate based on your findings.

Sure, that works for adding something without a lot of connections. But if you are tasked to add a feature that has many hooks into a complex system (plus additional unforseen hooks that you won't realize is needed until you implement it), it's basically a stab in the dark. You can guess a time, then triple it.

Re: Dear Agile, I’m Tired of Pretending (2018)

#399

Post by giglamesh » Tue, Jul 02, 2019, 4:26 PM UTC

peterwwillis wrote: post #114

> let’s stop pretending Agile was some sort of cure all But we won't. That's why snake oil salesmen were so effective: we want to believe in the cure-all. No matter how often you chastise, people'll keep buying it, because they're aspirational. They want there to be greener grass on the other side, and they're willing to try anything to find it. The business doesn't actually care about Agile at all. It just has heard…

People complain endlessly about snake oil, but honestly, have you ever heard a creaky snake?

Re: Dear Agile, I’m Tired of Pretending (2018)

#400

Post by ScottFree » Tue, Jul 02, 2019, 4:39 PM UTC

rch wrote: post #396

ScottFree wrote: post #284

Earlier quoted context omitted.

This. Most developers either don't want to or can't understand that there are real and valid reasons for wanting a predictable software production schedule. That said, I've only ever seen one software project consistently meet production deadlines. Is there benefit to committing to the original schedule with Partner X if there's no way you can deliver on schedule? Or is it one of those things where Partner X has comm…

In the example I'm thinking of the partner wasn't really bothered that the schedule slipped, but the ideal marketing window came and went before the product officially launched, which certainly affected sales. They were really excited that all the planned features made it to market though. I'd say that some aspects of the capability maturity model make sense, even for engineering groups that practice agile day-to-day…

> the ideal marketing window came and went before the product officially launched, which certainly affected sales.

Definitely. I used to see that all the time in the games industry. Getting the right launch window is critical because most of a game's sales happen in the first few days of launch. And yet, games are famous for shipping months, even years late. They usually seem to make it work. I guess you'd be particularly hosed if you couldn't afford the burn rate for the extra X months it would take to get to a decent launch window.