Egomania Itself

I'm wondering, should I kiss your ass or send you my Résumé ?

I've just been given a special "non XP" position (read : cowboy along the XP team, think of Jean Reno in Nikita) for not being a team player enough (read : "I don't give a shit 35 hours a week, my weeks are between 20 and 100 hours depending on the mood"). Thanks you for fighting for my freedom.

I though I'be fired for not beeing XP-capable. By pushing things like : "people over process" you make management teams get back on the earth.

The Agile methodology, like other extreme technologies that tend to induce religious ferver in adherents (e.g., Lisp, Smalltalk, and for good reason), will provide the long-term benefit of some of its best ideas (unit testing is helpful in many cases) trickling into mainstream development processes.

ROFL.

Couldn't it be that you are supersicious about Agile programming....You'll never know.

j/k

I love your refreshing points of view.

There is nobody - nobody - who has as high of a Polarizing-Yet-Insightful-Opinions * Testicular-Fortitude-To-Post-Those-Opinions product as you, Mr. Yegge. You are one of the few bloggers who I read every day.

That breakdancing Chicken? It's a Pigeon, as described by B.F. Skinner.
Interestingly, hearing the story in an Ethology class inspired me to write my first program in about ten years, to demonstrate the selection effect of random reinforcement to myself.

You know, what, I don't even care about the Agile stuff anymore, I don't give a damn!

JUST STOP WRITING SO GOD DAMNED MUCH!

plenty of "success stories" from non-Agile teams
"There are hundreds of successful ways to build small applications, but only a few ways to build large systems successfully." p431 "Software Assessments, Benchmarks and Best Practices."

Agile vs. non-Agile, failure vs. success
The fun starts when we ask what any of that actually means - whose definition of "Agile"? whose definition of "success"?

It's such fun to define success for non-Agile projects (whatever they are) as on-time on-budget, and chose a different definition of success for Agile projects (whatever they are).

I'm a tech lead on a project at Google. We very recently started using Scrum to see whether we could get better at producing more of what our customers wanted faster. I was the one who sold management on the idea; it didn't come from above, so don't blame them. So far this is working pretty well.

I understand that this is a personal blog, and Steve's giving his opinion. Still, it bothers me because it gives what seems like a pretty inaccurate view of Google and what little I know about agile development (sorry, I don't think it merits a capital 'A'; it seems faintly ludicrous to me; maybe that's the sort of thing that bothers him too).

As far as Google: there's been a lot of talk here about the "Google way", which sounds a heck of a lot like "Google methodology" to me. If there is one, I don't know what it is, and I've been working here almost three years. Different groups use different approaches -- some are design top-heavy, some are totally XP (though they are the minority), and some just lump new functionality in until they decide it's done. Groups do what works for them, and nobody much seems to mind.

My point is: "Google" does not mean "doesn't do agile." It doesn't mean anything remotely like that. We have an "intergrouplet" (a semi-formal organization of engineers supporting an aspect of engineering life, like documentation or the build system) devoted to agile, and upper management (who are not stupid people) supports the spread of agile ideas. So yes, we do agile at Google, big A and little a.

I spent a lot of time talking to people in that intergrouplet before we started trying Scrum. The attitude I got was, "Well, here's what the books say, here's what we've tried, and here's what seems to work pretty well for us." Which is what I wanted to know. I'm not interested getting a certification; I'm interested in making my group happier and more productive, and if there's an idea that will help me do that, I'll try it. Many of the agile ideas seem to fall in that category. We're trying a few now, and if they work out we'll try more later. If not, we'll drop them. Maybe that means we're not really doing official Scrum; but if it works, who cares?

What bothered me in these posts was the idea that anybody who used agile was either a gullible mark, or an unscrupulous consultant, or both. I'm not a consultant, and I don't think I'm that gullible. When I first saw Steve's post on "Good Agile, Bad Agile," I thought, great, here's somebody who's opinions I respect, and I'm going to learn something. What I got seemed like pretty wild, unsubstantiated ranting about why agile is bad, without reference to any specifics, or any discussion of particular agile ideas he didn't like. The one specific I do remember him disliking was pair programming, but the argument seemed to be, "Pair programming sounds stupid to me; therefore, it is stupid." I'd be very happy to hear why it's not a good idea, or anecdotal evidence about how it failed, but that's not the kind of thing that's going to convince me of anything other than his strong personal dislike of pair programming, the same way that some people don't like science fiction or folk rock.

(I really wish, by the way, that Steve had described what experience he had with agile development; he said he'd tried it, but not what actually happened. Did he have to do daily standup meetings? Did his group do pair programming? Did they have regular meetings with the customers? Why didn't it work? That's a post I very badly want to read.)

I was depressed and frustrated by these posts, because they're getting a lot of play, and the lesson people I talk to seem to be getting isn't, "It's okay to say no to Agile," but "Agile is stupid, so don't waste your time learning about it, and if you use any agile methods, you're stupid." I bet that Steve is a very good engineer, and I'm ready to be convinced, but I need more than that to do it.

It occurs to me that maybe the point wasn't that agile development ideas are stupid, but that people have a tendency to turn ideas into religions, and while some agile ideas might be (and, I think, are) healthy for software engineering, the Church of Agile Development isn't. That's an idea I completely agree with.

Patrick: The well over 95% of teams at Google -- and everywhere else, mind you -- that do not use Agile needed a voice as well, precisely because of the Church problem you bring up in your last paragraph.

I would encourage you to be sensitive to the fact that it's hard to back out of Scrum if it's not working significantly better than not using it. (And you won't really be able to tell; it'll just be a "feeling".)

You should run weekly double-blind polls with your team, peers, and management. If anyone goes limp, taps out, says stop, even if they're faking it, the fight should be over, and you should put the process back on the shelf.

If you think only Google does Agile right. Why did they choose java for Gmail? Why does the top Gmail engineer thinks that refactoring tools are important? http://beust.com/weblog/archives/000414.html

> "... if you add enough chili, you get chili."
> ... it's plain, unadulterated superstition.

Agreed. More code, less fashion!

Prashant, your comment is so poorly phrased as to be unintelligible.

Since you linked to Cédric's blog, however, I believe I'll do the same:

http://beust.com/weblog/archives/000392.html

Everyone knows that real chili doesn't have beans...

"In order to process all that information fast enough, our minds have a tendency to assume that if two events are coincidental, they're also correlated."

s/coincidental, they're also correlated./co-temperal, there's an associated causality./

Things that happen at the same time are correlated. In time, however, not by cause and effect.

Here's the point of this article:

Just because someone (or some group) is loud doesn't mean they are right.

- and -

Think for yourself. Don't trust superstition; use the scientific method.

- and -

Yegge doesn't think we should allow loud, religious and superstious people to spread their brand of development to the point where thinking for yourself becomes a cowboy coder activity.

Hey Steve,

Great reading as usual--of course, I wonder what Dave Thomas would have to say about it :-)

I'm not sure if you're back to reading your comments, but if you are I posted a response here.

Steve, thanks for responding to my comment. Maybe the conventional attitude toward Agile is just very different from my own experiences. Both Google and the last company where I worked are very light on process, and engineers have a lot of authority, so they would have to be convinced of its value for it to be adopted. At a company where engineers don't have authority, or where management is blindly willing to follow the latest process fad, I can see the potential for disaster. Maybe the potential is worse with big-a Agile because there's a kind of touchy-feely, let's-hold-hands-and-sing-Kumbaya quality to some of the presentations that clouds the discussion of what should be specific, practical, measurable development practices.

Speaking of which, I strongly agree with your point about evaluation. We are concerned about how to tell whether Scrum is working. We're talking about internal customer surveys, engineer feedback, comparing quarterly objective results, etc. to try to measure this, but we don't know whether those are going to work. I don't know whether we'll be able to find an objective measure of success. I haven't been able to find much convincing evidence in the literature for or against agile, just a lot of very small experiments and anecdotal data. That's not a criticism of agile -- it's incredibly hard to run a systematic experiment to measure things like developer productivity -- but it means we're trying this because it "feels" like a good idea. We've given ourselves a quarter to experiment. I think (and hope!) we're wise enough to drop it if it doesn't "feel" right after that.

Another anagram is: Elegant Mafiosi :)

Found your blog via Joelprah link. Glad I did. World needs to here more independent, funny, thoughtful, slightly eccentric voices like yours.

Great post Steve!

I'm a big fan of agile techniques in general but I've always had a problem with the unjustified advocacy and shameless marketing. Of course it's just the latest in a long line of snake oil solutions. Maybe one day we'll stop trying to define the perfect process and just get on with it.

Keep up the good work.

This was great, except that it is not true that "egomania itself" is the only 2-word anagram for "agile manifesto." There are loads of other good ones, to wit:

FOLIAGE INMATES
INFAMIES LEGATO
MANIFEST GOALIE

and of course,
FOAMIEST GENIAL
(if only it was the AgileST Manifesto!)

Best. Blog post. Evar.

disclaimer: I've never done XP programming, and I wouldn't know Agile methodologies if they poked me in the nose. The first time I heard someone go on about XP (at JavaOne a few years ago), my thought was, "how interesting: they're trying to find ways for programmers to be cogs so they can get control of the process."
in 2001, I interviewed at a hardware company to be their VP of software development. They'd implemented the 802.11a/b/g stack in hardware (yes, entirely in hardware, so they told me) and were very perplexed about why software development was always so hard to schedule -- their hardware development was very deterministic, and they could gauge the complexity and be very accurate in their scheduling, but software... well, it was squishy. I had no good answers for them.
software development is a fundamentally creative act, and debugging is often an intuitive one (where intuition likely is subconscious reasoning). I think much of software can be reduced to the production of cogs, but the great stuff, the really innovative stuff, will never be spit out of a machine.

I wonder, if you could arrange several types of programming languages into 12 catagories, and predict which types a person would like based on date/year of birth.

Like a techno-zodiac. :)

Seems almost ironically fitting.

Great post, Steve. The funniest line, however, might have been in your response to the comments:
"… little dict." Truly clever!

It makes me happy to see that you're back to reading the comments. Now I wish I had something more intelligent to say. Okay, I'll be quiet now.

Steve,

I've always been a fan of statically typed languages, though I've been able to use variant-typed languages like JavaScript without feeling the need to jump in the shower, but the recent push towards type inference in one of my languages of choice has left me feeling scared that I won't know what the compiler is actually using. I crave the organization and trust that I feel coming from the practice of assigning an interpretation to each symbol at each level of the code.

By your theory of neat-freaks, this should make me an early-riser who can't focus on anything until the bed is made and the counter cleared, but this is not the case (and it is not the case for my wife either! :-). What, then, am I? Am I some sort of freakish hybrid?

Please help me to understand myself :-)

To people claiming that Steve "needs an editor" and that there's "too much rambling", remember that these are not essays he is writing. These are blog entries. Blog entries are meant to be vitriolic, meandering, fun, and feel more like sitting around a campfire with a great storyteller than listening to a PhD candidate defend his thesis.

Heck, Steve even claims outright that they're "[drunken] blog rants". It turns out that they're quite sober, and contain many quite well crafted jabs. Story and metaphor drive points home much deeper than an RFC.

Just add me to the list of people who have unmade beds and use a statically-typed language. I've just spent too much time playing guess-the-type with interpreters where it's basically impossible to have "37" remain a string and {{"37"}} remain a list of lists (that happens to have one element).

I don't use statically-typed languages because of how I was potty trained, but out of the same desire for effort minimization that drives your anti-static preference. It's just that for me, the minimal annoyance is in having to have a preface to every function labelling variables and having to manually cast when necessary, and for you minimal annoyance is evidently in accepting the speed hit from frequent type-checking and having to fix the occasional mis-cast when necessary.

Also, S., thank you for not editing to the least common attention span. If they don't want to read the whole thing, they learned how to skim an article in junior high.

Patrick,

I find your comments pretty interesting, but I'd like to present a counterpoint.

I worked on a team (at the same company as you) where we were essentially "forced" to use Scrum. I don't think a single engineer on our team found it useful, and I personally found it annoying, but we didn't really have a recourse for evaluation: I gave feedback that I didn't like it, but I'm not sure that everyone else was comfortable doing the same, and there weren't any of these wonderful double blind weekly evals. I also think its results were mis-used. The data that was derived from it (how much our team could accomplish in a week) was tainted and it shouldn't have been turned around and used to make decisions.

I think this shows that even our venerable company is not above top-down pressures to adopt processes that should remain the the personal choice of individuals on a team. I appreciate Steve's posts so far because they address the issue of this being adopted as a process for many, without evidence.

I personally don't ever want to use Scrum again. I'm not sure how this jives with people who find Scrum useful -- am I just supposed to stay off of their teams? Are we going to be divided into agile vs. design upfront vs. whatever teams in the future? What happens when someone on my team wants to use index cards, but I find them ridiculous and contrived?

I agree that each team should be free to pursue whatever strategy it finds useful, but individuals on those teams should never be made to use a process without evidence of its worth. And just because its Google doesn't mean that we don't have to be very careful about these issues -- you make a lot of assumptions about our engineering culture that are not true everywhere.

Neha,

I'd be very interested in talking with you about your experiences with Scrum. I think there are things about it that are going to be valuable for my team, but our goal is to make our development process better, not to market Scrum. If there are pitfalls here I'm just not seeing, or not taking seriously enough, it would be great to understand what they are.

I'm not sure how to answer your question regarding groups that disagree about process issues. I don't see a fundamental difference between Scrum and any other approach here: what about engineers who dislike the waterfall model (which must be most of us)? What happens when someone in your group won't start coding without a big up-front design document and you just want to use test-driven development? Some approaches to software development won't play well with others, and I guess I don't think it's always reasonable for each individual in a team to pick a process that suits him or her.

Clearly there are some aspects of process where most people can agree, or we think it is acceptable for a higher authority to mandate certain behavior. Source code control and code reviews are a couple of examples that nobody I know of argues are bad ideas, and even if they're occasionally irritating, most of us follow them. On the other side are things (or so I've heard) like telecom software reviews, where they'll do multiple rounds with large committees to read over small changes to make sure they aren't going to mess up the phone system -- almost anyone not in that world would regard that as overkill. The problem, which feels to me like the Emacs vs. vi debate, is the large, fuzzy world of things like 3x5 cards and daily standup meetings and pair programming, where people have intensely strong opinions; but process, unlike editors, is something that the group does, and isn't an individual thing, so we can't always just agree to disagree.

My immediate reaction to your question was to think that yes, teams should collectively pick their processes, but I realize that that's not very realistic in most cases; either the team can't agree, or management has a way they want things done, or (as in my case) there's somebody evangelizing for an approach that nobody's strongly objecting to. The alternative I see is a sort of no-process process, where everyone does what they personally prefer, which can be amicable but has some big disadvantages too. To some extent, that's the world we're coming from, but it still remains to be seen whether more process helps us out or not.

Here is the correct superstion reference: 'SUPERSTITION' IN THE PIGEON. It is a classical paper of B. F. Skinner.

enjoy you unique insights.. but your verbose rambling writing style makes me think you must enjoy
Java coding - tons of redundancies

Reminds me of a time when i saw the a verbose Java program containing thousands of classes -- to fart you need to create a "fart" class containing a constructor destructor and other boilerplate..

XP, Pair programming, scrum -- silly ideas conceived by non-coders, for assembly line programming (applicable to
cobol programming in the past and to its modern equivalent Java)

I ramble.. on style Joel has you beat, you are entertaining anyways,
keep it up.

Hey Steve,
I have this dict-enlarging technology for you, CHEAP !
http://wordsmith.org/anagram/index.html

You're welcome

paulo -- thanks for the reference. I wonder if my 1986 psych prof was passing along an urban legend, or if she recounted the facts from the paper accurately and my re-telling of it changed over the next 20 years. I'll have to go review the tapes after I'm dead. In the meantime, I'll go check out the paper. :)

Sorry to hear about your little brother.

I worked in a company that was "sold" agile by a string of consultants. It ended with redundancies. I've seen so many methodolgies come and go in exactly the same manner and it's good to see this one going. I won't miss it.

As an Orthodox Jew, I think that I can bring a different perspective to this religious war. I hold tight to all those Commandments in Torah that most people ignore. The essential thing is this: I'm not looking to take that cheeseburger out of your mouth, or prevent you from going to the movies on Friday night. Holding strong religious convictions is fine (i.e., Agile); just limit your proselytizing to those who seek you.

[You never really know if it's a "fact" until science has promoted it.]

This was incredibly lovely, and in fact sums up these last few posts perfectly. If, for example, Steve bumped his head on the door, he would not know whether he has a concussion until "science" (wow... just take a moment and admire the reification here) declares that yes, a new fact has been discovered, and Steve has bumped his head. (For more points, "science" should do repeated experiments to come to that conclusion.)

For additional fun, realize that repeated experiments, where event B (called "effect") follows in time after event A (called "cause"), is exactly how "science" supposedly works to decide what is "fact" and what is "mere" superstition. Apparently, the only difference between a regular Joe seeing something happen several times, and a scientist doing the same is that, well, the latter is a scientist.

Funniest blog in a long time.

Amazing how 20-somethings can make sweeping generalizations of what everyone in the industry is "really" doing, based on their pampered existence at Google and one example of gaming software.

Jeff L: please don't feed the Agile Fascist stereotype.

I wrote this entry before Stevie had his first rant. I think it is quite relavant to this post.

Agile's Dark Side

Looks like Martin Fowler has responded:

http://martinfowler.com/bliki/AgileImposition.html

Yegge, Someone is always going to bash you for some side comment you make that you never expected anyone to question, so here I go:

I understand that the Enquirer, despite being a gossip magazine, has been trying to improve its reputation by extensively fact-checking all of its articals. Wikipedia can be said to have extensive fact checking for those articals with high interest and multiple submitters, but surely there is still a lot of unchecked crap.

So I demand you take it back!!! Enquirer rools Wikipedia drulez!!!!!!!

And in defense of C++, some of us are still doing client applications with large data sets and find that C++ has the best combination of performance, collection of libraries, and platform support and don't feel like "well, you should still use ruby wherever that _doesn't_ matter" makes any sense.(Though I totaly understand your cat painting comment. Really what gets me is doing consructor/copy constructor/assignment operator/destructor before I can write code that actually does stuff -- and that so many argue about what the right way to write those fillers are so that it is thread/exception/DRY safe!)

Stevey, if you didn't read Umberto Eco's "Foucault's Pendulum" you should. Echo - who is a first professor of semiotics with University of Bologna - shows how our mind correlates disconnected facts, regardless that the facts are related or not in reality. In his book he gets the reader to believe in a story which he demolishes completely in the end.

He shows that a statement is true or false not based on fact, but by how many people believe the statement is true or false. Given enough believers, then anything BECOMES true.

Same as Eco, or the Agile Manifesto people, you do the same. If you can build enough belief into your readers, than suddenly you become a man of truth. And you are a pretty good writer. "You can start with dog shit, and if you add enough chili, you get chili." LOL. Your chili is pretty good ... :)

Of course, being scientific and objective about things doesn't help either, because of two reasons. First of all because it seems science is extracting facts by randomly connecting dots (see George Chaitin's work), same way our brain does. No surprise there since our thinking process is what invented science. And secondly, objectivenes is no good because it is too easy to twist and turn around. As an extreme, one can even justify genocide based on objective facts. Objectiveness can be that bad.

With that being said, you're article is strictly your loud opinion on agile and it represents the truth as much as the agile manifesto does.

Finally, if you're one of the good guys and you're honestly trying to make a difference, maybe you try to encourage / remind people to think for themselves?

Honestly I don't know how to take all of Steve's comments. You can read them one way and they are funny, another way and they are not funny.

Many of the arguments suffer from well known fallacies. http://www.nizkor.org/features/fallacies/

It is hard to tell if Steve is saying that there is Agile, Waterfall, some other devilish method, and Google's way OR if he is saying there is Good Agile and it is Google's way OR something else.

I do believe that there are people selling Agile, Spiral, CMM, and many other methods, including Google's way, as being the best.

From what I have gathered the Google way consists of:
a) Hiring people who can't be duped
b) Not telling when a product may release.
c) Hard work is the solution to all problems.

I am pretty well known in the Agile communities. They know that I don't believe in any one process. I do find many good practices in the Agile camp. I haven't found anything new in the Agile world, but I have found new ways to talk about techniques and practices which I consider good.

I am not as elloquent as Steve and I often have to find my voice through someone else. I found that Ricardo Semler had experiences that I could understand and had shared them in a book. Here is my summary of that book:
http://home.att.net/~geoffrey.slinker/
maverick/Maverick.html

Now let me explain a bit about myself. I have always believed that books that tell you how to be successful are a joke. The book itself is how the author is being successful and the author depends on fools to buy his book.

After much resistence to a friend's suggestions to read Semler's book, he finally loaned me his copy so that I wouldn't have to spend money on the book and therefore I wouldn't feel like I had fallen into the trap.

Another text that speaks volumes to me is "The Law". Here is a link to that as well:
http://home.att.net/~geoffrey.slinker/
maverick/TheLaw.html

This should give readers some insight into my personality.

I took the lessons from the "Maverick" book and I came up with the Maverick Model for software development. http://home.att.net/~geoffrey.slinker/
maverick/MaverickDevelopment.html

Shortly after I had done this friends wanted me to apply the Maverick Model to a specific situation, thus creating a method. I was hesitant knowing that once you state things in a method there would be many that would take it out of context and then find fault.

Sorry, I have been rambling. Maverick is not sold, there are no boks to buy, no consultants to hire. There is a discussion group which is available to all. Since I do not get any money for my efforts does it make Maverick better than Waterfall (which has many many books and papers) or Agile or the Google way?

There is a type of person that I call and Agilista. Agilistas are nothing more than opportunists that have jumped on the Agile bandwagon and they shout "come down to the river and be healed". These Agilistas don't understand development, they don't know why Beck, Cockburn, Jeffries, Fowler, or whom ever suggest specific practices. These Agilistas don't even know what the real problems are!

I feel that there have been a lot of non-developers that have found their position weakened by new methodologies (in this case Agile) and they found themselves loosing clout. Therefore they have relied on their "snake oil" salemanship and jumped on the wagon and started shouting their sales pitch. These types of people ruin everything and they don't even understand what they are ruining.

Also, I have seen those that have not experimented with new applications of old ideas (such as Agile)and have superficially declared them stupid or snake oil, or some other form of the "appeal to ridicule" approach.

When I first heard of XP I did some quick study of it and I started a paper. The title was "XP eXposed". I wanted the paper to be sound so I was doing my homework. As I experimented with XP I soon found that it wasn't as stupid as I first thought. Eventually I found that there were many good things to learn (for the novice) and to be reminded of (for the seasoned). I never finished the paper. Why? Because I found it better to focus on the good than to focus on the negative.

I understand that some people feel the need to debunk the myths and expose the frauds. That is good, but not good enough.

What is needed are solutions to real problems. I have always found it hard to listen to conservative talk radio, eventhough I am very conservative. Why? Because it doesn't take too much to point out what is wrong. It takes much more to point out how to fix what is wrong.

Ridiculing early risers, strongly typed language users, bed makers, etc., may be entertaining but fails to get us closer to solutions.

Also arguing that if any one soul finds fault with some practice (in this example a daily Scrum) then the practice should be shelved immediately then we can clearly shelf Waterfall, Spiral, Google's way, C++, Ruby, Python, Smalltalk, Fords, Chevy's, Hondas, Democratic Republics, Socialism, Communism, Scooby Doo, H.R. Puff-N-Stuff, the Wiggles...

So, to keep to my mantra of offer solutions:
1) Experiment. (http://home.att.net/~geoffrey.slinker/
maverick/Scouting.html)
2) Learn the difference between Leadership and Management.
3) Work can not be replaced. Talking about work is not work. Planning to do work is not work. Meetings about work is not work.

Sincerly Geoff.

Here is a snippet about leadership that I believe to be useful:

The leader, for example, has a passion for equality. We think of great generals from David and Alexander on down, sharing their beans or maza with their men, calling them by their first names, marching along with them in the heat, sleeping on the ground and being first over the wall. A famous ode by a long-suffering Greek soldier named Archilochus, reminds us that the men in the ranks are not fooled for an instant by the executive type who thinks he is a leader.

For the manager, on the other hand, the idea of equality is repugnant and indeed counterproductive. Where promotion, perks, privilege and power are the name of the game, awe and reverence for rank is everything and becomes the inspiration and motivation of all good men. Where would management be without the inflexible paper processing, dress standards, attention to proper social, political and religious affiliation, vigilant watch over habits and attitudes, etc., that gratify the stockholders and satisfy security? ... Managers do not promote individuals whose competence might threaten their own position, and so as the power of management spreads ever wider, the quality deteriorates, if that is possible. In short, while management shuns equality, if feeds on mediocrity... For the qualities of leadership are the same in all fields, the leader being simply the one who sets the highest example; and to do that and open the way to greater light and knowledge, the leader must break the mold. " A ship in port is safe," says Captain Hopper, speaking of management, 'but that is not what ships were built for," she adds, calling for leadership... True leaders are inspiring because they are inspired, caught up in a higher purpose, devoid of personal ambition, idealistic and incorruptible... So vast is the discrepancy between management and leadership that only a blind man would get them backwards... "

Steve, I gotta say this is pretty unfair to agilistas--I don't know one of them that can write half as entertainingly as you.

A lot of this stuff is common sense, but the Far Side cartoon really cracked me up. It's so true about static typing. I mean, it's gotta be pretty well proven by now that static typing is not necessary for scalability or maintainability, but yet some people just can't stand not having it.

When it comes to methodologies I always go back to "No Silver Bullet". The fact is, there is a certain capacity to be a good programmer based on the interest and focus to solve difficult problems. I think it's characterized by the confidence and tenaciousness to debug any issue, not necessarily any particular knowledge. The people who don't have this ability area always looking for a way to make programming easier and more foolproof. Of course methodologies, new languages, and tools can help, but sooner or later you will hit a bug which requires a real programmer to solve. The developers of these methodologies are effective salesmen, because they are honest. These methodologies are the result of skilled developers refining their own process.

The problem is mediocre programmers won't get anything out of the methodology if they don't understand why. Otherwise it's just blind obedience without reason. The best you can hope for from a methodology is inspiration for how to solve issues you are already aware of.

Hi Steve,

Well, I'm off the net for 2 weeks, and some interesting stuff sure happens.

First, I am a strong proponent of XP. I have seen it work, and seen it work well, in several projects at several companies.

What I sense from your blog is that the XP "zealots" you see make it out that there is only one way to do XP - by the book. However, I see (and believe) some strong leaders respond to comments like "If I do this, am I doing XP?" with comments like "XP isn't about following a strict methodology - it's about delivering value to the customer"

To that end, I believe that XP is a tailorable process. Pair programming doesn't work for everyone, and may not be needed all the time. Does that mean you aren't doing XP? (And the answer is: it depends on who you are talking to).

Your comments highlight one of the biggest fears I've always had about XP - that once managers and consultants got ahold of it, it would be basterdized into being a prescribed methodology, instead of a collection of practices that can help improve the development in your shops.

I, instead, view XP as a cookbook. I look at the practices and the current situation, and see which ones fit for the current problem the organization is experiencing (or percieving). For example, if the relationship between the developers and the customers is adversarial, then some of the customer practices like planning games and the such can help mend that relationship.

But, it might not.

And good teams know that, in XP and agile, when something doesn't work, you do a retrospective of why it doesn't - and then ditch it if you can't fix it.

It's a shame that what you've seen for XP has given you the impression it has. No matter how completely amusing your blog posts are.

Because, in my world of XP, one of the most important things for the teams to remember is that it is /their/ process, not anyone else's, and it is /their/ responsibility for ensuring that they understand the principles behind the practices so they can tweak them to fit their needs.

Hey Thats Great, but I think you should maybe spend a little time working on your cool game Wyvern which I love to play :)

First time commenter; followed the link from Jeremy Zawodny's linkblog. Just wanted to let you know that your page (main page) screws up my browser... not quite a full browser freeze, but a freeze-of-the-current-window-and-all-tabs-in-that-window (Firefox on a PPC Mac). Anyway, adblocking "http://rcm.amazon.com/*steveysblog*" gets rid of the problem. 27 iframes in a 216kB page seems to do the trick of killing my browser. Individual post pages work fine, though.

Python and Lisp are languages I use most often. They are very
flexible, but their lack of the ability to do static typing
sometimes makes bugs more difficult to find. In other words,
if your code looks unusual, it's either a mistake or a
sign of genius. In most cases, the former.

I prefer to treat types as compiler-understandable comments. Clearly,
not every variable declaration needs a comment (as C/C++/C#/Java would
like), but sometimes comments are useful. Type inferrence, or
generally "comment inferrence", is the way forward. Most importantly:
it should be up to the programmer what and when to comment, not to the
language designer.

There is probably too far down to ever get read, but I'll post it anyways... it's a short anecdote from my personal career.

In 2001, I was working for a Small California Software Startup. We had 10 or 11 engineer working on an enterprise application, and had been for about a year. Management was forcing us towards a ship date that was too aggresive (by a few months), in order to book revenue (which of course would ultimately leave the customer very unhappy with the unfinished product, and they wouldn't be repeat customers).

So, one day, they fired the VP of Engineering, the VP of Marketing, and the Director of QA, and introduced us all to none other than Mr. Ken Schwaber (author of "Agile Project Manager with Scrum"). And, www.controlchaos.com.

Interestingly, the old VP of Engineering was keeping track of all the tasks on a big paper calender with stickies that she would move around as features got put in or moved out. Mr. Schwaber convinced us that this system wasn't any good, and having a once-a-week meeting that took about an hour to update this calender wasn't going to work. Then we started having DAILY meetings where we answered the three questions.

I bemusedly noted after about the third day that the answers to the questions that I gave didn't seem to matter. I could lie about what I did yesterday, I could like about what I was going to do today, and I could make up all sorts of reasons about what was blocking progress. No one seemed to be recording anything, and there seems to be no actual destination, just a continual tacking of the boat, back and forth, back and forth.

I quit and changed jobs about 2 weeks into this new process.

The paper calendar with stickies seemed quite good to me, and I'm sure we doing Scrum wrong.

I don't think the product ever shipped in whatever form it was in, and I know it didn't make any money.

Unfortunately, I think management truly beleived Scrum was going to allow them to slow time itself.

And by the way Mr. Schwaber speaks, you'd be hard pressed not to beleive he thought himself able to slow time.

Someone wrote:

For additional fun, realize that repeated experiments, where event B (called "effect") follows in time after event A (called "cause"), is exactly how "science" supposedly works to decide what is "fact" and what is "mere" superstition. Apparently, the only difference between a regular Joe seeing something happen several times, and a scientist doing the same is that, well, the latter is a scientist.

No, that's not how science works. You really should read up on things before you post such nonsense.

What science actually does, in addition to noticing correlations between events, is attempt to find a way to show where those correlations break down. A scientist comes up with a theory, then tries to falsify it (prove it wrong by running other tests).

And I think that's part of what Steve is saying isn't happening with development methodologies. Lots of people are doing the annoying marketing/religion thing - they're using anecdotes about how their system worked for them and completely ignoring any of the problems or attempting to find out where it goes wrong.

He doesn't say how to test such things, but he at least claims that he's seen Agile development not work. (I agree with Patrick that some specifics would be nice.) That's a step in the direction of doing some actual work to figure out what does work, but it's not the final step by a long shot.

Beautiful writing.

Ben,

Individuals and interactions over processes and tools

You should read about Russell’s Paradox. When you ascribe to a Manifesto, of any sort, you, by definition, have put individuals and interactions in the back seat. Thus, any process that defines itself as above process is not adherent to the process to begin with. Try saying that 10 times fast.

Working software over comprehensive documentation

What good is “working software” if no one knows how to use it?

Customer collaboration over contract negotiation

Yeah, that really works. What programmers need, more in life, is to start dealing with the customers more and to not worry about getting paid. It’s one of those nice sounding phrases, where you get the picture of the programmer and the customer holding hands and walking though the flower fields sing kumbaya. Be weary of things that sound so happy.

Responding to change over following a plan

See Russell above.

Like many folks in these threads, I've been managing software projects for a while - enough to have managed with waterfall methods, agile methods, back-of-a-napkin methods, and run-fast-the-exec-is-coming methods.

In my experience, the equation has been quite simple: if

-you have a strong engineering team
-your problem is reasonably well understood
-you can reasonably manage your managers

(note that I said "reasonably" and not "perfectly" in both of the latter two items)

then less process always wins. The right things get done, priorities are basically ok, people are basically productive. Anything that's in the way is, well, in the way. That goes for Microsoft Project, random web tools, and index cards with a system.

This is not a revolutionary point, though it's worth remembering when you have the privilege of meeting those top requirements.

Beyond the bluster, predicted paranoia, and straw man attacks inside Steve's posts here, that seems to be the main point. It is perhaps a valuable one.

Charles,

Customer collaboration over contract negotiation

Yeah, that really works. What programmers need, more in life, is to start dealing with the customers more and to not worry about getting paid.

Actually, you are right. Delivering what the customer specified initially instead of what he wanted leads to worrying about your income eventually. No employee has a problem with immediately changing the work when the boss says so (instead of sticking to the old order). External suppliers have, but the problem here is simply the contract sum which one or the other side thinks needing renegotiation.

And what do you want to say with Russell? That it is logically impossible to state generally that you ought to make up your own mind instead of following rules? Good thing men are not slaves to logic, then.

Adreas,

My point about Russell was that the definitions in the Agile Manifesto stated above were misleading. If there is a manifesto about how to act and that manifesto claims to talk about the need of individuals and the need to not stick to a “plan”, then what does one do who follows such a manifesto if the thoughts of one individual are in conflict with those beliefs? In most cases, people who follow such beliefs are following a “plan”, in the classic sense, so what if not following the “plan” is in conflict with the plan itself, ie. The Agile Methodology.

So my point about Russell was that the underlying definitions that were brought about were a little full of it. You can be an individual, as long as you subscribe to our way of thinking. Plans suck, but if you don’t stick to our plan, then you are a Cowboy. The ideals and the reality do not reconcile.

STIFLE EGOMANIA.

Exactly one?!?

captcha = crqcha

Some dis-Feng Shui-inal ramblings...(I prefer bad puns to anagrams). How about methodologies are tools just like programming languages, IDEs, editors, etc? Most only do well on certain types of projects. Agile works well on highly seperable, shallow problems that amenable to casual user verification. The church of agile wants to apply it to all problems and it simply isn't capable of solving complex, highly interdependent problems.

Cheers,
Dave

It looks like that Google folks have the longest comments/articles I'd ever encountered. Either:

1. They have a woderfull model that makes 10 people doing work of 100 by multiplying their skills.

2. Google had(!ve) a great techology and marketing strategy to suck a lot of cash from investors/advertisement and now throwing all this cash freely into the heads (pockets) of overexcited programmeers that are not capable on using reasonably readable English (not that I whant to cut anyone's part of the body, but offering this opportunity in public is really a bad taste!).

Don't take me wrong, I admire Google of being first reasonable challenge to MS - but I hope neither Page nor Bryn will through this god-like speech and spend that amount of thime typing it (nad, NO, I don't expect them to offer parts of their bodies to be cut in case they need to do things they considered wrong).

3. It really sucks that gmail has me PERSONAL email context related advertisement. How'd u know they don't send copies to NSA/FBI/AttorneyGeneral/KGB?

Poor Mike. If the post is such a steaming pile, why on earth would you allow it to ruin your day? You know that's just your choice right? You can choose to think of Steve's post and allow it to piss you off or you can choose to move onto something else that makes you happy. That's kind of what the post is trying to push I believe.

Think for yourself.

Check out one of Steve's previous rants:
Bambi Meets Godzilla

Here, he's more thoughtful than his anti-Agile rant. Ok, attack the Agile-istas but leave Agile alone! Kent Beck sounds reasonable in this conversation:

Kent Beck - An Agile conversation

Steve's rant is bringing out all the Agile-haters and creating new ones out of people who just appear to be bad coworkers:

"Nicolas said...
I'm wondering, should I kiss your ass or send you my Résumé ?

I've just been given a special "non XP" position (read : cowboy along the XP team, think of Jean Reno in Nikita) for not being a team player enough (read : "I don't give a shit 35 hours a week, my weeks are between 20 and 100 hours depending on the mood"). Thanks you for fighting for my freedom.

I though I'be fired for not beeing XP-capable. By pushing things like : "people over process" you make management teams get back on the earth."

Huh? I thought one of Agile's principles was "people over process": "Individuals and interactions over processes and tools".

I'm reading about Agile and it doesn't look like the religion he makes it out to be, but a handful of good practices. But I'm just learning it from a book and not from one of these Agile-istas he's ranting about.

I'm re-editing my last post:

"Ok, attack the Agile-istas but leave Agile alone!"

If your problem is with the Agile-istas and not Agile then leave Agile alone. Otherwise, feel free to PROPERLY criticize Agile. :)

Pat :
I've spent 4-5 months beeing culpabilized, people over my back trying to fold me to enter into the quiet stiff process. I though I should resing, but for a reason I can't figure, they felt more important to keep me collaborating than going out. All this because "I'm not a team player" wich is obviously true, as it is true for at least 50% of the world population. But resources I economised by communicating less were spent learning my stuff : computer science.

Moreover, I think some practices we have (tight control over people, "design sessions" where the boss leads ...) are not from any XP books, but rather in Robert Sutton's one, in the "bad management practices" sections.

Eek!

I do believe that we have gone beyond tolerable limits of religious fervour and into the realm of the doomed:

What's all this about us non-agile (OK, I'm arthritic) developers missing the ... "long-term benefit of some of its best ideas (unit testing is helpful in many cases)"?

Gosh. I'm so glad that I have this stack of cases where unit testing is of no benefit at all. In fact, I believe that any maniac who insists on unit testing, for any reason at all, is a sure-fire witch and should be burnt at the stake.

... which should be a lesson to all Agile programmers. Except that XP didn't invent unit testing, and to their credit, don't focus on it as a core philosophy. (There are around eleven others, depending upon who's counting, but they all have to be present at the same time. This means, for example, that having "unit testing" without having a "customer" does not make you Agile.)

This is worse than snake-oil. This is turning into the Childrens' Crusade.

Res ipsa loquitur, and many thanks for the chicken joke.

A quick search gives me MAMMON EXPERT RIGGER for "extreme programming". Coincidence?

What is really essential for good software development?

To me it's only one thing:
Look around at what you do and what's really happening. Think hard how you could improve. Try it.
Repeat...

To me this is what agile is all about.

There's no better place to run when your you-know-whats are on the line than Oklahoma. Although you should avoid dark dirt roads in order to protect other parts of your anatomy...

just a joke, I'm Okie and proud to be.

Nice post.

Nice posts steve. I look at superstition in a whole differnt way now haha. But if everything we think, that is not proven by science is superstition, then where does that leave religion? Just a thought.

Cant wait till you get wyvern's server back up by the way.

Hi Steve,

Good post; you've raised awareness and caused people to feel and think.

Re: static styping, have you read Gabriel Garcia Marquez's 1000 Years of Solitude? There's a great scene in the village of Macondo where everyone starts to forget what anything is/does, and so people start putting little tags on *everything*: "This is a cow. It produces milk. This is how to milk the cow..."

Thanks again for the post. Cthulhu F'taghn!

Edward Ocampo-Gooding

Thanks for the great dialogue here, Steve. Some interesting stuff all around.

One of my takeaways has been to avoid letting any product development process become religion. The dogma that agile, or xp, or waterfall, or joe's devprocess, is the only way to do things -- and following it with blind faith -- is a fallacy that companies I've worked with seem to fail to understand.

Yahoo had an interesting course, which I experienced first-hand. No real process when the company first started, which worked great. Once the bottom fell out, we went to some pretty religius waterfalling approaches. Once we slowed down to the speed of a brown slug, with Goog eclipsing us, we went to Agilee whole-hog. Every step of the way, it was beat into the teams that you must develop products this way or they will not launch -- even when we didn't know the process fully, and had to hire outside Agile Priests or McKinsey Bishops to help the lowly product teams learn from their wicked ways. Maybe that's more of a sign of desperation than anything, but it doesn't seem dissimilar from other friends I talked with at places like eBay, Netflix and a host of other smaller online companies.

Since then, the start-ups I've worked with have tried to swing somewhere in the middle of the pendulum. I like how you've characterized the Google environment, as it seems to take some of the best elements from a variety of philosophies.

I hope it's a good lesson to other folks that they should adapt and adopt to what's best for them. That doesn't necessarily mean Google or Agile or Whatever is bad -- just to remember to shrink to fit.

YES it isn't good to follow Agile methodologies blindly.

But there ARE good ideas in Agile. At least reading about Scrum/XP might give people some ideas they may want to try out in their own team.

You talk about Agile like its all a waste of time and doesn't work at all - but at the same time what you described about how Google does things itself includes some of the same ideas in Agile like being "lightweight on processes" and "adapting to needs of the team".

Its like for example Religion A has many teachings, one of the teachings says meditation is good for your mind. Person A is a follower of Religion A so he does meditation. Person B says Religion A is trash, doesn't work, doesn't believe in following it, but at the same time Person B likes to do meditation which he learned from somewhere else - he doesn't even know Religion A teaches about meditation because he never really practiced Religion A.

Now Person C has never tried or heard about meditation before. He has just heard about Religion A and is a little curious. He reads Person B's blog that Religion A is trash, is a waste of time - so Person C stops persuing learning about Religion A and goes back to Religion Waterfall. Too bad for him that he didn't get to learn about Religion A because if he did he would learn about meditation and it would have been a great part of making his life better even though he wouldn't like some of the other ideas in Religion A so wouldn't have followed all of Religion A. He would also have told many of his co-workers about how meditation is good. Instead he tells his co-workers that Religion A is a waste of time and so they all go back to Religion Waterfall.

So basically, just trashing Scrum/XP like you did isn't doing any good but probably is causing more harm. Anyone can write a post trashing Agile (but admittedly probably no one could have wrote it as crazily as you did).

And even though following an Agile methodology blindly isn't a good idea, but there are good ideas in there that can expand thinking about project management just by reading about it.

Forcing a religion on someone else is bad I agree, but if people are smart enough they would learn to choose the good teachings that apply to them from the religions.

And sometimes, for people for some reason need to follow a specific religion by the letter, it cou;d be that Religion A may be better than Religion Waterfall. Science can't prove it (or hasn't proven it yet) that followers of Religion A on average are happier with their lives than Religion Waterfall. But some people who have tried both can give an idea.

For example, if you know more people personally that converted to Religion A from Religion Waterfall than from Religion Waterfall to Religion A .. then maybe you could draw a conclusion. :D

Ummm, that last part should have read:

For example, if you know more people personally that converted to Religion A from Religion Waterfall than to Religion Waterfall from Religion A .. then maybe you could draw a conclusion. :D

Chanon, are you suggesting this is a one-way rule of thumb ;-)

Either way, I don't think it would be wise to draw any conclusion from that. Any more than it would be wise to draw a conclusion from the number of people following religion A vs religion B.

If you take look at the waterfall process you'll see that it contains lots of "agile" ideas too: like involving the customer, prototyping, feedback, and iteration.

The original paper that became "waterfall" is here:

Paul,

Alright, yes maybe you can't really draw conclusions from that.

Maybe the Religion A's priests are just better at converting people.

But the point still stands that both Religion A and Religion Waterfall may have good teachings, so dismissing any of them before actually trying to understand them might not be smart. And focusing on the bad points of the Religion and then dismissing the whole Religion as useless doesn't do much good.

For the people who don't want to waste time with religions anyways .. well no problem :)

I'm just saying that I agree that following religions blindly is bad but sometimes religions are useful because they have teachings that *smart* people can choose to adapt to their own life.

Just to add to the "spookiness"...if you use "The Agile Manifesto" you get "Negotiate Fishmeal".

Scary indeed!

*pokes Steve in the ribs*

Hope you haven't got bloggers block again, no posts for over a month. I love it when people actually think on what they do instead of simply following the rules. Remember rules are not meant to be followed blindly. They're meant to be followed after you decide they are actually good. And even then you need to think about ways to improve them without making them overly complex.

Steve, you're missed.

Perhaps just post holiday recipes until you are unblocked. "Deep fried yams with plum sauce is always a favorite at the family table", etc.

Then you can do something really foolish like declare that only complete morons use imperative programming (though admittedly that's still not as inflammatory as your poking the Agile guys with a stick).

Anyways, I hope you and yours have a happy holiday period.

Naaah ...
Just keep poking the scumbags with a pointy stick.

Or have you been relocated to a concrete pile supporting the Loop in the agile version of Chicago? (Which I believe is on Interstate 44, right by Lake Arcadia. Last time I was in Oklahoma, there was a wonderful German restaurant which would probably cook your gonads in a really nice, satisfying cream source and let you have them as a last meal before passing you on to the, ahem, contractors.)

Not that I'm criticizing agile methodologies, or indeed Oklahoma, of course.

What was that crap about "agile with a big 'A'"? Have I missed something? Is there another movement on the way here? I mean, I did get rejected for my last contract job for "knowing the technical side of the job inside out, but we don't feel he'll be able to get up to speed on the agile process."

Hee hee.

Teeny question here: if it takes too long for a neophyte/member of another religion/albino dwarf addicted to clove toothpaste to get up to speed, does this make the process agile?

Or does it make it Agile?

Res, nunc et, loquitur ipsa.

(RIP HST)

OK, one last question.

How many agile programmers does it take to screw a light-bulb in?

at least 2 they have to stick to pair bulb screwing :)

'They just work hard, they stay lightweight, and they ship great stuff'.

Sounds like agile to me...

Index cards and suchlike are an implementation detail. They're handy because you can rip them up if you get the requirements wrong and move them around if the priorities change. Most ThoughtWorks projects also have an electronic copy, because that's just common sense. A good implementation of agile looks remarkably like common sense. Do more of what adds value, and less of what doesn't. Reflect, measure and repeat. Job done.

kathy said...

at least 2 they have to stick to pair bulb screwing :)

Kathy, I found a coupla possible other answers (just grazing around those wonderful, wonderful agile websites):

* Two. One always leaves in the middle of the project.

* It's hard to say. Each time we separate the bulb into its modules to do unit testing, it stops working.

Or, my personal favourite, mainly because I just made it up:

* None! Pair programming, 5x3 cards, The Customer, Stand-Up Meetings, YAGNI, drool drool drool (OK, I'm getting bored here) ...

I See The Light! It Emerges! It makes no sense, and is totally undocumented, and will drive maintenance programmers crazy, but It Emerges! (Cue Creature from the Black Lagoon.)

It also tends to work off a Bulgarian wattage, using a Hungarian threaded notation, and requiring a twenty-five pin socket. But that's cool.

As in, room-temperature cool.

(You can set the most part of that to a disco beat from the '70s, which I guess kinda underlines the point.)

Thanks, Kathy -- I needed to get that off my chest.

Doom to the Agile Manifesto!

Interesting article but I agree with Patrick that there is no proof or anecdotes of what and why in Agile doesn't work but yes religious zeal in implementing what you think is agile can be bad because there is a lot of stuff subject to interpretation and saying your interpretation is the right interpretation is always problematic.

I am amazed how no one has mentioned Life Cycle of a Silver Bullet, which is an excellent article explaining what agile is going through and how Google Method is best kept unpublished.

I would strongly urge everybody to read the above mentioned article.

You got a lot of guts being featured on Agile Mafia.

You seem to not control your bloger's block syndrome. What a pity - I'm waiting for a new article :)
However I totally disagree with your point about agile - looks like you just don't want to know anything real about it. this holy war thing is fun however.

And I'm glad there are places on this Earth where there's no calendar pressure - thank you for showing the light :)

Take your time, get comfortable, do it when you're ready....but don't leave us hanging forever! :)

In light of steves untimely death, I Have created a tribute. My heart goes out to his familyd
http://tributesteveyegge.blogspot.com/

By the way, in new C# (3.0 for the moment), there is quite clever (imho) approach to the problems of static type systems. It emulates a huge deal of DL's by the means of type inference, automatic collections, anonymous methods/classes etc, but in the context of a given method only. It seems that in this context DL-like approach is really useful (read: time-saving, both in programming and reading programs), while on the class level static approach does better.

I think google adwords used scrum
check this out

http://stormcoders.blogspot.com/2007/01/scrum-tuning-lessons-learned-from.html

and this
http://www.shmula.com/159/scrum-at-yahoo
The New York Times published an article comparing Yahoo! and Google’s products and their development times. It was an interesting read. In that article, the Ash Patel, Chief Product Officer at Yahoo!, mentioned Scrum as a method used to reduce development time:

What the Times doesn’t say is that Yahoo! is now 18 months into its adoption of Scrum, and has upwards of 500 people (and steadily growing) using Scrum in the US, Europe, and India. Scrum is being used successfully for projects ranging from new product development Yahoo! Podcasts, which won a webby 6 months after launch, was built start-to-finish in distributed Scrum between the US and India) to heavy-duty infrastructure work on Yahoo! Mail (which serves north of a hundred million users each month). Most (but not all) of the teams using Scrum at Yahoo! are doing it by the book, with active support from inside and outside coaches (both of which in my opinion are necessary for best results).

Meanwhile, Yahoo says it is now trying to emulate Google’s faster method of creating products. Like most big companies, it used to develop software by first creating a comprehensive design that defined how features would be written and tested. Instead, it is now trying what is known as a scrum method, where it will plan, build and test parts of a product every 30 days.

This comment has been removed by the author.