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)

#211

Post by pmorais » Sun, Aug 04, 2019, 6:38 AM UTC

ma2rten wrote: post #22

crazygringo wrote: post #5

This post feels a little disingenuous... First of all, it's not like most engineers at Google are working on Bigtable or Borg, with a "very simple interface and tons of hidden internal complexity". Plenty of them are working on normal consumer-facing products, the "software with a simple core and lots of customer visible features that are incrementally useful", although maybe that's not the hype people want to believ…

First of all, it's not like most engineers at Google are working on Bigtable or Borg, with a "very simple interface and tons of hidden internal complexity". I would say that most engineers are working on something like that. Those two examples are from google cloud/technical infrastructure, but other products such as search and ads have tremendous complexity behind them.

I feel like this hubris is why almost every google product I use is riddled with horrible bugs. The cursor move functionality on Gmail for iOS has been broken for TWO YEARS. It’s also why the tensorflow API is a horribly over-engineered abomination when Pytorch is almost at feature and performance parity with something exponentially simpler and more consistent/elegant. That “biggest baddest solution” culture makes sense for Bigtable; it’s god-awful for anything remotely customer facing.

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

#212

Post by JSavageReal » Sun, Aug 04, 2019, 6:53 AM 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…

How is this even legal? Is there a movement to ban stacking ranking? If we don't voice our concerns as employees, then nobody will.

Also the fact that "meets expectations" is concern for firing makes absolutely no sense. A plumber who "meets expectations" in fixing my toilet is a good plumber. I don't expect a plumber to go "above and beyond" and give me a Thai massage too.

Absolutely unreal some of the crap we put up with in this industry. Blows my mind that there are actually humans out there in management positions advocating for and implementing this totalitarian dystopian garbage, throwing away their employees for "meeting expectations" as if they're disposable "widgets".

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

#213

Post by theworld572 » Sun, Aug 04, 2019, 7:35 AM UTC

mmcnl wrote: post #164

theworld572 wrote: post #48

Earlier quoted context omitted.

Whats the point of SCRUM then? If all it does is to tell you "do what makes sense" why do we even need it? Thats a rhetorical question, I already know the answer is that we need it in order to keep SCRUM consultants, certifications, training etc. a profitable business. Whether or not you think SCRUM is good or bad, you can't argue that a sizeable (if not the majority) amount of companies are "not doing it right" and…

Working is not vacation. Sticking to a process is a hygiene factor which doesn't necessarily has to be fun but it makes it possible for companies to be properly managed. That being said, stop complaining. If you can find room to complain, you surely can find room for improvement right? It might just be me, but everywhere I've worked I've never encountered a manager who isn't open to solid ideas for improvement.

I never said I wanted software engineering to be fun. I have worked on 4 different teams that followed Scrum and all four of those teams suffered from the same problems - low productivity and poor management. The most entertaining was a recent place I worked where we had a certified Scrum master who had been "trained" by one of the two founders of Scrum, when I joined I told him about some of the bad experiences I've had with Scrum and he said "yeah that annoys me, those teams are not really following scrum and so teams think that scrum is bad but really they are not doing it right". Of course in the months to come I realised that we ended up with the same exact issues I saw in previous teams. In contrast theses problems were just non-existent in teams that did not follow a set methodology.

Scrum is just not a good way to manage a team. I find Scrum to be a lot like religion - it means different things to different people but its evangelists always have a pre-prepared answer to every possible criticism, usually containing lots of jargon, buzzwords and double speak.

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

#214

Post by theworld572 » Sun, Aug 04, 2019, 7:36 AM UTC

insertnickname wrote: post #126

theworld572 wrote: post #48

Earlier quoted context omitted.

Whats the point of SCRUM then? If all it does is to tell you "do what makes sense" why do we even need it? Thats a rhetorical question, I already know the answer is that we need it in order to keep SCRUM consultants, certifications, training etc. a profitable business. Whether or not you think SCRUM is good or bad, you can't argue that a sizeable (if not the majority) amount of companies are "not doing it right" and…

Scrum , not SCRUM . It's not an acronym.

Good to know.

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

#215

Post by solipsism » Sun, Aug 04, 2019, 7:47 AM UTC

okcando wrote: post #136

solipsism wrote: post #100

Earlier quoted context omitted.

If an employee is as good as you think they should be, why would you put it at risk of termination? Because quality of the employee and the employee's work are not the only factors in hiring and firing decisions. Sometimes a smaller workforce is what makes sense, and if all your engineers are "meeting expectations", what are you going to do?

There are other factors but just one is under discussion: cutting the bottom five percent in performance reviews. And if consecutively "meeting expectations" puts you near the bottom, then the expectation must actually be to exceed expectations. Nevermind that this policy necessarily means churn and undervaluing aspects of software like security or fault tolerance and a constant drain of institutional knowledge.

I'm not arguing for the policy. I wouldn't want to work at a place like that.

But I feel like this isn't very hard to understand and I don't know what you're not getting about it.

And if consecutively "meeting expectations" puts you near the bottom, then the expectation must actually be to exceed expectations.

Uh.. no.. you seem to think "meets expectations" necessarily means "will not get fired". This policy exists, as dumb as it may be. Imagine you're a manager at a company like this and you're tasked with giving a performance review. You have two choices: you could do what you seem to be implying they should go and fudge the ratings, so that the bottom 5% always get "does not meet expectations." Or you could say "fuck that stupid rule, I'm going to rate this person honestly, and if they still fire him that's their choice."

A performance rating and a company policy about firing are two completely separate things. I think you must have a naive understanding of how staffing decisions are made in the real world.

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

#216

Post by InvOfSmallC » Sun, Aug 04, 2019, 7:48 AM UTC

pizlonator wrote: post #178

InvOfSmallC wrote: post #171

Earlier quoted context omitted.

I'm sorry but what's the point of a 1MB patch of beautiful code? Did this programmer actually develivered a business value for the customer or not? I'm not saying that you should not maintain your code nice, decoupled and what note, but having as a major KPI the code being beautiful to me it's non sense.

The point? Read the article. It’s a big perf win. It’s important that it’s beautiful since the bytecode of a VM gets used so much throughout some of the VM’s most complex parts. Beautiful code is easier to use and maintain.

I read the article. And I don't really think that we mean the same thing with beautiful code.

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

#217

Post by GordonS » Sun, Aug 04, 2019, 8:41 AM UTC

empath75 wrote: post #67

theworld572 wrote: post #31

Earlier quoted context omitted.

My biggest criticism of Agile and Scrum is that it assumes that you can just plan out how a feature will work by sitting in a meeting and talking about it. Then spend the next two weeks implementing that plan. Software development almost never works out so neatly. What really happens is that you have a set of requirements and an idea of how you are going to implement the feature. You start working on it, maybe you di…

> My biggest criticism of Agile and Scrum is that it assumes that you can just plan out how a feature will work by sitting in a meeting and talking about it. Then spend the next two weeks implementing that plan. They don’t, there are ‘spikes’ that are just time spent researching or exploring or designing rather than implementing. If your scrum master is telling the team what they can’t or can’t do, or how they should…

> If your scrum master is telling the team what they can’t or can’t do, or how they should do their jobs, they are doing it wrong

Unfortunately in my experience this does happen quite often. I've found the biggest issue with scrum is when people (usually the scrum master and PM) take hard-line, dogmatic views of scrum processes.

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

#218

Post by collyw » Sun, Aug 04, 2019, 8:45 AM UTC

Retric wrote: post #8

gilgoomesh wrote: post #7

I think the answer badly misconstrues the purpose of "short term planning" and "continuous integration" as though these concepts preclude long proof-of-concept projects. The point of short delivery cycles is not to deliver a viable product to an external customer every two weeks. Rather it simply ensures that code remains in-sync with its intended use-case and guards against individuals going off on untracked tangent…

Doing 1 month without integration is still fine. When agile was conceived doing 6 sprints per year would have been considered agile in many fields. The goal is to be able to be as responsive as reasonably possible not simply to add thousands of mostly meaningless milestones. It turns out that most projects can be broken down into absolutely tiny pieces, and that is generally a good idea. However, the core idea is you…

>It turns out that most projects can be broken down into absolutely tiny pieces, and that is generally a good idea.

Generally I agree, but I have noticed in doing things like that, no one ever seems to bother about refactoring, or tidying things up at a higher level.

Our designer complained about the CSS organization and spend a couple of days tidying it up. I have a feeling that breaking of tasks into small pieces takes away focus from more long term commitment to code organization and architectural patterns.

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

#219

Post by goatinaboat » Sun, Aug 04, 2019, 11:06 AM 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…

A previous employer had had that rampant feedback inflation for years, and reset it one year. The Big Boss - quite reasonably in my mind - said “our expectations are high and you should feel proud of meeting them”. But the company culture was still set up around “strong exceeds” being the norm and “meets expectations” being code for “massively underperforming” so that was an uphill battle. And many of those who had gotten used to “strong exceeds” really were massive underperformers. Really to make this work they should have deleted the entire history from the HR database.

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

#220

Post by goatinaboat » Sun, Aug 04, 2019, 11:09 AM UTC

jecxjo wrote: post #151

gordaco wrote: post #38

Earlier quoted context omitted.

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

This lead to a dark rabbit hole and a lot of engineers leaving.

But, I bet, a large and well-resourced HR department, which was the real goal. Who invented the system, after all.