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

201–210 of 420 posts

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

#201

Post by ehutch79 »

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…

False equivalence.

You planning 'how to put fuel in a nulean aircraft carrier'.

For most software projects the equivalent question being asked is 'can you put some fuel in this thing we have'.

When asking things like * what kind of fuel * is the thing a container or a vehicle * etc

The response is often 'isn't it obvious, you're the developer you should know'.

Can you tell I'm in the middle of training coworkers to offer up proper requirements.

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

#202

Post by Isamu »

celticmusic wrote: post #178
Isamu wrote: post #157

Earlier quoted context omitted.

>That's when I knew it was time to leave that team Currently in that situation. My "agile" estimate blew up by a factor of as much as 10, just because the ask was conceptually very simple, even to the domain experts I consulted. And by bad luck the way I was implementing the story it happened that the issues unfolded one-at-a-time, rather than somewhere in the beginning where we could have broken things up into more…

why in the world would you ever use the end of a sprint as a hard deadline? That's broken from the get-go.

>That's broken from the get-go.

Indeed.

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

#203

Post by SkyBelow »

eeZah7Ux wrote: post #168
kjsbfkjbf wrote: post #58

Earlier quoted context omitted.

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.

Why?

In all areas of life we judge those around us not by the true facts, but on our limited knowledge. Working to improve that knowledge can result in a change in judgment. It seems completely reasonable for there to be a person who does good work but who isn't know for doing such, and as such is viewed worse than they should be. By working to increase the knowledge of the work they do, their evaluation in the eyes of others will improve.

Of course, it isn't a straight forward or simple in practice. There are those who lie and misrepresent, and if you are to obvious about your intent you will be viewed as manipulative.

I don't see why this deserves either the label of BS or a ban from HN?

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

#204

Post by rhizome »

Isamu wrote: post #157
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…

>That's when I knew it was time to leave that team Currently in that situation. My "agile" estimate blew up by a factor of as much as 10, just because the ask was conceptually very simple, even to the domain experts I consulted. And by bad luck the way I was implementing the story it happened that the issues unfolded one-at-a-time, rather than somewhere in the beginning where we could have broken things up into more…

>My "agile" estimate blew up by a factor of as much as 10, just because the ask was conceptually very simple

Please do not feel bad, nor let anybody make you feel bad about this. It's absolutely natural for this to happen. If anything you could use it to ask for a junior or intern to delegate implementation details while you dig further into the coal mine of this feature.

"Simple is hard." What you can learn from this (beyond team pushback) is what kinds of questions can be asked to figure out if a simple ask is masking 10 other things.

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

#205

Post by karmakaze »

I wish the post visited each of the principles. I can't find one I disagree with. It's all in the interpretation and implementation. Agile for me is not a single methodology that you develop. It's about refining and redefining processes that work for you team and org.

Principles behind the Agile Manifesto

We follow these principles:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Business people and developers must work together daily throughout the project.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Continuous attention to technical excellence and good design enhances agility.

Simplicity--the art of maximizing the amount of work not done--is essential.

The best architectures, requirements, and designs emerge from self-organizing teams.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

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

#206

Post by rhizome »

justinpombrio wrote: post #106
java-man wrote: post #97

Earlier quoted context omitted.

I think there is a way to give an estimate (have been doing it myself for a decade), even for dependencies that are not known from the start. (I mean, reasonable dependencies. No one can account for unknown unknowns, but the software engineering field is not an art, more of a skill, we do have well established processes to minimize the surprises). Is this something that HN audience is interested in?

> Is this something that HN audience is interested in? Are you teasing ? Yes, we want to know! Though frankly I'm incredulous.

Fred Brooks would be incredulous.

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

#207

Post by nprateem »

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 still can't estimate how long something will take me when I've never done it before

In that case you're meant to do a spike to research the issue. You can timebox the spike to half/whole a day. Then use that knowledge to help your estimation for the following sprint.

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

#208

Post by FpUser »

lordleft wrote: post #7

The best way I've seen agile described is "designing code in a way that acknowledges change.' I think there's a lot of value in understanding that you may have to go back to the drawing board when designing parts of your program. I have little regard for the entire industry that has risen up around agile, however.

Exactly my thoughts.

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

#209

Post by nprateem »

dymk wrote: post #186
matthewhartmans wrote: post #162

Earlier quoted context omitted.

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…

What are you doing in a spike? If you can't work out after a day the rough complexity of the task (bearing in mind you should be working on a small deliverable) there's something seriously wrong. You're not meant to be doing the work in the spike. If your research spike shows that it could be a can of worms, then the outcome of it should be another ticket for a proof-of-concept for another sprint, but with specific goals (e.g. "get a POC working that does X, Y & Z").

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

#210

Post by zentropia »

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…

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?"

Post reply on HN