Forgot your password?
typodupeerror

Good Agile — Development Without Deadlines 339

Posted by kdawson
from the crushed-in-a-scrum dept.
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.
Yegge also does a fine job of skewering what the author calls "Bad Agile."
This discussion has been archived. No new comments can be posted.

Good Agile — Development Without Deadlines

Comments Filter:
  • 3 meetings a week! (Score:5, Insightful)

    by 91degrees (207121) on Thursday September 28, 2006 @09:01AM (#16227599) Journal
    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
  • by jimstapleton (999106) on Thursday September 28, 2006 @09:04AM (#16227643) Journal
    /\ informative/insightful/underated the parent please.

    In most places I've worked it's been no more than once per two weeks for the prorgrammers. The buisiness side of things has more, but hey, that's what business people are payed for, to sit around and talk while others do the work.

    Ok, the business side fo things does do work, but the programmers shouldn't have to go to meetings like that. Their meetings are more like the occasional team huddle to verify that they are working on the right path - 5 minutes, quick, and to the point
  • by 91degrees (207121) on Thursday September 28, 2006 @09:09AM (#16227713) Journal
    There is a catch. You have to be a genius with god-like programming skills.
  • by Mycroft_514 (701676) on Thursday September 28, 2006 @09:14AM (#16227777) Journal
    Really, I agree with another poster. I average less than 1 per week. We have our regularly scheduled team metting, but that isn't even actually held every week. And we tend to talk more about other people's problems then ours, since we are a DBA/Tech support team.

    Switching teams? Right, and that makes agile development work. Sure. Of course, I have found out that what agile deveolpment REALLY does is push MORE work onto your DBA and tech support teams, in order to "reduce" the work of the development teams. The net tradeoff is a negative sum, as tech support and DBA teams are more expensive then developers.

    Don't tell people what to work on? And exactly how does that finish projects, ever?

  • by 0racle (667029) on Thursday September 28, 2006 @09:14AM (#16227791)
    My guess is there are a lot of team member introductions.
  • Re:GOOG IN MY ASS (Score:3, Insightful)

    by CastrTroy (595695) on Thursday September 28, 2006 @09:18AM (#16227855) Homepage
    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.
  • by Gnostic Ronin (980129) on Thursday September 28, 2006 @09:18AM (#16227867)
    I think part of the reason that other companies choose the "Agile" methods rather than the "Google" method is the problem of the customer. The customer needing a custom application needs it by a certain time or it could become outdated or downright useless. Tax software complient with 2006 tax codes are useless after April 15th, 2007. Or if you're making custom software for manufacturing, you can't leave the client without his software after the plant opens, he'll probably cancel the contract. Virus updates would be another big "can't be late" kind of issue. Waitng a month before you can stop a new virus probably means a cancelled contract, and a lot fewer customers.

    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.

  • Okay, sure (Score:5, Insightful)

    by Z0mb1eman (629653) on Thursday September 28, 2006 @09:20AM (#16227887) Homepage

    - there are managers, sort of, but most of them code at least half-time, making them more like tech leads.

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

    - Google has a philosophy of not ever telling developers what to work on, and they take it pretty seriously.

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

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


    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?"
  • by rtaylor (70602) on Thursday September 28, 2006 @09:24AM (#16227945) Homepage
    They may be including informal design and algorithm meetings in their list. You know, the ones that you usually start by yelling over the cubical wall or out into the hallway which end up on a whiteboard somewhere with a small group.
  • by Xzzy (111297) <sether@tru7hMONET.org minus painter> on Thursday September 28, 2006 @09:25AM (#16227971) Homepage
    Don't tell people what to work on? And exactly how does that finish projects, ever?

    Considering how often Google puts up new features on their site, apparently it works pretty good for them.

    Regarding the number of meetings, I only have one formal meeting a week, but can spend several hours a week with a couple other guys talking over the specifics of whatever we're working on. Could be considered "meetings", even though they don't involve sitting around a table and going through an agenda.
  • by 93 Escort Wagon (326346) on Thursday September 28, 2006 @09:28AM (#16228001)
    I love Google; but really - these perpetual betas are basically just another form of pre-announcing, IMO.
  • Test (Score:3, Insightful)

    by AutopsyReport (856852) on Thursday September 28, 2006 @09:31AM (#16228049)
    Let's take a leap off the "it's amazing to work at Google" mentality that has been championed by more people that do not work at Google than those who do. Most of the points raised by the author appear amazing from a developer's perspective, but not from a business view.


    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.

  • The PHB response? (Score:5, Insightful)

    by paiute (550198) on Thursday September 28, 2006 @09:34AM (#16228095)
    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.
  • Don't criticise (Score:5, Insightful)

    by tygerstripes (832644) on Thursday September 28, 2006 @09:35AM (#16228111)
    It's easy to jump on this guy for making us all feel shit about our inevitable working conditions (you think you've got it bad? Try working in local government...). However, really what he's doing is putting in clear, simple terms some concepts that we all understand deep down, to whit:


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

  • by rockmuelle (575982) on Thursday September 28, 2006 @09:37AM (#16228139)
    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
  • by thesandtiger (819476) on Thursday September 28, 2006 @09:39AM (#16228173)
    Er, except for one difference...

    Google's making money. Actual real profits. You must be thinking of YouTube or something.

    During the 90's, the companies that were being touted as being run by genius management were pretty much not doing anything but helping the manufacturers of $800 office chairs get rich.
  • same conclusions (Score:4, Insightful)

    by roman_mir (125474) on Thursday September 28, 2006 @09:40AM (#16228211) Homepage Journal
    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 [slashdot.org] 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.
  • Re:No Wonder... (Score:2, Insightful)

    by Chineseyes (691744) on Thursday September 28, 2006 @09:42AM (#16228249)
    Deadlines also lead to half ass buggy products that don't even meet original expectations *cough* Vista *cough*. Deadlines thus piss off the kind of people who have a vision of what they want their "perfect product" to be like. And I would think these are the type of people google wants working for them. If you read the article you would see they have plenty of motivating factors so that argument is dead, coordination is highly overrated if a group of people are working on anything (sports, coding, singing, dancing) long enough they all start to work in sync granted you need a coach of sorts in all of those areas but you definitely don't need someone prodding them like they are cattle. I don't even know why you mentioned direction, I'm assuming you work with adults if they need someone to give them direction then you are in some serious trouble.
  • the strategy... (Score:3, Insightful)

    by arkaino (972287) <arkaino AT gmail DOT com> on Thursday September 28, 2006 @09:47AM (#16228307)
    You can't help but want to do your absolute best for Google; you feel like you owe it to them for taking such incredibly good care of you.

    It's clear, good people in good mood, that's the best way to give incentives to your peers. second...

    - developers are strongly encouraged to spend 20% of their time (and I mean their M-F, 8-5 time, not weekends or personal time) working on whatever they want, as long as it's not their main project.

    that is, killing the pressure in a smart way, and third....

    One is that Google a peer-review oriented culture, and earning the respect of your peers means a lot there. More than it does at other places, I think

    that is, the respect of your peers is a KEY here, as a consequence that keeps things calm....
  • 3 meetings a week? (Score:4, Insightful)

    by plopez (54068) on Thursday September 28, 2006 @09:50AM (#16228363) Journal
    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.
  • by UbuntuDupe (970646) on Thursday September 28, 2006 @09:57AM (#16228469) Journal
    Something I want to add about Google's profitability. A lot of people have tried to compare Google to GM, and basically say, "Yeah, you're doing fine, because you're profitable now, wait until you have retirees to take care of like GM did." The difference though, is that, having learned from the 50's, Google isn't making those mistakes. Google will never have massive pension obligations for the very basic reason that Google does not enter into these obligations. When an employee leaves, Google's "debts" with them are already settled in full. If half their current workforce suddenly retired, they'd have to find replacements, but they wouldn't have to scratch their heads about any pension fund.

    That's one sign they have a clue what they're doing.
  • by Vexler (127353) on Thursday September 28, 2006 @09:58AM (#16228485) Journal
    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).
  • by EastCoastSurfer (310758) on Thursday September 28, 2006 @09:59AM (#16228517)
    Don't tell people what to work on? And exactly how does that finish projects, ever?

    This is a direct by product of the type of person that google hires. They look for the really smart self motivated type. This is the same type of person that writes OSS (and no one tells them what to work on and there are surprisingly quite a few OSS projects in various stages of completion). Your comment also ignores the fact that no projects are ever really finished.

    Googles method is a good one, and it works for them. I do think the author missed one of the huge reasons that it works - googles hiring practices.
  • Re:No Wonder... (Score:5, Insightful)

    by EastCoastSurfer (310758) on Thursday September 28, 2006 @10:08AM (#16228679)
    I know you're just flamming, but what does 'beta' actually mean? It's just a label on a given version of a piece of software. Would it make you feel better if tomorrow google changed their gmail from 'beta' and put 'production' on the page? That is what most other software companies do. Especially if the product has been up and running successfully as long as gmail has.

    In reality most software is either continously developed or it dies. I've worked on numerous software projects and few if any have ever reached a point where no more work was required. 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.
  • by andykuan (522434) on Thursday September 28, 2006 @10:10AM (#16228713) Homepage
    There are also countless OSS projects that either barely get started or are simply two paragraphs on sf.net with big dreams and no work.

    That said, I agree that it's all about its hiring practices. The talented and self-motivated person is a rare and special thing to find and hire. The Google Agile practices would never work at any company I've ever worked at because most of the engineers (yes, most) at those companies would end up day-trading, playing Quake, or gambling online (or even, *gasp*, posting replies like this on /.)
  • by andykuan (522434) on Thursday September 28, 2006 @10:17AM (#16228839) Homepage
    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.
  • by dougman (908) on Thursday September 28, 2006 @10:25AM (#16228965)
    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.
  • Herding cats (Score:5, Insightful)

    by plopez (54068) on Thursday September 28, 2006 @10:29AM (#16229051) Journal
    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.
  • by Phleg (523632) <<stephen> <at> <touset.org>> on Thursday September 28, 2006 @10:34AM (#16229147)

    One is just a weekly status update with your team lead, which seems fine.

    The other two, I'd wager, are probably pretty short, unstructured coordination sessions. Making sure everyone's on the right page, person to person. Also, perfectly fine.

    Meetings aren't necessarily a bad thing; it's the completely worthless, unproductive types that you need to watch out for.

  • Re:Test (Score:2, Insightful)

    by Xentor (600436) on Thursday September 28, 2006 @10:35AM (#16229169) Homepage

    I'm not quite sure which side I'm on in this, but the particular things you pointed out might be more relevant than you think. I'm currently enslaved to a Wall Street firm (That shall remain nameless), so let me give you some contrast...

    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.

    Here, and I suspect in most companies with large IT departments, we have a large number of projects and teams, and every developer is locked into their team until upper-level management decides otherwise. As a result, we have web developers working on heavy client applications, good designers working on mindless bugfixes and support, etc etc. The guy who sits next to me (We have trading desks, not cubicles) is doing the work of six people, because upper-level management has decided not to put anyone else on his projects. He has no support people, so when London has a problem (We're in New York), he gets techs support calls at 3am. A good developer should know when his project no longer needs him, and when his project needs more help. Managers might not, or might not care.

    There aren't very many meetings. I'd say an average developer attends perhaps 3 meetings a week.

    I agree that three meetings sounds like a huge waste of time, but as someone else pointed out, he might refer to unplanned team discussions as "meetings." If he really means three organized, scheduled meetings a week, then I'm completely in agreement with you on that point.

    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.

    He talked about a task queue system they use. Sounds like they give the developers one giant TODO list, and let the managers worry about the management without bugging the developers. I think all that stuff is going on in the background, but just isn't made apparent to the little guys.

    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.

    Here's the reason I made this comment. That's a big deal. Here, anyone who actually eats lunch in the cafeteria (Or... *shudder* OUTSIDE!) is seen as slacking off, because hard workers eat at their desk WHILE WORKING. When people have to work late, they generally order take-out and eat dinner at their desks too. Even when the job forces us to work until midnight, getting reimbursed for something as simple as a pizza takes a ridiculous amount of red tape.

    Oh, but of course you're not REQUIRED to work late, but any real-world programmer knows that statement is meaningless.

    Now then, since you'll probably assume I'm defending TFA completely, let me make this disclaimer. I don't work at Google or know anyone who works there, but I doubt everything is nearly as utopian as he describes. I'm guessing they just keep some of the paperwork at management level, so as not to distract their programmers. That said, Google NYC might see (And discard) my resume if my current job annoys me too much more.

  • Re:Not true (Score:5, Insightful)

    by Anonymous Coward on Thursday September 28, 2006 @10:35AM (#16229177)
    100% correct you are. // posting anonymously for obvious reasons

    I worked for Microsoft myself and I'm at Google now. There's a whole lot of brainwashing going on here at the miracle company. Yes, the benefits package is pretty good, and yes the work per se is pretty cool. But all the marketing hype that makes working here sound like working in heaven is so much inflated. Coincidentally enough, I'm planning on going to Oracle in the coming months -- there are a couple cool positions open in the group where a friend of mine works. Don't get me wrong, Google is cool, but nowhere near as cool as it's portrayed, especially here on Slashdot.

  • by lewp (95638) on Thursday September 28, 2006 @10:49AM (#16229449) Journal
    Indeed. I think it's so funny that people focus on the "omigosh beta" aspect of Google's software. It's only beta because they don't want you to bother them about it if you can't get it to work for some reason. Is it enough to make you want to keep a backup of your GMail account because you're afraid they might just decide to discontinue the service some day (even though they won't)? Good! You should be doing that anyway, beta or not, Google or not.
  • by nuzak (959558) on Thursday September 28, 2006 @11:17AM (#16229987) Journal
    Bell Labs created the transistor. Intel, the microprocessor. IBM, quantum spin teleportation.

    Google gave us a better search engine and some derivative web 2.0 apps.

  • by Anonymous Coward on Thursday September 28, 2006 @11:30AM (#16230217)
    The buisiness side of things has more, but hey, that's what business people are payed for, to sit around and talk while others do the work.

    This is typical of software guys. You do know that someone pays your checks right? The guys paying your wages are the ones sitting in meeting trying to figure out a few things:
    • What are you going to produce next
    • How are they going to sell it
    • Should one of you fucktards get a promotion
    • Should one of you fucktards get a raise
    • Do you guys need better equipment
    • Should you guys get health insurance
    • Should they change the development procedures so you guys have a better work environment


    The list goes on and on. This is also work. You know that waiters, bussers, checkout people, fast food workers, bus drivers, ect. consider your job nothing and thier jobs "real" work. Get a fucking clue. Almost every business where some damn tech guy decides he's also going to be the "business" guy crashes and burns.

    You want to know why?

    Because you guys know jack shit about how a business runs. You may be great at what you do, but essentially you're a intellectual factory worker. You produce a product - that's it. You guys always deal with what outside forces "should" do. You live in a fantasy land where logic reigns supreme. Unfortunately, that ain't reality. And this fantasy perception will get you killed in the business world.

    A lot of you tend to slam marketing. Your shortsightedness is mind boggling. Only a smart person could be so fucking stupid. You do realise that you only criticise marketing that isn't directed towards you, the rest of it you eat up. In fact, you will actually become an evangalist if you like the advertisment enough. Go ahead, pay attention the next time you do it. I hope the hypocrisy hurts.

    Maybe instead of making snide statements at others who actually influence some level of control in the world, you could better yourself and eventually exert some yourself you pathetic asshat.
  • by Fahrenheit 450 (765492) on Thursday September 28, 2006 @11:55AM (#16230719)
    Gahhhh! Would you people please quit calling the offense that SF ran in the 80s the West Coast Offense. The WCO is what Doy Coryell developed and ran in his San Diego days with Dan Fouts, slinging the ball about. What San Francisco ran was developed and implemented back in Cincinnati, before Walsh took it to San Francisco. So unless you're referring to the west coast of Ohio, your terminology is terribly wrong.

    Yes, I know that the clods in the broadcast booth call it the WCO, but they can't even master the difference between an end-around, a reverse, and a double reverse. Do you really expect them to get the history of the sport correct?
  • by yurnotsoeviltwin (891389) on Thursday September 28, 2006 @11:57AM (#16230753) Homepage
    Google's beta products are almost universally better and more refined than any other company's final releases. I applaud Google for not pulling products out of beta until they're truly thoroughly tested.
  • by MikeBabcock (65886) <mtb-slashdot@mikebabcock.ca> on Thursday September 28, 2006 @12:07PM (#16230947) Homepage Journal
    The terms "rush" and "do quickly" are different.

    Yous till can't rush a stirfry ... if it takes 3 minutes, it takes 3 minutes, not 30 seconds.

    Its not rushed if its done in the right amount of time, even if that amount of time is short relative to other foods.
  • by andykuan (522434) on Thursday September 28, 2006 @12:15PM (#16231101) Homepage
    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.
  • by Anonymous Brave Guy (457657) on Thursday September 28, 2006 @12:34PM (#16231499)

    Er, except for one difference... Google's making money.

    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.

  • by Shads (4567) <`gro.sudahs' `ta' `sudahs'> on Thursday September 28, 2006 @12:52PM (#16231841) Homepage Journal
    All of the google apps are profitable. They all feature the ads :)
  • by Mycroft_514 (701676) on Thursday September 28, 2006 @01:50PM (#16233033) Journal
    It is really simple. If you have to hire more DBA's because you pushed developer work onto them, or you pushed mroe work onto the DBAs because of poor development practices, then you are paying higher costs. Each DBA gets paid more than each developer, ditto for tech support people.

    That is my point. We are trying out agile development here, and because of it, the developers are causing the DBA group to do multiples of the work they used to do. So far only one test project, but it is enough to see what is going on.

    That and this type of programming has gone round before, and will go round again. There is no "new" methodolgy under the sun. If you have really good developers, than anything will work. If not, nothing does. There, a new methodology.

    Oh, and Drucker is not part of it, since Quality is what is lacking in the first place.
  • by cubicledrone (681598) on Thursday September 28, 2006 @02:38PM (#16233979)
    Don't tell people what to work on? And exactly how does that finish projects, ever?

    WELL IT SURE SEEMS TO BE WORKING OUT JUST FINE FOR GOOGLE, DOESN'T IT?

  • by RingDev (879105) on Thursday September 28, 2006 @03:25PM (#16234997) Homepage Journal
    Brilliantly thought out. and well said. /golfclap

    Now pull your head out of the toilet of fanboyism and try to imagine applying non-proffitable project management to a company that doesn't have huge sums of money to loose while looking for another cash cow. The vast majority of developers work in businesses that are not IT companies. Companies where there are deadlines, budgets, time constraints, and customers.

    As I said, I would love to experience the Google workstyle, but it is only applicable in places like Google. Do not expect the same kind of environment working for H&R Block.

    -Rick
  • by bADlOGIN (133391) on Thursday September 28, 2006 @04:17PM (#16235993) Homepage
    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'".
  • by drsquare (530038) on Thursday September 28, 2006 @05:19PM (#16237133)
    Google is profitable because they're good at selling adverts.

    This isn't anything to do with revolutionary management or development tactics, but good old fashioned advertising principles.

    Excuse me if I don't join the worshipping of what at the end of the day is just a giant marketing corporation that makes a few novel permanently-beta web applications on the side.
  • by RingDev (879105) on Thursday September 28, 2006 @05:34PM (#16237397) Homepage Journal
    I completely agree with you that developers don't have to be at every meeting, but bringing one along from time to time can cut off problems and bring up issues that may have been missed other times.

    I also agree, that free of leashes we can do some brutally awesome things. But in the majority of corporate worlds, that just isn't an option. As much as I'd love to create a custom leasing solution designed to directly mimic the exceptionally complex business needs of my organization, they can not afford the multi-year investment it would take. They wouldn't even be able to afford (in time) the business requirements gathering and analysis that would be required to build such a system.

    The more I learn about project management, the more critical I can see it as being. I've been involved in successful projects, and unsuccessful projects. And as a programmer I couldn't ever really explain why a project failed. The code was good, the app was maturing, features were solid, bugs were few, and yet they failed. After learning more about project management I can see how much more there is outside of coding and deployments. Some of the failed projects were doomed from day one, not because of an single person's failure, but because of a total lack of direction, guidance, and management.

    -Rick
  • by Anonymous Coward on Thursday September 28, 2006 @06:29PM (#16238129)
    Uh. Did you miss the part where he says

    Teams are always situated close together in fishbowl-style open seating, so that pair programming happens exactly when it's needed


    They have meetings ALL THE TIME. Constantly, every single day. Most are just two people talking about something and everyone else overhearing them. Or maybe one guy just asking aloud if anyone knows about something or another. Everyone knows what he's working on, what he's having trouble with, who knows about that stuff so they can ask them in the future, and whether and how it was resolved. Done! You don't need to say that at a daily meeting because, duh, we all know because we were there when it happend an hour ago. Organized meetings are for teams where members never, ever see each other. Take a space constrained company that's big but can't afford all the wasted space of a Googleplex in the Valley. You can move this person here and that person there, but ultimately you're going to have people on the same team accross the building from each other. It's inevitable unless you repack the whole building every time someone joins a team which is completely impossible.

    For all of the companies that can afford some empty space to allow for team relocations, by all means this is the ultimate way to improve productivity. This mere tiny sentence probably speaks volumes to why Google works so efficiently.
  • by tr0p (728557) on Friday September 29, 2006 @01:43AM (#16241669) Homepage

    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.

1 1 was a race-horse, 2 2 was 1 2. When 1 1 1 1 race, 2 2 1 1 2.

Working...