Why do developers at Google consider Agile development to be nonsense? (2016) • Hacker News Board

Re: Why do developers at Google consider Agile development to be nonsense? (2016)

#151

Post by jecxjo » Sat, Aug 03, 2019, 8:04 PM UTC

gordaco wrote: post #38

js2 wrote: post #29

> This type of innovation takes significant up-front design time, and working on components over longer than one week iterations. Because the projects have such simple external interfaces, and so much internal complexity, much of the work is not even visible to “customers”, so there is no way to write customer visible stories about it. This type of software takes 8–20 months to deliver the first working version to th…

> Little did my manager know that a few quarters of "meets expectations" had caused HR to drop me into the bottom 5% of the company and so I received a letter from HR that I was at risk of being terminated. This is disturbing and, I think, a twisted form of grade inflation, mixed with the usual suitspeak where words don't necessarily mean what they mean. If an employee is as good as you think they should be, why woul…

I worked for a large global company and this matched exactly what I was seeing. I had projects with year or more development cycles before something was deliverable so "meets expectations" was difficult when you had nothing to show for your work as they only cares about final results. We even had an unwritten rule where everyone must have at a minimum two "needs improvement" because "everyone should be working on making themselves better." This lead to a dark rabbit hole and a lot of engineers leaving.

With such a messed up evaluation process engineering demanded direct, documented process for doing evaluations. Instead we had managers trying to gauge output based on defects fixed and lines of code committed. You could tell management had no clue.

Re: Why do developers at Google consider Agile development to be nonsense? (2016)

#152

Post by mnd999 » Sat, Aug 03, 2019, 8:05 PM UTC

will4274 wrote: post #108

caconym_ wrote: post #35

Earlier quoted context omitted.

Is "the masses" offensive?

No, but some people are sensitive. I suspect most Google developers consider themselves part of "the masses"

I’m not sure that’s true

Re: Why do developers at Google consider Agile development to be nonsense? (2016)

#153

Post by tus88 » Sat, Aug 03, 2019, 8:06 PM UTC

js2 wrote: post #29

> This type of innovation takes significant up-front design time, and working on components over longer than one week iterations. Because the projects have such simple external interfaces, and so much internal complexity, much of the work is not even visible to “customers”, so there is no way to write customer visible stories about it. This type of software takes 8–20 months to deliver the first working version to th…

The workplace culture this kind of Lord of the Flies management approach results in must be horrendous.

Re: Why do developers at Google consider Agile development to be nonsense? (2016)

#154

Post by viscanti » Sat, Aug 03, 2019, 8:09 PM UTC

paganel wrote: post #150

adrusi wrote: post #140

Earlier quoted context omitted.

Eh, the language makes a bit more sense than that. It's a bit too euphemistic for my taste, but it's reasonable. "Meets expectations" — which expectations? The expectations for the role of for the employee? If we're talking about the expectations for the employee, then obviously it makes no sense for meeting expectations to be a bad thing. But if instead we're talking about expectations for the role, it's perfectly c…

A bus driver that “meets expectations” is the perfect bus driver, I don’t want him to “continually improve” thinking that he’s the new Ayrton Senna, I don’t want to be driven around by drivers who think that they’re Formula 1 drivers. How are programmers different from bus drivers?

> A bus driver that “meets expectations” is the perfect bus driver

By what standards are Bus Drivers evaluated? Near accidents are OK as long as they're lucky enough to not be involved in a real accident? If so, I'd prefer they actually improve and decrease their odds of being in a future accident. Does efficiency matter? Maybe one that's on time more often is actually better? Maybe customer service matters, and they can get better at helping people who need to buy tickets for the first time?

> I don’t want to be driven around by drivers who think that they’re Formula 1 drivers

It seems like there are multiple dimensions that a bus driver can improve on that aren't "become a race car driver". Given that, it seems like the bus driver analogy already isn't a good one.

> How are programmers different from bus drivers?

It doesn't even seem like we need to answer this one. You started with the false assumption that there are no dimensions that a bus driver can improve on other than becoming a race car driver. One could argue that there are much wider ranges of value creation in programming between average and above average programmers, but that's irrelevant given your initial premise is obviously flawed.

Re: Why do developers at Google consider Agile development to be nonsense? (2016)

#155

Post by krinchan » Sat, Aug 03, 2019, 8:14 PM UTC

kd5bjo wrote: post #9

There is unfortunately a large gulf between “agile” and “Agile” development these days. The former refers to development generally in line with the agile manifesto, with processes tailored to the needs of the team and the project. The latter is a buzzword used by consultants to convince management to put their favored bureaucratic method in place, usually some variant on the scrum system.

This. Our team tends to take more of a Kanban approach and we've yet to miss a quarterly delivery and always have a good sense of how far along we are. Meanwhile, the higher ups think it's black magic we don't spend 4 hours in "sprint planning" every two weeks.

Re: Why do developers at Google consider Agile development to be nonsense? (2016)

#156

Post by vecter » Sat, Aug 03, 2019, 8:14 PM UTC

js2 wrote: post #29

> This type of innovation takes significant up-front design time, and working on components over longer than one week iterations. Because the projects have such simple external interfaces, and so much internal complexity, much of the work is not even visible to “customers”, so there is no way to write customer visible stories about it. This type of software takes 8–20 months to deliver the first working version to th…

It sounds like your manager failed to adequately represent your work.

Re: Why do developers at Google consider Agile development to be nonsense? (2016)

#157

Post by caminante » Sat, Aug 03, 2019, 8:21 PM UTC

hinkley wrote: post #115

The hardest part of working with really smart people is that they can rationalize pretty much anything. Worse still, if they have been on the project for years and you’re the new guy, you’re working from a deficit of knowledge and they’ve had plenty of time to cook up a “coherent but wrong” model of the universe. The only thing that saves a group like that is humility. Trying to see the system through the eyes of the…

There's a lag (potentially years) in judging peer competency (or cognitive dissonance) when you switch domains. Gatekeeping and poor new-hire integration are early warnings.

You might ask yourself if your current executives are aware of the issues you're seeing, then think through what you can control and re-prioritize.

Re: Why do developers at Google consider Agile development to be nonsense? (2016)

#158

Post by pjmlp » Sat, Aug 03, 2019, 8:22 PM UTC

bravoetch wrote: post #138

ckosidows wrote: post #132

Earlier quoted context omitted.

My company insists each ticket in Jira have a time logged on it now. This is on top of story points. Everyone I know has pushed back on it, but I hope this isn't becoming a standard elsewhere.

Product / project / scrum guy here. Logging time won't make sense unless each ticket is one person working on it at a time. The moment it becomes teamwork (like asking someone else for their thoughts on an idea) the value of time is meaningless. People are also useless at estimating time in advance, but pretty great with throwing a story-point number on a given story with the right guidance. Please feel free to sched…

Many companies use Jira tickets to track employee time, instead of having a separate time tracking system.

This creates a situation where everyone is searching for tickets to make up for their daily 8h.

Re: Why do developers at Google consider Agile development to be nonsense? (2016)

#159

Post by tom_ » Sat, Aug 03, 2019, 8:26 PM UTC

solidasparagus wrote: post #114

Udik wrote: post #57

Earlier quoted context omitted.

Who said that Googlers are not part of those "masses"? Surely they enjoy products from their company as anybody else? And then, of course, nobody said you're part of those masses anyway. Maybe you're not. Do you enjoy Google product X as other hundreds of million do? Then you're part of the mass that enjoys it. Otherwise you are part of the mass that doesn't.

'The masses' refers to the lower classes (look at any dictionary and how the word has historically been used - 'opiate of the masses', 'the unwashed masses'). It would not typically be correct to say that a Googler is part of the lower classer. 'The masses' is definitely not the same as 'everyone'.

Another way of putting it: words have connotations as well as meanings.

People do sometimes seem to forget this! - so it's good to have a reminder.

Re: Why do developers at Google consider Agile development to be nonsense? (2016)

#160

Post by edw » Sat, Aug 03, 2019, 8:34 PM UTC

viscanti wrote: post #154

paganel wrote: post #150

Earlier quoted context omitted.

A bus driver that “meets expectations” is the perfect bus driver, I don’t want him to “continually improve” thinking that he’s the new Ayrton Senna, I don’t want to be driven around by drivers who think that they’re Formula 1 drivers. How are programmers different from bus drivers?

> A bus driver that “meets expectations” is the perfect bus driver By what standards are Bus Drivers evaluated? Near accidents are OK as long as they're lucky enough to not be involved in a real accident? If so, I'd prefer they actually improve and decrease their odds of being in a future accident. Does efficiency matter? Maybe one that's on time more often is actually better? Maybe customer service matters, and they…

No, I think this is a fine metaphor. If an engineer can understand a problem, identify a solution, and then implement, document, deploy, and support it in production for project after project, it’s completely legit to say they’re good engineers, and are not necessarily improving in any relevant way.

Similarly, a bus driver that consistent drives without causing accidents, doesn’t spill the passengers’ coffee, doesn’t burn too much gas or wear out the breaks too quickly is a good driver.

What you say to either of these people is “Great job, we love you, keep doing what you’re doing!”

Encouraging growth and improvement as an end in itself can be destructive: How many projects amount to rewriting something that works in some new language or framework because an engineer wants to pad their resume or just learn something new?

Craig Mod recently wrote Fast Software, the Best Software; I’m hoping he follows that up with Software That Already Exists and Works Fine Using an Unsexy Suite of Technologies, Software that Doesn’t Need to Be Rewritten.