Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

medium.com

Post reply on HN
Print view View original

161–170 of 420 posts

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

#161

Post by curtis »

ryanmarsh wrote: post #120
curtis wrote: post #67

Any software development methodology or process is going to come up short if it ignores the fundamental nature of software development, which is: We do not know what we're doing until we do. Any process or methodology that tries to extract promises out of the software development organization about things that are still in the we do not know what we're doing phase is going to result in disappointment at best and seri…

We do not know what we're doing until we do Ironic that so many Agile coaches like to bandy about Dave Snowden's Cynefin and then act entirely opposite of what it recommends.

From https://en.wikipedia.org/wiki/Cynefin_framework:

> The Cynefin framework is a conceptual framework used to aid decision-making.

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

#162

Post by matthewhartmans »

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.

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

#163

Post by geezerjay »

ALittleLight wrote: post #96
geezerjay wrote: post #14

Earlier quoted context omitted.

What's stupid in wanting to get an idea of how much a project costs in order to decide if it's a good idea to pursue, let alonr allocate resources?

"How long will X take?" "I don't know, I've never done X before." "Yeah, yeah. It doesn't have to be perfect analysis, just a rough idea for scheduling. Not written in stone, ha ha." "Uh, a week?" "Okay, great, so if I say 8 days you should have it done by then?" "Yeah, I hope so." "Great, thanks." Day 3: actually doing X requires unforeseen Y and Z which will each take a month. "We need to add Y and Z to the schedul…

> "How long will X take?" > > "I don't know, I've never done X before."

I fail to see how your example makes any case on how estimating how many resources a project needs is stupid.

At most your example argues that asking inexperienced and clueless devs to estimate stuff they know nothing about produces highly unreliable information.

The main difference between hacking away at a code base and software engineering is identical to the difference between construction workers and civil engineering. Sure, estimating is hard. Yet of you want reliable estimates you need to check with experienced professionals.

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

#165

Post by eropple »

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.

In the perfectly spherical Agile world, yes.

In practice, for anything that's new, your project devolves into a set of spikes for development because your time-boxed investigation leaves unknown unknowns everywhere. Which is fine in that perfectly spherical Agile world, but it makes less-than-perfectly-spherical stakeholders very upset that they are not getting to use the Agile stick to beat over their developers' heads, as they have been trained to do.

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

#166

Post by tetha »

I'm currently experiencing this, and especially the whole delivery vs discovery, knows vs unknowns and their impacts on estimations. It's quite interesting, especially how differently you have to handle delivery vs discovery projects.

Basically, my team consists of some devops engineers mostly working on maintaining and extending the config management, and some other technical consultants who deliver and execute projects, ideally fully standardized.

For the standard delivery projects, it's extremely valuable to hammer the scope down into a precisely known constant and track the time spent to implement specific parts, as well as the delays incurred for different reasons. This allows for a strong, deliberate optimization of execution time with a measurable, predictable business impact as well as a reliable estimation of these tasks.

Discovery projects on the other hand? Yeah. We're pretty good at giving a lower bound for the time necessary by tracking similar tasks in a job. Extending a database entity is going to take a roughly similar time each time. Packaging, downloading and extracting binaries isn't going to differ that much in time from the last 3 times we did that. If you can identify a bunch of similar tasks you've done some time ago already, you can give a lower bound - "The tasks we consider familiar will take about 2 weeks".

But after that? Who knows. At that point we're rather estimating by asking: When do you stop feeling silly about it? Do you need a year to do this? A month? Two weeks? A week? A day? So usually we hand our project managers something like "This will take 2 weeks we know, plus 3ish weeks we don't know".

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

#167

Post by rhacker »

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 know that kind of environment too. Usually some department head is a YES person, saying the delivery can be done in some timeframe X. Then timeframe X is told to the dev team and the dev team says X + 50 days. Then the dept. head goes back to the sales team and by that time it's too late. Then the entire organization pushes down on the dev team with fury. The product is of course released in X + 75. (because you always need to double or triple the dev team estimate)

Those environments are toxic and the sign of toxicity is that the estimation process is not up for discussion (AKA the dept head keeps doing it again and again and no heads roll)

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

#168

Post by eeZah7Ux »

kjsbfkjbf wrote: post #58
xfitm3 wrote: post #53

Earlier quoted context omitted.

I was interested in comp sci precisely because I didn't have to talk to people, an area where every interaction is a performance. I want to be alone - what's so wrong with that?

There is nothing wrong with that, but careers under capitalism are about _signaling value_. I hope you find a place (or have found a place) where you're appreciated. :)

Please keep the "value signalling" BS out of HN.

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

#169

Post by F_J_H »

LyndsySimon wrote: post #138
F_J_H wrote: post #44

Earlier quoted context omitted.

I had not heard of "emergent architecture" until you implied you hated it, and so I thought I would Google it. I have no idea what emergent architecture is in the agile context, but the idea of emergence is fascinating to me, and has been ever since I read "Emergence: The Connected Lives of Ants, Brains, Cities, and Software" by Steven Johnson. We see the idea of emergent design everywhere in nature and society. I'm…

Thank you for that book recommendation - I just bought it and am looking forward to reading it :) I also had not heard the term "emergent architecture" in relation to software development. I'm intimately familiar with the concept of emergent order, though, and my grokking it was part of my "political awakening" in my 20s. It led me from being a libertarian-leaning conservative to an anarcho-capitalist. To put it anot…

You'd probably like Milton Friedman's ideas, and I'd be surprised if you've not already come across his work and YouTube lectures.

There is something to be said for small government, but also can go too far: actors acting in their own best interest can obviously cause harm to society or to the larger group as a whole (See "tragedy of the commons").

Related to emergence is rapid iteration, and it's importance to analysing complexity, which is caputured nicely in "Boyd's law". See https://blog.codinghorror.com/boyds-law-of-iteration/, and then see if you can find the referenced paper by Roger Sessions. (Sessions seemed to caputure the essence of "Lean Startup" before it was cool...)

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

#170

Post by mbar84 »

stcredzero wrote: post #134

But but but, the problem is Waterscrumfall, not Agile as intended in the Manifesto Here's the thing. Corporations are hierarchical. Human beings are hierarchical. We're also communal, but start putting us into larger and larger group situations where we're facing competition, stress, and we must engage in concerted effort, and we go into hierarchical mode. Why does everything tend to go back to waterfall? It's becaus…

Very well said. If there's a methodology that starts with: these are the people involve, these are their incentives and this is the expected outcome in game theory, then I think we'll be making progress on methodology.
Post reply on HN