Slashdot Mirror
Good Agile — Development Without Deadlines
BigTom writes, "In a recent blog entry Steve Yegge, a developer at Google, writes a fascinating account of life at possibly the coolest development organization in the world. Steve lays out
some of the software development practices that make Google work. Go on, say you are not even a little bit jealous. ;-)" From the article:
- Developers can switch teams and/or projects any time they want, no questions asked; just say the word and the movers will show up the next day to put you in your new office with your new team.
- There aren't very many meetings. I'd say an average developer attends perhaps 3 meetings a week.
- Google has a philosophy of not ever telling developers what to work on, and they take it pretty seriously.
- Google tends not to pre-announce. They really do understand that you can't rush good cooking, you can't rush babies out, and you can't rush software development.
Really. Some of that seems nice from a worker prospective, but 3 meetings a week? That seems... excessively many...
34486853790
Connection too slow for X forwarding? Try "ssh -CX user@host"
3!? What do they need 3 meetings for?
Where I work, we have an average of about 1. and sonme of us think that that's too many
One thing that helps Google in this regard is that they are insanely profitable, and their software engineers as described in TFA are really more like product development entrepreneurs, so it's easier to set up an incentive-based program like this that puts a huge, juicy carrot in front of the developers to keep them headed in the right direction. I suspect that 99% of the rest of the IT world doesn't have this luxury.
That said, it's a very interesting example to consider. Within the coming months I'll be forming a new application development group, and the mechanisms of determining what we'll be working on and how it will be prioritized are TBD. Good food for thought, here...
Stop by my site where I write about ERP systems & more
There's got to be a catch somewhere!
for years.
Well! No wonder Gmail has been in beta for about 2 or 3 years now. Development without deadlines is akin to getting nothing done. People need direction, coordination, and most of all motivation. That doesn't mean you set unrealistic or oppressive deadlines, but deadlines are necessary to keep things moving - at least for those of us living in the real world.
Dude, I'm not sure if any of you complaining about meetings actually are in the same buisness as these guys but 3 is a good ammount. Usually with this type of job, there is a meeting every day!
So everyone should work within a large, hugely profitable organization...
Seriously, we cannot afford to be so cavalier about delivery dates etc in a team of four. In general, when the margin on the product isn't that great and/or you're understaffed, you'll run into trouble if you spend three days polishing how that button works.
So, how do you create great software when the resources are limited?
Stop the brainwash
awesome!
I spend at least 20% of my time scratchin me balls!
"Developers can switch teams and/or projects any time they want, no questions asked; just say the word and the movers will show up the next day to put you in your new office with your new team."
I work for Google and I can tell you right now that is total horse shit. Google are not so different than my previous employers, Oracle and Microsoft.
If anything, working in Google is worse than Oracle/Microsoft due to the people I work with (brainwashed losers.) They are the type of people who want to join a cult.
Many innovative corps start out that way, then turn into a bureaucratic dictatorship after a couple disappointing quarters.
Perhaps Microsoft could learn from this. they have never been good about deadlines. Not trolling however mabye it is just a business strategy.
The greatest revenge in life is massive success.
It depends on what you mean by meeting? If they mean every time you get together with two or more other developers for more than 15 minutes to discuss something, then I could see 3 meetings being not enough. If a meeting is when you get together with 15 other people and discuss things for an entire afternoon, then 3 is probably too many.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
Google can do this, and pretty much any company that can set its own time-table can use "Google Agile" methods. But you're limited to just those products where a delay of a few weeks or months isn't a major issue. It's simply not true for every type of software developer out there.
Maybe "Agile" methods aren't the absolute best out there, but there are cases where it's simply not possible to use "Google Agile" methods.
Sure, that sounds wonderful, as long as:
- you're working with intelligent, competent, creative people
- you have an effectively unlimited budget(relative to most other companies)
- you're working for a software-only company which is only successful because of its innovation, not because it has to deliver specific functionality to specific clients
How many of us can say that? Hmm?
It sounds like a dream job, but let's face it: it relies on individual heroics, from everyone, all the time. Now that's fine if everyone working there is far above average, and "individual heroics" means "enough intelligence and maturity to keep a view of the big picture without being whipped with a rolled-up Gantt chart", but it's a recipe for disaster in most other places.
Is this the emerging ivory tower of Google developers? While I'm happy for the guy, most of the blog sounds like "look at me, I'm developing under near-ideal conditions, why isn't everyone else?"
ClutterMe.com - easiest site creation on the Net. Just click and type.
Google is the darling of The Street, stock's trading at a bazillion a share, we're a Google nation. Of course their managers are all paradigm-shattering super-geniuses, and all the "normal," plodding-along companies will be buying Google-branded Kool-Aid and foosball tables in the hopes some of the magic drips off.
Check back in five years, there's some kind of upheaval in Middle-Central-Lower Slobovia, the Market tanks, Sergey's enmeshed in a sex scandal with an Israeli weight-lifter, shareholders revolt, The Next Big Thing hits (something with a Google-opposite development philosophy, perhaps involving chains and semi-regular beatings), and all the wonks who are praising Gooogle's brilliant policies today are writing best-selling books with titles like "What Were They Thinking?" and "...Damn Hippies!"
Been there. We called it "The Nineties."
It depends on what you mean by meeting?
No it doesn't, you fucktart.
that is a valid point. I guess I think of a meeting as 3+ people, typically half an hour or longer, formally planned and organized.
34486853790
Connection too slow for X forwarding? Try "ssh -CX user@host"
I love Google; but really - these perpetual betas are basically just another form of pre-announcing, IMO.
#DeleteChrome
"And it's true because your actual performance review is almost entirely based on your peer reviews, so it has an indirect financial impact on you."
How is this good? Every place I've ever worked consisted solely of snakes who would cut your throat, flat out lie, cheat and steal if it meant they would get ahead, get promoted, get their project funded, or push the blame.
It's a sorry state but most people aren't honest and there is no correlation between intelligence / ability and being honest in a workplace.
Showing your importance to one or a few managers is one thing; showing that effectively an entire group which ultimately will contain at least one of these types of people is another.
The "utopian-ism" of the above quote from the article seemingly runs contrary to the author's opinions on "methodologies".
Up until maybe a year ago, I had a pretty one-dimensional view of so-called "Agile" programming,
Sounds like he still has a pretty one-dimensional view actually. Yegge often has interesting things to say, I just wish he didn't constantly have to be so bloody arrogant and condenscending about it, for instance:
anything that calls itself a "Methodology" is stupid, on general principle. [...]
And by "stupid", I mean it's "incredibly brilliant marketing targeted at stupid people.
There are some really good refutations of pretty much all his arguments in the blog comments, for instance:
"[..]most of us in our industry are writing sotware for paying customers (who might happen to share an employer with us) who have a "soft real time" idea of the value of the features we build: ie, the value of the features is at a maximum at some time t and declines, perhaps rapidly, after that. These three kinds of development are all quite unlike this."
[...]
"I don't doubt that the Google approach is very enjoyable for the developers, and is a good fit for Google's business model--but there are a lot of other businesses wokring in other business models. For many (not all) of them, agile with any size of "A" can be a big step up from what they've got."
Being bitter is drinking poison and hoping someone else will die
Developers can switch teams and/or projects any time they want, no questions asked; just say the word and the movers will show up the next day to put you in your new office with your new team.
Having developers on a merry-go-round between projects is probably a good reason why their products never make it past the Beta stage (which is terrible).
There aren't very many meetings. I'd say an average developer attends perhaps 3 meetings a week.
One meeting a week should be sufficient. Three meetings a week spells inefficiency and poor process.
there aren't Gantt charts or date-task-owner spreadsheets or any other visible project-management artifacts in evidence, not that I've ever seen.
Okay, so now we're advocating against the use of project management techniques? Let's piss in the wind and hope it lands where we intended?
even during the relatively rare crunch periods, people still go get lunch and dinner, which are (famously) always free and tasty, and they don't work insane hours unless they want to.
There is tasty food everywhere in this world. Why does it need to be constantly emphasized that Google has tasty food? Google is a software company, not a restaurant. And secondly, the author makes it seem that in crunch periods, companies other than Google do not allow their employees to have lunch and dinner. I somehow suspect (legally, personally, ethically, etc.) that is not the case. Are the employees of EA starving during their crunch periods? :)
The point here is that Agile Development is a good model if its used properly. Using Google as an example to demonstrate how Agile is good, however, is a mistake. Subscribing to Google's use of Agile is a recipe for disaster.
For he today that sheds his blood with me shall be my brother.
Hubris is followed by what exactly? I know it begins with an N.
No doubt some consultant will turn the Google model into a salable series of talks and books. Your management will crow about how they are going to adopt the Googleway, where all employees are happy and productive. What could go wrong?
But the PHBs will cherry-pick those aspects of Google's business that suits their preconceived comforts. Remember when we were all supposed to be like the Japanese? Show up for work, sing the company song, use just in time, statistical process control and all the other stuff? Yea, we were just like the Japanese, except for that pesky lifetime employment understanding. We'll just leave that one out - it really isn't important.
If Slashdot were chemistry it would look like this:Cadaverine
This sort of relaxed attitude and being different from all the other software companies sounds very much like Apple or Microsoft in the early 1980s. I wonder if google will still be like this in 10 or 20 years time?
- Google is a company whose success is almost entirely based on innovation
- Innovation comes from intelligent, well-motivated people
- The best way to motivate intelligent people to innovate is to give them total freedom (rewards are just to give them a direction, NOT to motivate them - they are motivated because they love what they do. Try offering rewards for something they don't want to do, and see what happens...)
- Most companies (even software companies) make the majority of their money through churning out the goods, not innovating - Most companies do not have the funds or the original culture to even contemplate the above working practices
- It would be lovely to work for Google.
Personally I'm really glad this article got posted - it's not telling everyone how everyone should work, but it does offer insight into how Google works, and that's valuable insight indeed as long as it's not taken out of context.
Meta will eat itself
Google is not a software development firm, but an ad sales firm (check their 10-K if you have any doubts). It uses software to attract viewers in the same way television networks use programming and magazines use articles. Under this model, it makes sense to give developers a large amount of freedom to develop whatever they want. The final type/quality/status of the software doesn't matter nearly as much as the fact that there are new features appearing on the site from time to time to attract new viewers..er, users... and keep old users. Most of the applications probably won't amount to much, but just like with any media company, you only need one or two big hits a season to keep people coming back.
Google develops a large amount of its content in house in much the same way old movie studios developed all their films in house. For Google, the talent is not actors and directors but developers. Movie studios learned that you treat the talent well to keep them around and Google has taken that lesson to heart. Developers tend to want complete freedom to work on what they want with no deadlines and giving them this is the easiest way to keep them happy. Call it 'good agile development' or whatever else you want, it's really just keeping the talent happy in the hopes that they'll keep developing content to attract users.
Unfortunately, software companies that rely on software or service sales for revenue cannot take this extreme approach to agile development. They need to deliver software on occasion or someone else will replace them in the marketplace. Agile development is still the best way to go, but unbounded development only works if software isn't your primary source of revenue.
-Chris
It sounds more like "have as many / few meetings as it takes to do the job."
At different points in a project, you need more meetings than at other points (and different types of meetings).
And yes, I'm jealous, darnit! I've been in places where there is a meeting every day, and nothing gets done (except preparing for meetings), and where there are NO meetings every week, and nothing (at least nothing on target) gets done. Both suck.
so apparently you don't have to work for Google to come to the same conclusions as this guy. Agile with the capital 'A' (or XP) is a religious movement, it adheres to a sweat shop mentality because it forces release dates (release cycles,) while pairing programmers and thus forcing everyone who is coding to kill their wrists (does that really leave that much room for thought?) The story cards are a ridiculous substitute for a proper design, and projects that succeed do so because someone takes their responsibility seriously (and in case of Google it helps immensly that everyone takes their responsibility seriously, regardless of what the insentives are.)
Of-course not everyone can afford the same culture as Google, simply because not everyone has access to the same funds.
You can't handle the truth.
It's clear, good people in good mood, that's the best way to give incentives to your peers. second...
that is, killing the pressure in a smart way, and third....
that is, the respect of your peers is a KEY here, as a consequence that keeps things calm....
Are you serious? That's a busy week for me. Usually only during intense design sessions. Or training. We usually have only one formal meeting a week and then chat online or pop into someone's office as need be. Far cry from when I was working at a fortune 500 company and we 4-5 a week, chewing up up to 10+ hours a week. The same was true at a Uni I worked at.
Google's getting too big.
putting the 'B' in LGBTQ+
Ummm, okay, hm.
I'M NOT JEALOUS.
Better?
Moron.
LMAO, vword: "compute"
Mod parent up.! +1 Insightful
Back in the peak of the Bubble, I worked as a systems engineer for a software development shop. Of course, being a software startup during that period meant having $1000 Aeron chairs for everyone and pool tournaments ever so often, to say nothing of free Friday catered lunches. Then, when the money started to run dry and a few airliners crashed into a couple of buildings, the perks went away and so did my job.
What is interesting, however, is the way similar "perks" are perceived as rewards at Google. If you feel that perks are rightfully yours and must not be sacrificed even in the face of company financial difficulties (feeling "entitled"), then it's hard to make your brain justify working hard for your keep (or harder during particularly difficult times). Whereas if you are working on something for which you have genuine motivations AND have rewards to aim for, then the management has two aces in their deck: An employee's internal motivation (which can be invaluable), and external positive reinforcements. These two characteristics contribute directly to the health of the company both in its balance sheets and in its corporate culture, and that is A Good Thing.
Looking back, it wasn't the exuberance of the Bubble that destroyed it, because the way Google works can seem to be quite exuberant to some code monkey at Chrysler. It was the way that management could not decide (a) how to set business goals, and (b) how to manage its employees. When management forgets how to manage and employees forget how to work, you have a problem on your hands (see the sad saga that was Daikatana).
What stands out in TFA is just how high and mighty the author is flying. Reading through the rather wordy post it sounds like Google is basically operated like a university computer lab only with a lot more incentives - BFD - and not surprising since that is the environment where the founders came from.
I wonder if this guys tone reflects the prevalent culture at Google, because what impresses me most about Google is just how vulnerable they are.
They have a single source of revenue: Ad Words. If Joe User starts ignoring ad words (quick: what's the last banner ad you clicked on?), the party is over.
They have heavily armed competitors (M$). I always wonder what it was like at Netscape when they first heard the footsteps and realized MS was closing in on them...that maybe Navigator could be beaten...
For all the publicity surrounding things like google maps, gmail - none of these products seem to earn very much money and are hardly killer apps.
That's nothing. At my company, we never have any meetings at all, nor any plans. And staff can take holidays whenever they want and work on whatever they want!
We're not making any money yet, but it's only a matter of time! (Fingers crossed!)
I think Google's either very lucky or very clever not to have genuine externally created deadlines to work to. The number one source of genuine deadlines in my career has been the sunsetting of legacy services: "Our network provider is pulling their SNA service in 18 months. We need to provide an alternative to the 40,000 customers who reach our service using SNA, and migrate them by that date, or pay AT&T $x million dollars to extend the service."
Of course, you can forestall this kind of issue by smelling the coffee and moving your customers off dying platforms before you're forced to -- but it's not glamourous work by any means, so surely it's not going to attract engineers in a company where you can jump onto any project you like on a whim.
They are picky about who they hire. I've heard the interview process can be as grueling as exam days.
I wonder if they are quick to pull the rug out from people who don't cut it.
Their hiring staff must be pretty perceptive.
Developers can switch teams and/or projects any time they want, no questions asked; just say the word and the movers will show up the next day to put you in your new office with your new team.
Speaking as someone who has known a few Google employees, I don't believe this at all. Certainly Google is more accomodating than traditional firms, but I knew someone unhappy about his assignment who had to wait for quite a while (at least several months, not sure the exact length) before he could get it changed. It's a lot easier to promise something like this than to deliver it when you're actually developing something -- I think some of the "Aha! That's why Google never gets anything done!" posts are misplaced, since in practice, developers aren't (mostly) on a "merry-go-round." They're just not quite as static as a traditional company.
I am the man with no sig!
Such a model can't succeed without the right type of people: intelligent workers who take pride in the quality of their work and who are self-motivated. And I don't care what company we're talking about -- you're never going to bat anywhere near 1.000 when it comes to hiring people with all three traits. I contend (with no supporting evidence whatsoever, but Yegge doesn't offer much other than anecdotal evidence either) that Yegge is wearing rose-colored glasses and there's either a good segment of the workforce at Google that still needs to be micro-managed or Google is quietly firing 10% of their staff every quarter to keep trimming out the slackers.
Is there any Google app that is truly profitable other than Google Search and Adds?
As you mentioned, with their huge amount of capital, they can afford highly in-efficient project management. I pity the fool who tries to introduce this management style into a smaller organization with budgetary concerns and uncontrollable deadlines. Not that I wouldn't mind working in their environment one bit. Either as a coder, or as a PM.
-Rick
"Most people in the U.S. wouldn't know they live in a tyrannical state if it walked up and grabbed their junk." - MyFirs
Incidentally, Google is a polite company, so there's no yelling, nor wailing and gnashing of teeth, nor escalation and finger-pointing, nor any of the artifacts produced at companies where senior management yells a lot. Hobbes tells us that organizations reflect their leaders; we all know that. The folks up top at Google are polite, hence so is everyone else.
They don't have bald men, yelling and throwing chairs around ??? LOL
I'll take issue with the "you can't rush good cooking" bullet.
Many dishes are best when done quickly and often at high heat. Think of fajitas, calamari, tuna steaks, shrimp, stir-fry, and the list goes on. Likewise, leave your steak, burgers, chicken, veggies on the grill for 3 hours (hey, you can't rush good cooking right?) and you'll have charcoal.
There is a balance in all things. Cooking and software are no exceptions.
Google has a great setup for the business they're in. The company I'm at doesn't have the luxury of doing whatever we please. Our customers depend on us to deliver certain things on time. We like to think that we do have a core group who get to work on some "fun stuff" that doesn't have a fixed timeline (though we like to at least know what year we might get it out). I think Google can do things they way they are due to a LOT of cash on hand combined with the fact that they're really trying to find cool ways to attract people to their ads and attract ad buyers to their cool products.
Meetings are never forced on you in OS Projects, people just have an IRC discussion or something..
You choose which OS project to work on yourself don't you?
"..."
Often I have, and no doubt you have also, heard the phrase "managing programmers/software engineers is like herding cats".
My observation has been, if you are trying to herd cats you are using the wrong management technique.
You herd cattle, not cats.
With cats you put them in the general area of mice and let them do what they are good at. Cattle you herd to the slaughter house.
Most software projects fail due to poor management, then managers don't understand it is not an industrial activity. Most are still managing from that perspective. Software is more like R&D and in reading the description of Google it sounds like they have built a good R&D environment.
I havent't tried XP, but if it gets us away from the rigid factory model of development, more power to it.
putting the 'B' in LGBTQ+
Consider the government as an extreme counter-example.
The word TFA fails to use: leadership.
Someone who knew something of the subject, http://en.wikipedia.org/wiki/James_Stockdale described five roles for a leader:
- moralist
- jurist
- philosopher
- steward
- teacher
Note the lack of "programs, process, policy, procedure, and paperwork" in the list.While Google may let people shift teams at will, I would be unsurprised to discover that shifts are infrequent.
Furthermore, by the time people start to abuse the culture, I would be unsurprised to discover that the culture ushes them to the door.
Have any of the major headz they've hired actually departed the big G?
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
- anything that calls itself a "Methodology" is stupid, on general principle.
- anything that does diagrams with hand-wavy math is stupid, on general principle.
And by "stupid", I mean it's "incredibly brilliant marketing targeted at stupid people."
The first one sounds like a sophomore engineering student rant, or better someone that's a self-taught engineer wondering why he wasn't choosen to design the next big bridge.
I'm not sure where he was going with that other one. Does he think that only those with advanced math degrees should ever write down an equation? I'm not sure what's so bad about writing "we can serve up X people on Y machines, in order to serve up Z we should shoot for Q machines"
He writes like he's never been at a company other than google.
I'd consented to try Agile last Christmas ("hey, it can't hurt"), and wound up arguing with a teammate over exactly what metadata is allowed on index cards before giving up in disgust
Ah I get it, you're a dick.
or a company that has nearly infinite profitability and can dangle vast financial rewards in front of the nose of its entire staff.
now, simplify your process:
- "portfolio management" (ie, determining which projects move forward and which get cancelled) can be self-managing through the developers own self-interests
- developer productivity is handled through developer self-interest
- project scheduling is handled through developer self-interest
man, there's all kinds of benefits to this: just like the Mythical Man Month showed - the cost of management/liaison/coordination overhead is a killer. And so is the cost of mediocre or poor developers. So, if you have a large staff of self-directed, self-motivated and expert developers motivated by huge financial rewards it will *really* pay off.
All you need to do is to start with the spherical cow, er infinitely profitable company, and some insightful management. And the rest is a cakewalk.
The last job I quit was meetings-happy. They were a small engineering shop, maybe a dozen people. And they all manufactured and programmed a very simple line of widgets. Maybe a dozen models, two cpus. One of them was a 8051 just to let you know how simple these widgets are. There were 3 code bases common to the widgets. Really - no big deal.
So...how do you keep that many people busy on such simple crap? Filler Meetings.
We would have daily meetings. And progress meetings. And status meetings! The status meetings were the worst. Nevermind the fact that you could do 95% of that through email - we would be summoned all to a big room. And all 12 guys would have to tell the boss what they're working on, how long it would take, where they were at, and so on. So you'd sit in a meeting for 2 hours just to deliver your 10 minutes worth.
Each meeting ended with this one managers arguing with the head of engineering for about a half an hour, as a bonus. It was like watching a married couple argue. We all refered to the argument as EOM, "End of Meeting", the final stage in the meeting handshake protocol.
Meetings, meetings, meetings. Made me NUTS. It always reminded me of this poster, working there.
Honestly, I've had days there where I've spent entire day in meetings. Even though we had a meeting the day before. All over a 8051 driven widget.
Thank The Powers That Be that I no longer work there.
Weaselmancer
rediculous.
We have a scheduled meeting every single day, at the same time. Lasts 10-15 minutes most days-- it's longer on Tuesdays. It's an essential part of our process, which is a sort of modified Scrum, and it works extremely well.
even during the relatively rare crunch periods, people still go get lunch and dinner, which are (famously) always free and tasty, and they don't work insane hours unless they want to.
I can't say for certain since I don't work there, but I supect that everyone is expected to "want to" work insane hours. Just like how NCAA athletes aren't "required" to come to "voluntary" workouts -- only if they actually want playing time! I know folks who interviewed at Google and decided not to accept the job because it seemed to them they would certainly have to work insane hours -- something they didn't want to do because they have a family, etc.
I wonder how Google is getting this to work while Apple couldn't in the 1987-1997 time frame. Perhaps it just works better for internet apps than it does for OS development.
heh, i need a new job...
Believe in technology, but back up your hard drive - Leo Laporte - ZDTV
Oh, and the standup meetings... don't they remind you of the daily prayers required by many (all?) religions?
:)
But I am an atheist and don't believe in prayers.
(and sorry for the spelling errors from the previous post, I don't really have that many incentives to be immensely grammatical here
You can't handle the truth.
Google works for itself The company I work for, works for a client. client->whip(project_managers) project_managers->whip(us) us->whip(coffee_machine)
Can I take your place? I work here at Oracle, and it sucks. I'm not sure what your friends told you, but it ain't good working here. Let's swap positions. Meet me at the Starbucks at the corner, and we can exchange contact information...
Except, of course, Google pays money.
Having taken the time to read through it, I was expecting to be informed about what aspects of agile development actually work. What I actually got out of it is "Agile Sux - Google Rox!". There's more details about Google than that, and it's very informative about their environment, but I saw absolutely nothing that would suggest that there's a "good agile" out there, because nothing that the author described has anything with the cannonical agile methodologies. Maybe he can call it Agile from the perspective of "This is how Agile would have been implemented in the Positive Mirror Universe from Episode 27 of All Programmers Live In Hell", but I drew nothing from it that I could use in a less extreme business environment. In fact, I'd say that nobody below the level of CTO could possibly make use of that information.
Wake up - the future is arriving faster than you think.
It's really no surprise that "Release it when it works" works better than "release it by ____ and we'll patch it later." Patches were originally intended to update the program with new features or to make it compatabile with no technology, not to fix things that should have been ironed out during development. Most software companied have just become lazy and decided they want more money faster even if their product sucks.
Is it just me or is it not going to upgrade to Vista in here?
Without having read the story i read the headline as Google Agile. Then when i opened up the story i was a bit surprised. Feel free to offtopic me to the pitts of hell. If anyone has any messages for the HP execs let me know.
I'd be curious to hear about what the entire hiring process entailed. Interestingly, I thought 10% was ridiculously low as it is. I'd guess that most traditional organizations might have up to half their staff being unmotivated and/or untalented. Besides, one's level of motivation in life does not stay the same. Just because you interviewed well one year ago, it doesn't mean that you're going to still be a bubbly source of inspiration when you've had a divorce and your close-friend dies in a freak accident.
What have these employees done to make Google profitable? Very little so far. Google is profitable only because of its original search advertising, which it had before hiring most of these employees. These same employees will be crying when they are laid off and have to work in the real world.
I think "planned" is the key word there. Our whole team has a standup meeting three times a week for about 15 minutes. That's a meeting. When we start on a major piece of work, three or four folks will have a design meeting for 30 minutes to a couple hours.
When people are working on something and encounter a snag or quandry, three or four people get together and brainstorm solutions. This is spur of the moment and informal, so it doesn't really feel like a meeting, just a discussion.
Ceci n'est pas une signature.
Yah that was my opinion too, the best coding I've done has been when I wasn't interrupted for stupid reasons for >5-6 days at a stretch.
3 Meetings a week is highly excessive, although I suspect its much lower than some companies like MS.
Shadus
Agile development works fine, IF you have knowledgeable people, people who can communicate with one another, and IF the management also gets that Agile is not like it was done 30 years ago. What you take into the cycles is up to the developers. Better take too little than too much.
Agile development DOES not work if you have bunch of cheap people who have no experience or people who just don't give a fuck.
Google's main business is surely very profitable, but how many of the little, random-idea things are making money for them? How many of their services don't carry that all-important advertising? What's underwriting the various accumulation/caching/republishing services to fight off the inevitable lawsuits when they step too far over the line? The biggest difference between a lot of Google's offerings and a lot of failing start-ups is that Google has a huge reserve bank account to back-up the non-profitable things.
Google today is acting like a cross between a VC firm and an advertising agency for its own brand. Perhaps this is a shrewd management decision, on the basis that the amount of money they make from the one idea that comes good covers the rest (VC strategy) or the increased profile they gain from the non-profit-making services boosts their revenue from the mainstream offerings (ad agency strategy). Then again, perhaps it's just the same kind of wishful thinking that leads many a start-up with a great idea but no business model to fail. Time will tell.
In any case, one thing that certainly is true is that the vast majority of software companies couldn't work the way Google do, because if other companies were doing the same thing at the same sort of level, then Google's approach wouldn't work.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I interviewed for a position at Google once. I can let my kids know this. It was an interesting experience. The interview seemed about as chaotic as their work format is described above. The interviewer was all over the place and there was very little structure. Needless to say, I did not get the job, but is was an interesting experience. http://www.adbloggers.com/
Even if you found and fixed every bug (haha), feature requests will continue to come in as people use the software. As soon as bugs/feature request quit coming in most software is essientially dead b/c that means people have quit using it.
l #texbk
Yeah, because no one uses TeX anymore.
"If you do succeed in finding a previously undiscovered bug in the programs for either TeX or METAFONT, I shall gladly pay you a reward of $327.68. Corrections to errors in The TeXbook or The METAFONTbook are worth $2.56, as in all my other books."
http://www-cs-faculty.stanford.edu/~uno/abcde.htm
Q: What did the comedian say to the crowd?
A: If I knew, this joke would be funny.
The article went on so many tangents, it made my head spin. If someone is going to link to an article on slashdot, make it a clear, concise, and well written one, not the junk piece of hackery linked to in this article. My Comp Sci teacher used to do what she called "extreme programming" where two people worked on one machine on one project. It sucked, because when you have an idea, you can't try it just to see if it works without inconviencing the other person. It's much simpler to work seperately, then colaberate later on, when both people have some good ideas.
Reading that article is like having a mini vacation, where after returning, your perspective is positively adjusted. My favourite quote was this paragraph.
"Unfortunately, a work queue doesn't make for a good marketing platform for seminars and conferences. It's not glamorous. It sounds a lot like a pile of work, because that's exactly what it is."
It is nice just know there is the possibility of a more efficient model, than the anti-productive meetings that continuously crop up at the end of projects (what features can we drop to meet the schedule, how many resources can we steal from other groups, can we live with releasing at this crazy high defect rate, etc. etc.) It seems highly desirable to work towards a model that actually promotes "real" work.
Hopefully this article will plant some seeds of thought that will start permiating other organizations.
Here, Peter Norvig (director of research) explains how they keep workforce quality high. It refers to Garrison Keillor's Lake Wobegon, "where all the women are strong, all the men are good-looking, and all the children are above average." The Google hiring strategy is to hire children that are above average.
- lake-wobegon-strategy.html
http://googleresearch.blogspot.com/2006/03/hiring
Q: What did the comedian say to the crowd?
A: If I knew, this joke would be funny.
Yes, too much of meetings is a waste of time. This is what most of the developers expect. Most of the meetings end up without any conclusion or schedule another meeting. Developers must have freedom and flexibility to produce results. Google has proven that over and over again!.
-Rafiq
http://www.ajaxtoday.com/
This is the big difference. The users of most of Google's software are not their customers. The advertisers are their customers. The other big difference is the delivery mechanism - services through the web. These two things create special circumstances for software development (not product development, Google's product is not software) that do not exist in most software development organizations. None of the users has to be sold to. There is no delivery, installation, configuration, setup. No sales/support cycle at all. No customers who will move to another product if you don't get that release out in a reasonable time frame. No marketing demos that need to be in place to sell customers. No commitment to any kind of schedule at all in fact. In addition even if a bunch of Google's "products" (gmail, maps, etc.) start to suck people will probably still use Google search and it is advertising on Google search that makes them all that money. So you simply can't compare Google to any kind of software development company because it isn't.
Google sounds like a stud-farm for PhD's. They can freely roam the pasture, and screw any project that takes their fancy.
All serious software should be designed before it is built. This means all hardware, peripheral software, UML design, ER design, and algorithm development should be documented and proven by a team before any actual code is written. Of course, all of this takes time.
Many professionals just do not get this concept. They have trouble grasping the fact that time must elapse before seeing anything.
From what I have heard and read, Google seems to have this idea down pat.
Google also allows their developers to devote 20% of their time toward applications of their own creative choice. This is how Froogle and Google Base came to fruition.
The Googleplex seems like a great development environment.
Hey - if Microsoft read this story, they might stop making product that stink.
Good thing for us they're busy panicing about Vista.
Stop the brainwash
This management style only works if you have very good self-motivated developers. With such high standards and ability to attract good people I can see how they can pull it off. But don't think this will work in your average IT shop.
Hi! I work at Google, so for obvious reasons I'm posting as AC.
> * Developers can switch teams and/or projects any time they want, no questions asked; just say the word and the movers will show up the next day to put you in your new office with your new team.
This is simply not true. I know a couple of guys that tried to switch teams/projects and it didn't work for them. Asking their superiors or superiors' superiors didn't work either.
> * There aren't very many meetings. I'd say an average developer attends perhaps 3 meetings a week.
3 meetings is *a lot* for me. Sometimes it's even worse.
> * Google has a philosophy of not ever telling developers what to work on, and they take it pretty seriously.
No, Google doesn't tell you, your manager does.
I mean Google is great and all, but it became a huge corporation. It will start to have, or already has, all the same problems other huge corpos have. I'll wait a bit more until I am fully vested, and then hastala vista Google.
P.S. They say that 20% is 20% of 120%...
Several posters have mentioned that most companies can't afford Google's extravagance. Though this may be true, why can't most companies afford at least something?
Programmers are money generators. But they're not like machines, they're quite temperamental. As such programmer productivity is a huge variable in the successful generation of money. Not putting money aside to encourage good development is akin to failing to oil the machine. It's worse actually, good programmers are magnitudes more productive than bad ones. Whereas even well-maintained egines won't deliver 4 times the mileage and performance.
Even my small consulting firm does something. They had special x-mas gifts for a couple of outstanding performers (I was one) and they cut me a recruitment cheque when they hired one of the resumes I brought to them. The cheque wasn't great ($500) and the gift wasn't huge (~$150), but at least they tried. They also make sure to take us out for lunch or beer and food every couple of months. We're drinking domestic beer and eating regular wings (not Google food), but at least we're being treated well.
All of these little things do add up. I wish they had more, I wish we had better PCs and some work time allotted to studying (rather than do it on your own). I wish we had incentive bonuses for renewals on lucrative contracts. But these are wishes, not issues.
Failing to pay your generators and keep them happy is a critical flaw. My bosses are (ex-)programmers and they know this. They can't afford to be Google, but they can afford even less to be cheap.
(Slashdot has to be the worst discussion forum in the world for anything resembling a serious purpose -- quick and dirty always drowns out everything else).
No matter how much incentive you get, no matter how much recognition you get, no matter how much freedom you have, the stuff you do will be a property of Google at the end of the day. Why would you want to do that? It's much better to work for your own startup. You can work on what you want to work on 100% of your time, not 20%. You can get every cent the stuff generates, not what Google (however generously) allows you to have.
Question: how would you evaluate two methodologies if you really wanted to? What would you need?
Answer: conduct a social science experiment using teams of volunteers. Undergraduate CS majors might do in a pinch.
Question: who is going to do this experiment? Computer Science professors? Ha! CS profs want to scribble equations, Design Languages, maybe, once in a great while, they'll be willing to write a program or two... but conduct a social science experiment? Feh, that's some other department, isn't?
So instead we're stuck with anecdotes, religious fanatics, and hucksters holding seminars...
Well Duh. So don't try to get the data from corporate sources.The comparison to "fad diets" is completly unfair: there are indeed academic sources of data on the performance of diets, it just takes awhile for the data to accumulate, but accumulate it does. Programming methodologies are condemned to remaining in the realm of pseudo-science for what seems like an eternity.
"Developers can switch teams and/or projects any time they want, no questions asked; just say the word and the movers will show up the next day to put you in your new office with your new team." Now how in gods name does that work out fine?
Select SigText from Signatures where Len(SigText) > 120 Order By Len(SigText) desc
Wow. Is it just me, or does anybody else get the impression that this guy is too smart to play well with others? I'm sure he does great things all on his own. For the other 90% of us mere mortals, Agile (yes, with a big "A") puts us in an environment where we can contribute, learn, and grow while producing business value. Even up against deadlines. Agile is a way to deal with the toxic cocktail of business chaos and technology potential. It's not a silver bullet - it's wolfsbane, garlic, holy water, a steak, a torch, some leather armor and a few other things to fend off the monsters of the Death March. You need to take the items (practices) that work for you. And to the author from TFA, the cards are a direction of what you need to do. Not gospel. If your project broke down over what could or could not be put on an index card, your problems were not with Agile. Agile was just exposing that you did indeed have serious problems (and Agile is *GREAT* for doing that!).
Even the much maligned (indirectly) Kent Beck went back and wrote version 2 and relaxed from the strict rosary of the 4 values and the 12 practices to a more organic view of values (still all required, up to 5 with "Respect" added) and practices (try 'em, but use what you need). The spirit of Agile is more about "Listening, Testing, Coding, Designing. That's all there is to software. Anyone who tells you different is selling something.". Keep in mind, that phrase gets pulled like a gun when somebody tries to build up big seminars. I'm not saying people aren't making money off the Agile name, but it's flat out wrong to think it's a snake-oil sales system. Anyone with an Agile community around them can get in touch and talk face to face with practicioners (we're a friendly buch, honest;). All it will cost is the time, the gas, and perhaps a cup of coffee.
Google may be small 'a' agile, but it seems it can only afford to do so because it has a cash cow and technologists at the helm. The grad school/hippy commune the author describes can't exist in the smog of capitalism unless it can be hidden away somwhere because some moron with a bigger paychack is always saying "at the end of the day, we gotta do somethin'". In the rest of the corporate world Agile tools and practices not only gives the dev team a chance of "doin' somethin'".
*** Sigs are a stupid waste of bandwidth.
Give anyone 12B a year and they can make any development methodology work, especially one without deadlines. Yeah, this is pure genious. Why didn't I think of it? Praise Google. Praise Google. We worship thee, all knowing Google.
they don't need to be told what to work on, they just steal ideas from everwhere else. has google created (not just improved) anything REALLY new besides adsense?
they're a one trick pony i don't care to ride.
In other news, Google is announcing their newest product, Google Porn Search (beta).
The Gospel according to lolcat
http://www.stinkymeat.net/
That steak might work pretty good after a week;)
*** Sigs are a stupid waste of bandwidth.
At long last—an environment where Agile can actually work. A place where nobody cares what you produce, how much it costs, or how long it takes.
Agile 1, Universe 99.
I'm a Programmer. That's one level above Software Engineer and one level below Engineer.
I've been through the process. The only one that compares to it in stringency is Microsoft's as of a decade and a half ago.
A friend of mine told me that when he sat in new engineer orientation at Google (with seventy other new hires), the first thing the first speaker said was "OK, everybody, welcome to Google. Everyone who's interview process took more than a month, please raise your hand." He says that all but a tiny number of hands went up. Only one person had had a process which only required a single interview. (I want to meet *that* one -- does he (or she) walk on water or something?)
Why doesn't the blog author just say, "Google has found the optimal development strategy for their market niche and guess what it is? Flexibility and profit sharing for the employees!" Big suprise. There was absolutely no good reason for him to wail on his straw man impression of agile. I work for a proud agile java development shop, Asynchrony Solutions, in St. Louis. Agile works amazingly well for our market niche where we are held financially accountable to produce deliverables for our customers. The "agileness" just keeps all the developers and the customers on the same page throughout the entire software development cycle.
This blog author conveniently chose to not mention many of the most rewarding concepts in agile development. Our agile process includes daily stand-up meetings. Around 10 am when just about everyone is accounted for, each team member standing in a circle takes a turn summarizing what they accomplished yesterday, and what they plan to accomplish today. This serves two major purposes: people must articulate their goals thus clarifying the big picture for everybody, and each person is held accountable by their peers for how their time is spent. You wouldn't believe how this motivates people to make themselves useful so that they don't have to explain why they have nothing to say to the group at the standup.
Shame on this blog author for not even going into how agile development works hand in hand with test-driven development. Well written unit tests coded at the same time as the software itself in atomic increments is the most amazing paradigm shift in software development for decades. I feel liberated when I can fearlessly refactor code that has been written months ago by different people and integrated everywhere in the project because they have properly maintained a test suite. Contrast this with a project that has no unit tests. You have to tip-toe around every line of code, and as the project grows, it becomes exponentially harder to make even the simplest refactor. Peer programming and the agile discipline enforce test-driven development in the real world.
This article made me sad because a lot of damage was done. The blog author is riding on the implied credibility from his position at google, but he is not a professional agile developer. Although the author was right to be upset about shameless vendors who don't care if what they are selling is a mismatch for their customers, I am in awe of how everyone at my company rallies around the agile flag because we are proud that we've got a development process that works for us and our clients, and the discipline to deliver great software. It may not be as visible or high profile as google, but I work with a staff that is just as driven and talented. I hope we don't miss out on any future business because of misconceptions born from this slanderous blog article.
My only regret... is that I have... bonitis..
That must've been Vint. Or Guido. It's said that the two of them, with their powers combined, can bend space-time and boil lead with their minds.
"unbounded development only works if software isn't your primary source of revenue."
true. however, that is the more general case.
Most programmers are not google material and do not work in places which sell software. Their clients are usually internal. If you can get your client to co-operate, or have the client in charge, and they understand well, and give them short term incremental features, it can work. The problem with software development is the sheer size of the 'unknown' portion in any estimate. When you get too many requirements, too many stake holders, too many commitments, and too many people watching, it is a recipe for 'challenges' and makes life really hard for the developers. There is a fundamental dichotomy: If you need funding, you have to sell, if you sell, you need to offer people something they want. Lesson: Try to get by with very little funding. I know this sounds trite, but it argues for component re-use, gradual accretion of a toolset, less development, and more thought about using existing components.
My preference is to is to undersell, underpromise, be modest and flexible about delivery dates, and use the absolute minimum amount of resources. The less resources being spent on a particular deliverable, the more management will leave you alone. You have your own long term strategy in mind, and cherry pick deliverables that you can meet at each step along the way... At any point you can point to recent successes, and planned next steps.
The overall plan, being years long, does not need to be shared widely because it is vapour anyways, will probably never happen, and if it does happen will be changed beyond all recognition. It is just a framework on which to hang current work. Best not to let people know that it even exists. If you start sharing it, then folks will say... well I want X but that's way down the list, and you end up changing the plan to meet deliverables, rather than picking deliverables that you can meet along the plan.
It really helps to have a small budget/number of stake holders, a clear understanding of the problem to be solved overall and at each step, which leads naturally to aggressively limiting scope, and incremental delivery.
Developers can switch teams and/or projects any time they want, no questions asked; just say the word and the movers will show up the next day to put you in your new office with your new team. I don' belive it. There aren't very many meetings. I'd say an average developer attends perhaps 3 meetings a week. That's too many. Google has a philosophy of not ever telling developers what to work on I don't believe it. Rather, I believe this entire story is a lame hoax. How about some fact-checking on this?
I'm in a simular boat. My company is in a niche market that is best served by Agile methods. In terms of development, there's no way we could produce as well and as fast without pair-programming and TDD. While the damage done from the article concerns me as well, there's a small part of me that hopes it's the competition that reads and believes it. "No, no.", I might say, "That blogger is right. Agile is full of problems. You should go back to waterfall. Or better yet. Here's a boxed copy of Microsoft Project you can have. Also, have you tried using RUP and encorporating _ALL_ the tools IBM has to sell you for it? " *DEVILISH GRIN*
It seems the problem is that you can't force a paradigm shift (I shudder and ask for forgivness for using that buzz word, but it is the most appropriate). People are either open enough to _THINK_ and _LOOK_ for themselves, or they aren't. And the personalities drawn to building software somehow historically seem to be the most shift challenged on top of it!
*** Sigs are a stupid waste of bandwidth.
Google is deep in the hype phase and has a ton of cash. The danger for a company in this position is that you can do all kinds of goofy things and you can talk yourself into believing that just about anything is the cause for your success even though there's no proof of a connection.
When reality eventually sets in and Google has to work to sustain itself, these "dream" practices will disappear. To Google employees I say: enjoy the party while you can, the real world is just around the bend.
"In the typical business world, it is well stated fact that any individual is 100% replaceable by someone who will probably do the same thing you did but cheaper."
... cheaper". So it's cheaper workers all the way down.
Taken to its logical conclusion this means that I can eventually hire someone and not pay him anything since "any individual can be replaced by someone
"Brainwashed in what way(s)? I got the impression Google succeeds b/c it has a lot of creative, innovative techies. "
See, it even works outside the company. How do you know that Google employees are so great? Why, because Google whispers it to you subliminally through their hiring stunts.
i only attend 1 meeting per week... :)
So the only company-wide dates I'm ever aware of are the ends of each quarter, because everyone's scrambling to get on that big launch screen and get the applause and gifts and bonuses and team trips and all the other good that comes of launching things with big impact at Google."
I can confirm this after doing a summer internship last year. The way people act inside Google is quite close to a cult. Nothing wrong with that, but I never got to feel totally comfortable in that environment.
meetings-per-week? Meaningless statistic!
What's important here? Being productive? Having respect for your time? Being part of a community?
Meetings should be very few if they serve no purpose, but...
The more helpful they are to everyone attending - the more I like them.
If you don't care about your co-workers, then don't go to meetings unless there's something in it for you.
But I have no patience for people who think that their time is too important to share with their co-workers.
Don't like the meeting? Then fix it. Change it.