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

181–190 of 420 posts

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

#181

Post by shados »

JustSomeNobody wrote: post #173
avgDev wrote: post #153

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…

Well here's the thing. Often I'm asked for my estimate in the same meeting I first see the story. I have no way of researching before giving an estimate. > ... and then if PM/boss don't understand there is not much you can do but probably look for a better gig. If only it were that simple.

> Often I'm asked for my estimate in the same meeting I first see the story

That's definitely awful. Personally when I was leading agile teams, for anything non-trivial we'd start by creating an issue to scope the individual parts of the project, frequently allocating several days to do so.

And some stuff is still mostly unscoppable. That's where Fermi estimation and the whole "How many chips can you fit in the empire state building" time deal comes into play. You have no way to really know how long something will take, but we need to allocate resources SOMEHOW, even if its completely off. An imperfect guesstimate is better than none at all.

The catch is that everyone involved has to know that its an imperfect (and potentially completely wrong) guesstimate, and it has to be revisited regularly as new information comes in. Everyone also has to be ok with restructuring the project (or even cancelling it, in extreme cases!) if we learn its completely wrong.

We recently discovered at work that an assumption/decision that was made nearly 2 years ago turned out to be totally false. The project that relied on that false assumption was about 10% in (the assumption was made long ago, but actually work started recently). We had to sit together and ask ourselves if it was actually worth pushing through the 90% (and likely regret it in a year), or agree to scrap the 10% and start over now that we know what we're doing. We have to be careful not to pull off a Vista/WinFS resource blackhole though!

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

#182

Post by RocketSyntax »

shados wrote: post #126
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…

> 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…

It's more about what is BEHIND the button.

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

#183

Post by filoleg »

xfitm3 wrote: post #53
quadcore wrote: post #13

Agile never gave organizations a holistic, viable alternative to Waterfall. Because there’s a difference between theory and practice. Product work is more about practice. When we complain about “AINO” (Agile In Name Only), we’re not being honest with ourselves. I agree with most of the article. Specially the keep-learning part. All Agile did was put software development teams unfairly under a microscope. I believe Ag…

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?

>I want to be alone - what's so wrong with that?

If you are writing software just for yourself, there is nothing wrong with that. If you are writing software for others, be prepared to be steamrolled by people who know how to write good code AND how to communicate with consumers of the software (i.e., paid customers, OSS devs, enterprises, etc., that one will depend on what kind of software you are writing).

I think that a lot of developers with a mindset similar to yours tend to underestimate how important good/valuable feedback (and communication in general) is. And I am saying that as someone who initially went into comp sci for reasons similar to yours. Some of the best engineers I ever worked with had amazing communication skills, and it acted as a x10 multiplier to their technical skills and overall productivity.

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

#184

Post by kryogen1c »

avgDev wrote: post #153
shados wrote: post #126

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…

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 in the hall and says "hey you, how long will this take?" That is not a reasonable question, so sure you cant give a reasonable projection. If youre a professional coder and you show up to a planning meeting and your answer is "I dont know, i have no idea and its not possible to provide an answer even on an order of magnitude" thats just ridiculous.

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

#185

Post by xmprt »

rhizome wrote: post #175
avgDev wrote: post #153

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…

> 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. This isn't personal, just a comment on a way of thinking that is not u…

I wish people were more comfortable saying "I don't know but I can do some research and get back to you later." Often times that's where the conversation about time estimates ends because they don't ask you again unless it's actually important. And if they do ask you, now you have a better answer (assuming you actually looked into the problem you're trying to solve).

The other problem with time estimates that I find is that even though I might know for sure that a certain feature will take only a day or two, I can't tell when it'll be done because I usually have other things to work on as well.

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

#186

Post by dymk »

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.

Maybe a spike takes a week. Maybe a spike takes an hour. I can't estimate that.

Which would be fine, but then management or the PM expects me to loop back around when a spike is complete. I'd rather just continue engineering a solution when I'm done investigating, which is the natural progression of things.

I'd rather treat {get requirements, investigate, implement, debug, deploy} as a single atomic task, rather than splitting it across N meetings for planning the sprint, planning the spike, meeting with the PM for more requirements they forgot to put in the user story, describing it at a retrospective, showing it at a demo.

Now I know somebody will say "But that's now how agile works!". Well, we have a few agile "coaches" that were embedded in our teams who would disagree.

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

#187

Post by stcredzero »

mbar84 wrote: post #170
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.

Methodologies are pretty good about that in the short term. If Agile were bad at that, then it wouldn't have spread. I think the problem is more Agile in the long term. It's a more general problem faced by longer term software projects.

The answer might be to have shorter term software projects. Make everything more modular, have a standard backplane into which everything can plug into, and enable competing short term projects. I think today's trend is to make corporations into ecosystems, and this change might be able to shape incentives positively.

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

#188

Post by bitwize »

Agile in practice is a way for Corporate to have its cake and eat it too: get the results and productivity associated with outstanding programmers, using the programming talent they have/can hire, with a minimum of risk exposure. Part of this is the attempt (also seen in other corporate quality efforts like ISO9000) to distill skills into process: to produce a book of rules that, rigidly enforced on relatively unskilled workers, will cause them to perform at the level of highly skilled workers. Hence my repeated quip that "Agile is attempting to emulate a good programmer with an array of average programmers". Unfortunately for Corporate, It Just Doesn't Work That Way.

Now I believe that Agile was started with good intentions, but today it is much more a motte-and-bailey doctrine. The motte being "Agile is the values in the Agile Manifesto". The bailey being "Agile is Scrum and SAFe, and all these meetings, ceremonies, and process are a necessary component of Agile". And I think this is why people fall into no-true-Agile discussions and eventually end up disappointed with something that showed a lot of promise. Agile started off a plea from programmers to Corporate, and it caught Corporate's ear. But once in Corporate's possession, it was deployed to serve Corporate ends only.

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

#189

Post by davesnothere »

kryogen1c wrote: post #184
avgDev wrote: post #153

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…

The domain is different in a way you don't understand.

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

#190

Post by asark »

lonelappde wrote: post #82
mstade wrote: post #24

Earlier quoted context omitted.

I think maybe the point they're trying to make is that comparing a software development project that may include a number of unknowns to buying a pair of jeans where there are probably very few if any unknowns is fallacious and a waste of time. That said, I don't think it's black and white. Some projects, making a simple web site that follows whatever Squarespace template is popular and filling it with some relevant…

And every engineer likes to pretend that their project is a moonshot. If you are inventing something incredible,why are you someone's employee instead of getting capital investment or self-financing from your last achievements?

It is when stakeholders throw curveballs.

"We want you to do this."

"Sweet, easy enough, I'll just use X, Y and Z, no problem."

"Oh but sorry you have to use A, B, and C instead. Oh and it'll need to connect to D for reporting, and we'd like it to sync with E which we've never done but they have an API so it can't be too hard, right? Oh and it needs to fit this design we've already approved that's about as far from native to the platform you're developing for as it could be and has a ton of UX issues that require fundamental changes to fix, which you'll uncover as you work. That's about as easy, right?"

"...."

[EDIT] oh and also one "minor" feature we're going to toss in later is actually big enough to build an entire company around so you'll have to waste a bunch of time talking us down from that while we quietly lower our opinion of you, and we've accidentally described a few things which are basically impossible by egregiously violating e.g. CAP theorem or being what's effectively a highly-available distributed filesystem that needs to fit without our timeframe and budget, which is 1/20 what it would take to maybe build that and that alone.

Post reply on HN