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

231–240 of 420 posts

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

#231

Post by uygarpe »

ehutch79 wrote: post #201
kryogen1c wrote: post #184

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…

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

I'm going to steal this if you don't mind.

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

#232

Post by chrshawkes »

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.

It's even worse when your lead is giving timeframes for you...

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

#233

Post by btilly »

Software development has some fundamental challenges that have been faced since the start, and always will. Understanding them matters. Here are some of the big ones.

1. Developers need to communicate with each other. A lot. This takes time. The amount of time goes up non-linearly with the size of the team. (The Mythical Man-Month claims a scaling law of n^2.)

2. Adding process + documentation of various kinds can turn that from unbounded time spent speaking to a large but bounded written effort.

3. Nobody is good at predicting schedules.

4. Good news travels, bad news doesn't (until the last moment).

The traditional solution was to solve #1 with #2, put a lot of effort into schedules for #3, and get blindsided over and over again by #4. The average result was that the average delivered software project took over 2x what was estimated, cost over 2x, and was delivered with under half the promised features. But, no matter how delayed, usually didn't start slipping the promised deadline until about 2 weeks before the first official release deadline. And these were the success stories, since most software projects never really got delivered.

What Agile opened up was the perspective that there were other approaches possible. For example we can solve #1 by having small teams, which makes #2 unnecessary, solve #3 by making projects small enough to not need good prediction, which creates a feedback loop to avoid #4. And that is not the only valid tradeoff.

But this is not a one size fits all. Real world data shows that a team hits peak throughput at 5-8 people, declines, and doesn't get back to the same overall throughput until 20+. (After which it is almost linear, but with much lower individual productivity.) The teams as drawn on the org chart don't matter. The teams as they actually interact, do.

If you understand your options, and understand the tradeoffs, you can figure out how to customize the right solution to the people/organization. If you don't understand the tradeoffs, the best that you can do is blindly copy what worked somewhere else and pray that you got it right. And if it turns out that you didn't, develop superstitions about what you should have done instead.

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

#234

Post by hinkley »

commandlinefan wrote: post #200
ALittleLight wrote: post #195

Earlier quoted context omitted.

I've worked about 10 years at FAANG companies and I'm yet to meet the experienced and expert devs who are good at estimating things. I think your characterization of "inexperienced and clueless" devs is off. The reason I think my example illustrates a problem is it's moving away from agile. I shouldn't estimate X without understanding it? Okay, I'll take the time to figure out, look around corners, etc. I realize I n…

> If we need X then let me work on it If you look through the managers who are weighing in on this thread, you’ll notice a common perspective: they don’t trust you to actually work on something. That’s why I have so little hope for any software methodology - even if it starts from something positive (like XP, which was the precursor to “agile”, did), it will be turned into “I know all of my programmers are stealing f…

In part because we still measure effort in hours instead of in wear and tear. That guy answering comments on Hacker News is probably trying to recharge, not steal from you.

I learned recently that the crane operators that unload cargo ships at some major ports can’t work more than four hours at a time. The movements are too precise and take a great deal of attention. I think you can work two shifts per day but there’s a mandated gap of some number of hours between them.

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

#235

Post by cr0sh »

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…

This would've worked if you'd taken your initial estimate (1 week) - bumped it to the next unit (1 month) - then doubled it (2 months). Maybe you would've been given 9 or 10 weeks, so you'd have the week for X, and 1 month each for Y and Z.

I understand this is a contrived example, but it's strange that, when you take a real project that "overran" based on the initial estimate(s), and you apply the formula - just how often the formula is actually really close to the actual amount of time.

Not always - but more often than not.

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

#236

Post by hinkley »

twic wrote: post #26
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?

Writing software is design, not manufacturing [1]. Do companies know accurately in advance how much it will cost to design a new nuclear power plant, aircraft carrier, or jet engine? [1] http://www.bleading-edge.com/Publications/C++Journal/Cpjour2...

Design or repair.

These are the same people who get furious at their mechanic or plumber when they double the time estimate.

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

#237

Post by outworlder »

geezerjay wrote: post #163
ALittleLight wrote: post #96

Earlier quoted context omitted.

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

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

Wow, so much hubris in such as small post.

Unless you have been doing the exact same thing forever(in which case you are at a risk of being replaced), new work _always_ comes with a degree of uncertainty. Be it new technologies, new business requirements or what have you. I have never worked in two identical projects in my life.

The correct answer would be a 'spike' or proof of concept. Either that, or hire those magical developers you seem to have who know everything there is to know.

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

#238

Post by outworlder »

akkartik wrote: post #224

"Stop unfairly putting dev under a microscope and letting everyone else hide in a black box. Why aren’t we just as concerned with how strategy teams operate? Or how legacy architects are constraints in the system?" Are other ladders in an organization not subject to performance review?! Managers? PMs?

They usually don't get _anywhere near_ as much scrutiny.

Dev gets performance reviews _plus_ the microscope.

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

#239

Post by chhickman »

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…

> Refueling nuclear aircraft carriers have projections start to finish, a half decade long.

The difference is that those projections weren't spit out on the fly by a engineer after a 15 minute pitch of some manager's great new idea. Those plans took many months of effort to put together by a team of specialists planning out the various details of the project. Software does have the equivalent of this, it's called waterfall development. The reason we don't do this is because, unlike aircraft carrier design, if you take six months to create a project plan your requirements will have likely already substantially changed.

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

#240

Post by cr0sh »

apatters wrote: post #36
twic wrote: post #26

Earlier quoted context omitted.

Writing software is design, not manufacturing [1]. Do companies know accurately in advance how much it will cost to design a new nuclear power plant, aircraft carrier, or jet engine? [1] http://www.bleading-edge.com/Publications/C++Journal/Cpjour2...

There are times when something truly original is being built and it's a valid argument for estimate uncertainty. But a significant portion of the industry is engaged in building CRUD app #237 or Ho-Hum SaaS #17, and a significant percentage of estimates end up wrong because some developer who was bored with his job decided to use a blingy new Javascript framework he had no experience with because he wanted a challeng…

I wonder if you looked at time estimates from developers of common process applications (like CRUD) in say, the 1980s, who used COBOL or FORTRAN, vs say those using Pascal or C - if those developers of code using extremely well known processes and libraries had better estimates than those using the "newer bling"?
Post reply on HN