Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

quora.com

Post reply on HN
Print view View original

171–180 of 239 posts

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

#171

Post by InvOfSmallC »

pizlonator wrote: post #60
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…

Some of the most beautiful code I’ve ever seen has come of an engineer going off for several months and coming back with a 1MB patch. That kind of time allows some actual deep thought to happen. Some kinds of outcomes won’t happen any other way. I agree with that point in the quora answer. This comes to mind as a recent example of an engineering project that had no incremental alternative: https://webkit.org/blog/932…

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.

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

#172

Post by temac »

Jtsummers wrote: post #14

This article makes a common mistake: Scrum and Agile are not synonymous. Given that error, the conclusion is nonsense. And besides, even Scrum doesn’t require a delivered product each sprint. Just an updated status and increment completed. If I’m building a new server and client architected system, the early sprints may be getting certain design details down. More documentation than code. Later on, I may have sprints…

If you redefine "agile" as common sense and what currently works for you, and "waterfall" as failure, then obviously every good thing will be "agile", and wrong stuff will be "waterfall".

Can we do anything with that though?

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

#173

Post by InvOfSmallC »

grok2 wrote: post #75

Anybody doing Agile/Scrum know how it deals with people issues? It seems like with these practices everyone is on a tight leash -- how does it deal with the fact that real people have a natural ebb and flow in their concentration levels at work or interest in work. If your are scrumming all the time, how do you get slow periods in your work cycle so you can recharge (aka slack-off :-))?

I work with agile and have 20% of time for personal stuff I want to try/study. Every week.

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

#174

Post by viscanti »

edw wrote: post #160
viscanti wrote: post #154

Earlier quoted context omitted.

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

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

We agree. If someone has maxed out all the relevant dimensions then there's no room for improvement. The problem is that there's a difference between that and average. The other problem is that there's continual room for being even better at identifying solutions.

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

Unneeded re-writes and getting better are orthogonal concepts. That you're confusing them here underlines the logical fallacy that you're making. If there's legitimate room for improvement (and there generally is in bus driving and in software engineering), and if that improvement makes you substantially better at your job, then it's worth it. In neither of those areas is the "average" employee completely topped off in where they can grow.

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

#175

Post by 2muchcoffeeman »

lonelappde wrote: post #166
Spooky23 wrote: post #139

Earlier quoted context omitted.

That’s by design. Keeps the workforce young and insurance cheap.

Why would companies prefer cheap insurance over productivity? If they want to pay less, they can just pay less. People would rather get paid less than get fired.

Is it about cost?

It’s often easier to get that pay raise by hopping companies. You’re then replaced with a new hire who is probably getting more than you did. And needs a few months to get up to speed.

Treating your proven employees well to retain them would cost less.

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

#176

Post by coldtea »

paganel wrote: post #169
coldtea wrote: post #165

Earlier quoted context omitted.

> How are programmers different from bus drivers? In that programmers are supposed to be creative, over-deliver, etc. You'd worry if a bus driver got from A to B in half the time driving twice as fast suddenly. But you'd be OK if a programmer you've asked to design system with features A, B, C and performance P, also delivers features D, E, F and performance 2*P without being asked!

> In that programmers are supposed to be creative, over-deliver, etc. Like I said, I don't want the programmer in charge of the software that manages my financial or health records to be creative or over-deliver, quite the contrary. I'd add personal-data to the mix, and now I've covered a huge chunk of SV companies. I think that the era of "move fast and break things" should be over by now, unfortunately relatively p…

>Like I said, I don't want the programmer in charge of the software that manages my financial or health records to be creative or over-deliver, quite the contrary.

Sure, but most programmers don't program systems that manage financial or health records or write the software for the ISS.

For the majority working on enterprise backoffice stuff, CDUD, web services, mobile and desktop apps, websites, and so on, being creative and over-delivering is OK, and even encouraged.

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

#177

Post by artsyca »

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…

Don't call it 'suitspeak' -- these suckers haven't ever had the decency to wear formal business wear; it's `golf shirt speak` at best

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

#178

Post by pizlonator »

InvOfSmallC wrote: post #171
pizlonator wrote: post #60

Earlier quoted context omitted.

Some of the most beautiful code I’ve ever seen has come of an engineer going off for several months and coming back with a 1MB patch. That kind of time allows some actual deep thought to happen. Some kinds of outcomes won’t happen any other way. I agree with that point in the quora answer. This comes to mind as a recent example of an engineering project that had no incremental alternative: https://webkit.org/blog/932…

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.

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

#179

Post by Mangalor »

steelframe wrote: post #21

Speaking as someone who has been at Google for about 10 years, I would caution against trying to paint "developers at Google" using broad strokes. Google is a multifaceted megacorporation housing a plethora software project categories. Through the years I've been deeply involved in a wide spectrum of them, ranging from "disconnect for 6 solid months and deliver a leapfrog for the masses" to "form an umbilical cord wi…

> "disconnect for 6 solid months and deliver a leapfrog for the masses"

What a luxury that must've been...

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

#180

Post by [deleted] »

smdz wrote: post #110
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…

And did your manager go on to get another promotion? And may be few more team members had similar jumps in performance? A new manager we had deliberately did this to us. Few of us got marked as "under-performer" levels at random times - risk of being terminated by the bell-curve justification and then within 6 months (not at the same time) we all were "exceeds expectations". The few of us figured out what the manager…

[deleted]
Post reply on HN