Sex, software, politics, and firearms. Life's simple pleasures…

Main menu

Post navigation

Culture hacking, reloaded

My last four days, at the Agile CultureCon split between Philadelphia and Boston, have thrown more new ideas and techniques at me than I’m used to encountering in a normal four months. Or more. It was very challenging and exciting, the more so because I was immersed in a culture at some distance from those where I usually hang out.

The organizers (Dan Mezick & Andre Dhondt) and various friends (now including me) are launching from agile software development into new ways of organizing work and communication that dynamite a lot of common assumptions about the necessity of power relationships and hierarchies. What makes this really interesting is not the theory but the working examples. They’re not dealing in vague platitudes, but in methods that can be taught and replicated. (And yes, I will describe some of them later in this post.)

Nobody in this crowd thinks politically (or at least if they do, it doesn’t show); it’s all framed as ways to fix corporate cultures to make them more productive and happier. But what this was, underneath occasional freshets of vaguely new-agey language, was a three-day workshop in practical anarchy.

Pulling me in was the result of a nearly last-minute brainstorm by Dan Mezick, who is a leading figure among agile-development coaches in the Boston area. He approached me by email a few weeks ago reporting that he’d read How To Become A Hacker and considered it (his words) “foundational wisdom”. It gave him the idea that my experience of articulating and shaping the hacker culture might be useful information for what the would-be culture-hackers at the conference are trying to do.

(Dan didn’t know when he decided to invite me that the hacker-culture connection with agile development goes right back to agile’s beginnings. I had been invited to the Snowbird gathering where the Agile Manifesto was hammered out in 2001, and if not for a schedule conflict I almost certainly would have been one of the signatories myself. My occasional conversations with people like Kent Beck and Martin Fowler have since confirmed that other signatories were pretty strongly influenced by my articulation in 1997-1998 of of what the hacker culture had been doing. So, in one important sense, the hacker culture is part of agile’s ancestry.)

Their initial problem, as Dan puts it, is that so far agile development hasn’t been scaling very well. Techniques like unit testing and TDD, design by story, pair programming, scrum, planning poker and the like have amply proven themselves at the small-group level (up to, say, a dozen developers). Properly applied they do boost the hell out of the effectiveness of product teams. But evidence that they can be scaled up effectively to much larger projects or coordinated enterprise-wide development is lacking. Dan sees a lot of snake oil being peddled under the “enterprise agile” label, and he doesn’t like it.

So what has gone wrong? Why aren’t agile techniques scaling? Takes no genius to diagnose that problem: agile, trying to scale up from the bottom, collides with the top-down-imposed conventional corporate habits of death marches, rigid hierarchy, and waterfall planning. And loses, because the imperatives behind all that sludge are wired too deep into the culture of most corporations to be displaced by mere productivity improvements, however dramatic.

Where Dan and Andre and their friends get radical is in the cheerful conclusion that conventional corporate culture needs to be blown up – or, to put it more diplomatically, re-engineered to enable higher productivity. Where they get effectively radical is that they’re not willing to stop at slogans and exhortation. Instead, they want to write a how-to manual. How to meme-hack your corporation so it’s not wasting most of its energy on authoritarian bullshit and territorial games, how to make it a place where more value is added and people are happier. Oh, and where agile techniques can be applied throughout.

The conference had some noise and nonsense in it, including one fuzzy-sweatered wack-job who wasn’t ignored as roundly as she should have been. But with that filtered out, the theme was very clear: we need to learn how to change the cultures that hold people and productivity back so they’ll stop doing that. This is a larger mission than simply “make agile development work” and potentially a far more transformative one.

The contrast with the hacker culture is interesting. We opted out and formed our own big tribe, with members in but not of the places where they work; later (after 1997) we built bridges back to the corporate culture from outside it. The agile people were, in a way, braver than us – they never left and never formed a big tribe of their own; instead, they’ve been trying to reform the corporate/institutional world from within, operating as a whole bunch of parallel microinsurgencies with some common ideas but not a lot of sense of shared purpose.

Well, up to now, anyway. Dan asked me in because he thought the experience of the hacker culture might be relevant, and – it is. Because what this conference showed me is that the agile folks are beginning to struggle their way through the same transition we went through between 1990 and 1998. Once again, I see a culture that had been diffuse, mostly unconscious and local trying to wake up. Thinking about shared purpose; moving from craft practice to intentional technique; asking itself questions about what the things it does mean in a larger context – and beginning to find answers.

Dave Taht (aka Dave in my basement) was along with me on this anthropological journey and disagrees. He thinks these people are at a much earlier stage corresponding to us in the 1970s, because they don’t yet have as much shared cultural capital to build on. He’s got a point; they don’t have a significant common corpus of slang or jokes or hero stories – there’s no agile-culture analog of the Jargon File or the joke RFCs.

For good or ill, they also have no equivalent of the Free Software Foundation. That is, there haven’t been any previous attempts to create a unifying “what we’re about” that failed to take on the majority of people in the culture. Their one previous try, the Agile Manifesto, was a success – at least at naming the movement and articulating very broad principles. In effect, they got their “agile” equivalent of the term “open source” a decade before fully understanding their mission, rather than after that awareness had already almost fully developed as happened with us.

Still, the parallels are powerful. People there ate up the material I brought about advocacy tactics and meme-hacking and leadership (about an hour and fifteen minutes split over three 25-minute sessions) and clearly thirsted for more. My value to them was that I had already successfully pulled off culture hacks on a large scale at least twice – and could explain how I had done it.

Since my blog audience mostly knows that story already I won’t rehearse any of it here, but rather write about what I learned from the interaction.

I’ll start with something relatively simple. I got enough exposure to agile techniques during this conference to figure out something I’d been puzzled about for a while. I knew that the Agile Manifesto described values very similar to those of the hacker culture. I also knew that wasn’t accidental. I also knew that some agile practices – notably unit testing, test-driven development, and design by story – have easily been absorbed and naturalized by hackers. But others (pair programming and scrum, for example) have not been. And I have wondered why this is. The separation between hackers and agile developers seems largely a matter of historical accident, so why has the cross-fertilization not gone further?

The answer is not complicated and perhaps I should have seen it sooner. Most of the agile stuff is designed to improve the quality of the interactions within teams that meet face to face and have stable membership. The hacker culture, on the other hand, evolved to support remote teams in which partipants commonly never meet each other and membership is unstable. The agile techniques we’ve picked up on are precisely those that can be applied in our communications environment.

When I describe the typical workflow of an open-source project to agile-development people they tend to look like they’ve been hit by a truck. Almost all communication by email and IRC, with only sporadic use of even voice phones? People join projects and cooperate for years without ever meeting each other? We take drive-by patches from people who pop up once, then disappear and are never heard from again? How can that possibly work?

One thing that got through to them and stimulated a lot of talk and thought is the idea that how far inside you are on a project is defined by whether and how frequently you push commits to the project’s repository. More generally, we nowadays define membership in the hacker community basically by who is pushing commits to public repositories (yes, I noted that the criteria used to be fuzzier and there are some interesting exceptions and edge cases).

Several people responded to this by observing that the agile community doesn’t have this objective kind of in/out criterion because it doesn’t have shared projects, and mused that maybe it needs to start some.

But let’s get to the fun stuff. Some of the techniques the agile people are playing with and thinking about now make me wonder “how can that possibly work?” But I’ll start with the easy ones.

The problem all of these are aimed at solving is that coercion and power hierarchies waste huge amounts of time and energy, block an organization’s ability to learn, do needless harm to people, and squander resources that could otherwise be turned into productive outcomes. Evil is not just evil, it’s stupid! Not being stupid pays off, therefore not being evil pays off. These are ways to not be stupid.

Before the conference, Dan educated me about the Core Protocols. This is a set of communications practices to be used among humans that are designed to suppress a lot of the bullshit and primate politics that commonly get in the way when we try to do and decide things together. I got to see and use them both by email with Dan and face-to-face in groups at the conference.

The Protocols have at least two results. One is to create psychological safety, largely by guarding the right of participants to opt out of a transaction rather than be subjected to power trips or other forms of manipulation. Another is to make it easy for participants to model each others’ intentions and desires. The consequence is that groups using them can learn more effectively and make good decisions more rapidly.

The Core Protocols are very clarifying – that much is obvious to me even from limited exposure. One of the authors calls them “software for your head”, and they’re a building block that can be used with other kinds of software for your head, including ways to re-invent how we organize groups larger than will fit in a single meeting room.

Two of these got an airing at the conference. One, actually the less radical one, is a kind of organizational design called sociocracy. Yes, I know the name is horrible – actually, its English-speaking practitioners agree it’s horrible, but think they’re stuck with it for historical reasons. No, it’s not socialist or anything like socialist; in fact, a core part of the theory is concerned with using free-market incentives to reward efficient collective behavior.

A sociocratic organization consists of a set of interlocking working circles. The rules of interaction within circles are constructed to support egalitarian behavior within the circle, suppressing normal primate-political bullshit through means recognizably similar to the Core Protocols (they also include interesting procedures for supporting consensus-based decision-making). There is expected to be a control hierarchy among the circles, but the damaging effects of the power relationships that sets up are mitigated by a clever hack called “double linking”.

Each circle has an operational leader appointed by the parent circle it reports to, and each circle has an elected representative to the parent circle, but they are not allowed to be the same person. The pass-requirements-downwards function is disconnected from the report-problems-upwards function.

There’s a Discordian maxim called the “SNAFU Principle” states that true communication is only possible between equals – because where there is a power asymmetry the inferior will tend to tell the superior what the superior wants to hear, and the superior will tend to tell the inferior only that which preserves his superiority. In hierarchical organizations the SNAFU effect leads to a progressive disconnection of decision-makers from reality as information passed up and down the command chain becomes progressively more distorted by this effect.

Sociocratic double-linking is a clever pre-emptive strike against the effects of the SNAFU principle. The existence of a reporting chain separated from command authority at least removes much of the normal incentive for command chains to distort information passing between levels.

There’s still hierarchy in the system, though. The more radical path is to flatten the firm entirely – no bosses, no subordinates, not even sociocratic circles. And this is just what two of our presenters, from a firm called Morning Star, told us about.

At Morning Star, they practice “self-management”. Your job isn’t defined by who you report to, but by your commitment agreements with your colleagues. In effect, everyone in the firm has horizontal contracts with other firm members. The business runs on a painstakingly-maintained process model and objective performance indicators. The contracts include performance targets, and your pay is tied to how you meet them. More details in the book Beyond Empowerment, which lightly fictionalizes the history of Morning Star and then presents supporting factual case studies.

Morning Star must be doing something right – it’s the top company in its market niche and robustly profitable. And it’s far from what most people would think of as the best case for radical experiments in corporate governance – capital-intensive manufacturing using a lot of unskilled seasonal labor. But perhaps the most intereresting thing about Morning Star’s organization is that they’ve scaled it past the Dunbar Limit.

Sufficiently small groups with sufficiently good leadership can make almost any theory of organization work. But human beings have only a limited ability to scoreboard the behavior of acquaintances, which tops out at the Dunbar limit of about 150. Above that size more formal lines of authority and obligation become necessary. Or so goes the theory, anyway. Morning Star seems to be a counterexample.

I shall finish my report by noting that I learned a new way to think about prophecy. Well, a specific and interesting meaning of the word “prophet”, anyway. This was at a keynote address by one David Logan, who has spent years studying what he calls “tribal leadership”. His “tribes” are social networks, usually (though not always) below the Dunbar size limit.

In Logan’s analysis, a firm – or an entire society – is best understood as a mosaic of interlocking tribes, each with its own microculture. Logan distinguishes five culture types or stages: Stage 1 = “Life sucks”, Stage 2 = “My life sucks”, Stage 3 = “I’m great (and you’re not)!”, Stage 4 = “We’re great!”, and Stage 5 = “Life is great!”. The whimsical titles conceal some heft; see Logan’s TED talk about how tribes evolve (or fail to evolve) from the highly dysfunctional Stage 1 (normally found only among criminals) to the high-creative Stage 5.

In Logan’s model, a “prophet” is a person who moves a tribe from one stage to another by – and this is what caught my attention – “preaching the inevitability of values-based change”. If this were a movie, tension-inducing music would be starting to play…

To do this, the prophet first has to understand what the tribe actually wants. Tribes form in the first place because of an alignment of values. The alignment may be around something trivial like rooting for a sports team, or something functional like doing a particular job, or something more profound like a shared aesthetic or political idea.

The point is that a tribe does, at least epiphenomenally, want something. But (the music is getting louder) not every tribe knows what it wants. The shared desire and values may be partly or wholly unconscious, and point to something larger than the tribe understands. The prophet’s job is to reflect the tribe’s values back at it in such a way that it changes stage – wakes up and starts to function at a higher level.

At this point in the exposition hairs are beginning to stand up on my arms. It only gets spookier when he talks about tribes organically growing their own prophets out of themselves to transform themselves – exactly expressing the feeling I’ve often written about that the hacker culture created me in order to be able to see itself better.

And what does a prophet do to transform the behavior of a tribe? He tells stories about what it was, is, and might be. He reminds people in it who they are. And this is the point at which I’m muttering I’ve been here. This guy is talking about me. I never thought of myself as a “prophet” before – I preferred to leave that kind of imagery to RMS – but it is undeniably true that I’ve written mystical poetry for hackers.

Huh. So other tribes create their own equivalents of “ESR”, do they? Interesting. Never thought about that before either. Perhaps we could form a mutual-support group for extruded polyps of tribal consciousness. Or something.

I was so energized by Logan’s keynote that when Dan Mezick told me he had an open session slot because a speaker had canceled it, I stormed into it and delivered an extended rant on practical prophecy 101 – not just what a prophet does but how to do it. With major tactics like giving things the right names as a source of power. Dave Taht recorded at least part of that talk; might be it will make it onto the net.

There’s lots more I was originally going to write about – the epic of the party bus that linked the Philadelphia and Boston halves of the conference, for example, and some of the very colorful people I met, and the exciting beginning of our attempt to create a culture-hacker’s manifesto which I think might someday be considered as important as the Open Source Definition.

But, on reflection, this report has been mostly about ideas, and I think I want to keep it that way rather than wandering further off into personal narrative, no matter how interesting that might be.

So I’ll finish by repeating that I think these are really important ideas. I’m glad I was there for this beginning; there are, I think, many more discoveries ahead of us on this path.

We may yet succeed in culture-hacking not just individual institutions but society as a whole into something saner, kinder, less hierarchical, and more productive on all levels. It’s worth a good hard try, anyway.

71 thoughts on “Culture hacking, reloaded”

Are you familiar with Valve (Steam) game company? Either you or someone else posted a link to a piece by their economist which turned out to be interesting. They appear to have a functioning non-hierarchical structure.

As a person who works in Enterprise software development, one of the big things that I see working against the Agile model is the requirement to Get It Right The First Time. Agile focuses a lot on repeated iterations. The problem is that in the enterprise market, a lot of customers do not and will not readily install incremental patches. We have customers who we are lucky if we can persuade to take an outage to replace faulty hardware. Unless the software is breaking all the time, they probably won’t upgrade but during a short window once per year … maybe. In those cases you need to have well-defined releases which can be thoroughly tested by sadistic QA people. We have customers who never upgrade their software for the ~5 year lifecycle of the hardware. All of this lends itself to waterfall-ish models (or at least well-planned releases with opportunities to fine-tune along the way).

The only way to push Agile back into the development chain is if we can persuade customers to update their software every 2 weeks. For web-based applications (like Google Docs) it’s pretty trivial as the customer just gets the new software the next time they log in. For corporate-hosted applications, it’s a much bigger deal. Microsoft went with the Patch Tuesday model for software where they release an update once per month. How many 24/7 businesses actually install and reboot their servers in order to be running the latest software? How often does an Oracle admin install/restart their server to be running the latest patch? (I don’t actually know how Oracle’s server works – they might be able to support upgrade-in-place).

Until we have an answer for that type of consumer, Agile’s going to find a hard time getting traction in a lot of larger software firms.

Ah, David, I’m glad you checked in. I particularly wanted you to learn about Morning Star. Appears they’re run by anarchocapitalists. Of course their internal system is, essentially, contract libertarianism.

Should you have a chance, I highly recommend a look at the late Eric Berne’s works. Berne was a psychiatrist, who had a pop sci best seller in the 60’s called “Games People Play”, and a couple of more in-depth followups called “What Do You Say After You Say Hello?” and “Beyond Games and Scripts”. The Stages 1-5 above relate to some of Berne’s work. (If you don’t recognize the behavior of some folks you’ve encountered in the various games Berne documents. I’ll be quite surprised.)

“The point is a tribe does, at least epiphenomenally, want something. But (the music is getting louder) not every tribe knows what it wants. The shared desire and values may be partly or wholly unconscious, and point to something larger than the tribe understands.”

And here I’ll point to Berne and to the late Edward T. Hall, an anthropologist doing research in comparative culture. Hall and his research partner George Trager discovered that they had to create a comprehensive theory of culture to meaningfully describe and analyze what they were comparing. See Hall’s books “The Silent Language”, “The Hidden Dimension”, and “Beyond Culture” for the results. I consider Hall’s work absolutely critical, and a great many things fell into place when I read it.

In Stultum facit fortuna I argue that consensus always winds up being dominated by the evil and the insane.

Planning Poker appears to be designed to avoid, or at least minimize, the dynamics I describe, to expose the wisdom of crowds rather than the madness of crowds.

The solution I suggested in that post is that always one guy should make the decision, and be responsible for the consequences, but in software development, that solution leads to the notorious death march.

While planning poker cannot entirely cure the propensity of consensus to be dominated by the evil and the insane, it avoids the problems that ensue with straight consensus. With straight consensus, the evil manipulate the Overton window, and no one wants to argue with the insane. With planning poker, the Overton window cannot be manipulated, and people are forced to argue with the insane.

This cannot cure all the problems with consensus, but it should substantially reduce the tendency to death marches one gets if one does not use consensus.

The Agile movement wants to improve productivity by decreasing hierarchy. Company owners want to increase extractable profits. They need a hierarchy to extract these profits.

These two aims generally are in conflict.

Hacker culture does not have this conflict, as there are no “owners” who can extract profits. Cooperative enterprises and communes do not have this conflict, but they often dissolve because their members decide to cash their profits and liquidate the company.

I am afraid the Agile movement will not be very successful in abolishing hierarchy in conventional companies with external (share) owners.

I notice that what I call “Manipulating the Overton window”, advocates of planning poker call “anchoring”, and suggest that anchoring generally occurs as an innocent accident, rather than a manipulative conspiracy.

The problem all of these are aimed at solving is that coercion and power hierarchies waste huge amounts of time and energy, block an organization’s ability to learn, do needless harm to people, and squander resources that could otherwise be turned into productive outcomes. Evil is not just evil, it’s stupid! Not being stupid pays off, therefore not being evil pays off. These are ways to not be stupid.

I’m about half way through, and i’m GOING to read the rest before posting this. But i wanted to articulate this thought before it slipped away.

This paragraph sums up why i don’t give a crap about the “free as in speech” evangelism.
I don’t really care if i’m “free”, i’m not even really concerned if someone uses my work to make money. I do care if they use my work and then try to stop other people from using the work i gave them but ultimately i figure that that is somewhat difficult (ignoring patents momentarily) if the other people in question can get the work from me(i.e. github/sourceforge etc…). I care because it’s stupid.

Winter on Tuesday, September 18 2012 at 3:45 am said:
> I am afraid the Agile movement will not be very successful in abolishing hierarchy in conventional companies with external (share) owners.

This article led me to read up on the movement, and it seems to me that the measures described are very much in the interests of shareholders, in that all of them look to me like anti lying and anti conspiracy measures.

Some of the measures recommended by the agile movement, such as dual reporting, are reminiscent of Stalinist measures to prevent the Soviet bureaucracy from freezing up, strangling itself in lies and red tape. They worked, and were generally in the interests of the top of the hierarchy, i.e. Stalin.

When a large company has committees, it rapidly develops a second secret hierarchy, invisible to board and ceo, and only partially visible to those at the bottom. This second secret invisible hierarchy generally pursues goals that are in conflict with the interests of shareholders.

Thus, for example, a committee meets to assess the cost and value of various features. Chances are, the first guy to speak will propose entirely crazy values and costs. If I go along with him, this will harm the company, but probably will not harm me – because if it would harm me, I would not have been invited to the meeting in the first place. If, on the other hand, I disagree, speak up, and propose more realistic values, I am likely to be subject to reprisals from the invisible hierarchy.

“Planning Poker” prevents this shenanigan, by making each person issue an assessment before he has heard any of the others.

Suppose I discover a committee to which I am not invited is coming up with crazy shit that has a large effect on me and my ability to perform my job. I speak to my boss, who gets me put on that committee. I very rapidly discover I am seriously unwelcome on that committee. From the moment that they hear my job description and department I am marked as an enemy infiltrator, and should I persist in showing up, quite grave reprisals follow.

The organizational principles proposed as part of “agile” reduce this sort of thing, prevent certain shenanigans that are seldom in the interest of the shareholders.

As a person who works in Enterprise software development, one of the big things that I see working against the Agile model is the requirement to Get It Right The First Time. Agile focuses a lot on repeated iterations.

As a person who walks the fine line between getting people to understand that Agile is not infallible magic and that Agile is mostly as good as it is because it is tailored to address all the things that we have learned routinely cause cascading failure in waterfall, the biggest thing i see working against IT in the enterprise is that they have this crazy belief that you can “Get it Right The First Time”. The only time it’s even plausible is when you’ve got a team that has already built N versions of the same software before, in which case i have to ask “Why the hell are they writing it again?”.

The incredibly well documented fact about software development is that the requirements you get from the user will almost certainly be wrong. Hopefully they’re wrong on small things that are easily fixed, but wrong is still wrong. If you then spend the next 6 months to a year developing a “Design Document” so you can “get it right the first time” you’re going to achieve two things. A) your design document WILL depart so far from reality that your chances of actually delivering what your users want will shrink to practically 0 and B) what your users want will change because the only business that remains static and unchanging for even 6 months is one that is winding down in bankruptcy.

There ARE things to “get right the first time”… you should model your ideas around concepts that are entrenched into the users language (e.g. if you’re writing accounting software that isn’t talking the lingo of double entry bookkeeping, you’re doing it wrong) and this language must be ruthlessly maintained. You should be sure of who all of your principle stakeholders and their general requirements are (e.g. if your client has an auditing requirement and you don’t know about it, your failure is a fait accompli). Everything about what “thing.exe” does when they double click on it is subject to change.

The problem is that in the enterprise market, a lot of customers do not and will not readily install incremental patches.

Absolutely. But this pre-supposes that your product release schedule and your developer release schedule are one and the same. Sure that’s the optimum case but then reality imposes its will (as it always done). You mention a QA team right? In lieu of a real customer making actual money off of a feature, you’ll probably need a test and support team.

The fundamental goal of agile here is that you don’t develop software for two years, do a month or so of user testing and then release. Instead you continuously verify, preferrably with real users but otherwise with someone who has a vested interest in people actually using the software, that the software is moving towards fitness for purpose.

@JAD
“This article led me to read up on the movement, and it seems to me that the measures described are very much in the interests of shareholders, in that all of them look to me like anti lying and anti conspiracy measures.”

If all goes well, the interests of the shareholders and the employees in production (eg, engineers) are aligned. Then, I assume that Agile can be used by the owners and the productive section of the employees to increase productivity.

However, there are many times the (short-term) interests of the shareholders and employees are opposite. In such cases, any attempt to reduce hierarchy will be met with strong opposition from higher management. And that view even ignores middle management (PHB’s), whose interests can be opposed to both the production part and the shareholders, and who can be expected to oppose any attempt to flatten the organization.

“The web’s hit the big time in a way few of us imagined possible. So as people who make websites, you’d think we’d be celebrating our repeated successes in designing amazing user experiences, as the organizations we work for become increasingly successful. But many of us have noticed a problem in our work: the user experiences we deliver don’t meet our expectations. Here’s the problem: organizations are the context for our work, and when it comes to the web, organizations are broken.”

One of my Rice professors, Gilbert Cuthbertson, used this in political science as Myth, Value, and Power (MVP). Said it could explain everything and it can.

In this case the Prophet is building a Myth, a common story, that leads people up the chain from Life Sucks toward Life is Great, in pursuit of a common goal. That’s what creates power. Power in business as well as political power.

What was Ted Turner other than a prophet? What was Thomas Watson Sr.? Steve Jobs.

The trick — and this is where you can be really useful to the world — is getting inside the process where the Prophet’s vision can be realized most efficiently.

Of course, since most high value-add production today is of intellectual capital goods, rather than manufactured goods, chopping down hierarchies using technology is essential.

@esr:
“I stormed into it and delivered an extended rant on practical prophecy 101 – not just what a prophet does but how to do it. With major tactics like giving things the right names as a source of power.”

I don’t recall you speaking to this subject before. Could you tell us more about “giving things the right names as a source of power”? Is there an ESR essay online somewhere that explains this?

Two instances of prophets who come to mind: Gene Rodenberry and Robert Heinlein. Both of them, in my childhood, gave an image of Where We Have Been And What Life Could Be that’s stayed with me ever since. Of course, there were many others — pretty much *any* science fiction with worthwhile protagonists can have this role. Which is, come to think of it, why I’ve read science fiction since I could read anything at all.

>Could you tell us more about “giving things the right names as a source of power”?

One of the most powerful things a prophet can do is identify something his tribe unconsciously does, or strongly desires (or both), and give it a name. The name then becomes three things: a focus of all that pent-up emotional energy, an object of reflection, and a rallying cry.

I’ve done this at least twice, with “open source” and our now-marked use of the term “bazaar” in opposition to the term “cathedral”. Arguably I had previously done something similar by giving lots of readers of the Jargon File permission to assimilate themselves to the preexisting term “hacker” if they chose to make the kind of self-commitment to their art that many of them wanted to make anyway.

As I noted at the conference, a prophet in Dave Logan’s sense of the term gives people permission to be idealists – he allows them to opt in to a bigger, more beautiful myth than the one they’re living in. The way I have used and promoted terms like “hacker” and “open source” does that, though it took a long time for me to become aware of the effect and understand its importance. I was growing right along with the rest of us.

I emphasized “right names” because of our unfortunate history with the term “free software”. It pointed at ideology and anti-commercialism rather than transparency, openness, and highest craft practice. That made it the wrong name, because it didn’t correspond to what hackers actually valued. That mismatch created pent-up but unconscious demand. When I proposed the right name (or at least a better one) the switchover in majority usage came astonishingly fast, basically within about four months in 1998. And produced a huge surge of energy and confidence that we’re still riding today.

There is a large functional anarchy that is still growing after 70 years. Alcoholics Anonymous
has twelve traditions, one of which starts off “AA ought never be organized…”. Another states “The only requirement for AA membership is a desire to stop drinking”.
Personally, I find the “never be organized” bit immensely attractive, along with the inclusive membership requirements.
Any effort to extend culture hacking beyond software ought to take a look at the framework behind AA and some of the other 12 step programs based upon it.

As a person who is forced by my corporate overlords to use Agile, I have to say, I fucking hate it, and so does everyone I work with.

My take on Agile? There are “good” customers, and “bad” customers.

Good customers will sit down and work with you to determine precisely what their needs are and articulate it, even though it’s not what they’re used to, even though they don’t like having to re-answer the same question 5 different ways so you can dig out the reality from the vague. Then you make a plan, implement the plan, and move on.

Bad customers will refuse to do this, for whatever reasons. They’ll insist that you work without a plan, and as you create failure after failure, and rebuild the same thing over and over, you’ll slowly work towards the final result, a disorganized, unmaintainable clusterfuck, at which point everyone will abandon the whole thing.

Every day you work with a bad customer, trying to be “Agile”, you train yourself to put blinders on, not think ahead and make yourself stupider.

The smart thing to do is to FIRE that bad customer.

But, people are greedy, and some of those bad customers have an awful lot of money. So, we apply the “Agile” process. We know it’s stupid, we know it creates a clusterfucked mess and damages our future as problem solvers, but we want the money, so we do it, to the detriment of all parties involved.

And that, in a nutshell, is Agile development. A formal set of rules for how to separate short-sighted idiots from their money.

Indeed it is. So, er, in what way is this problem with agile? When you know you’re in jammed in a box by stupidity and greed, why blame the methodology the greedheads forced on you?

Customers stupid enough to insist you work without a plan are real revolving sons of bitches, unpleasant no matter what the direction of approach. If you were doing waterfall their “specification” would drive you mad as surely as their lack of same is doing so now.

Bad customers will refuse to do this, for whatever reasons. They’ll insist that you work without a plan, and as you create failure after failure, and rebuild the same thing over and over, you’ll slowly work towards the final result, a disorganized, unmaintainable clusterfuck, at which point everyone will abandon the whole thing.

If agile is being forced down on you from on high, i’d rejoice because it means you have someone you can feed back protocol failures too who may actually care without having to get a 3 day conference and bad experiences to convince them.

With what little i know about your particular case, i’d probably point out that most forms of agile require an “acceptance test” before you can start working on a feature. This test will probably be specified in an ad-hoc way but should be (at least) enough for a minimally competent software tester to at least track the happy case (because everyone forgets to specify the negative tests). If you combine that with YAGNI and frequent releases you should end up with at least a two week plan.

I do agree that “bad customers” or more interestingly “customers who won’t engage” definitely make any form of agile challenging. However i’d take a personality issue over a reality issue any day of the week. And BDUF has serious reality issues.

JonCB said: If agile is being forced down on you from on high, i’d rejoice because it means you have someone you can feed back protocol failures too who may actually care without having to get a 3 day conference and bad experiences to convince them.

I suspect more realistically (and inferring from his tone) that what’s being forced on him is something called “agile”, without the concomitant commitment from the people doing the forcing, to work with it. (And quite possibly in the face of, as he said, Customers that don’t want their service provided that way, and are making his life hell when he has to deal with them.)

(Where I work, we don’t call our process “agile”, but we do a lot what “agile” is.

And I’d rather have that than what I suspect Ian has, which is more or less the reverse – a process called “agile” that apes its form without its essence…)

Ian: any decent hacker with lousy corporate overlords is probably employable enough to get a better job — one that doesn’t insist on catering to bad customers. The hiring market is very competitive these days, in your favor. Is there something keeping you in your current job?

I suspect more realistically (and inferring from his tone) that what’s being forced on him is something called “agile”, without the concomitant commitment from the people doing the forcing, to work with it.

Completely agree. And in fact that’s a common failure case, agile that isn’t really agile.
Having said that I find starting from an assumption of “well you’re not really doing Agile” tends to be counter-productive. Instead i prefer to focus on problems and solutions.

And from my perspective, it’s better to be in a position where upper management wants (at least in principle) this agile thing than where upper management is intent on following anti-patterns that we know fail but perhaps that is a “grass is greener” reaction.

In re. tribalism, the scary thought which comes to my mind is that Obama is the prophet of the Democrat tribe. In fact, that particular function might be the sole reason for his ascendancy, since it’s difficult to pin any other talents upon him. (I suppose this is somewhat in alignment with the post turtle description.) The thought that Democrats would choose Obama as their prophet, in order to see themselves better is even more disturbing than his election to high office in the first place.

And, of course, choosing names is part of what we see happening all the time, with rhetoric about ‘fairness’ in which the described outcomes have no relation to being fair at all. I’ve noted this elsewhere, e.g. the demonization of ‘militia’.

This makes me think a bit of emergent behavior. In the tribe, the prophet functions as a catalyst to bring about the emergence of those unconcious ideals.

But this fails your ‘the prophet first has to understand what the tribe actually want’ test, as I don’t give Obama that much credit. But it’s an interesting angle from which to evaluate what occurred 4 years ago, and what’s happening now.

As a person who works in Enterprise software development, one of the big things that I see working against the Agile model is the requirement to Get It Right The First Time. Agile focuses a lot on repeated iterations.

As a person who works in IC development, I can tell you that there is zero disconnect between “Get It Right The First Time” and agile-ish development; in fact, that being agile is one of the things that helps to Get It Right The First Time. Not that management would know any of the buzzwords.

There may be a management disconnect, in that sometimes people don’t like throwing code away, but if you can plan for a prototype that gets refined, you can have a much better product in the same or shorter time.

@JonCB:

As a person who walks the fine line between getting people to understand that Agile is not infallible magic and that Agile is mostly as good as it is because it is tailored to address all the things that we have learned routinely cause cascading failure in waterfall, the biggest thing i see working against IT in the enterprise is that they have this crazy belief that you can “Get it Right The First Time”. The only time it’s even plausible is when you’ve got a team that has already built N versions of the same software before, in which case i have to ask “Why the hell are they writing it again?”.

That may be true for some definition of “get it right” but it’s certainly possible to use agile internally and build something that meets externally imposed specs, and even to have an intelligent conversation with the customer about the specs, and change them in mid-flight, without ever delivering anything to the customer until you have something that will do a reasonable job of satisfying his immediate needs.

If this were not true, then you would not see ICs developed nearly as quickly and correctly as they are. IC development might look like a waterfall model from the outside, but inside most successful teams, there’s a lot of stuff going on that any hacker or agile programmer would find refreshingly comfortable, including continuous integration, a solid regression suite including both unit and system tests, and a well-used issue tracker with intense management scrutiny and thoughtful triage of every issue.

Also, although changes and problems found late in development aren’t exactly “welcome,” they are certainly acted on appropriately, because nobody wants to spend the time and money to tape out a chip that’s not going to do anything useful. In general, you won’t find chip companies finishing up a project just to say they did.

But there are also death marches, usually imposed by external real-world constraints, which could be anything from having the prototypes to the customer in May and production in July so the customer can hit the Christmas shopping season, to just hitting the shuttle, because it’s going to be three months before the next one in the right process.

My first reaction to the description of Morning Star was, “this sounds like Valve!”

There’s an article by realtime 3D graphics guru Michael Abrash, which includes a lengthy description of how Valve operates. It’s the subsection marked “Valve is Different.”http://blogs.valvesoftware.com/abrash/valve-how-i-got-here-what-its-like-and-what-im-doing-2/
The system he describes is even more radical than the one you describe for Morning Star. Executive summary: there are no job titles. Desks are on wheels, and you just move your desk over to whatever group is working on a problem that seems interesting to you. You can even start a whole new company initiative if you want to, like Abrash did for wearable computing.

@esr : great post, & really important. I guess I’ll have to read it a few more times before understanding it fully – there is a lot in it. I don’t think I deserve the “hacker” title. Yet.

I don’t know in the USA, but here in France, the suits are gaining more & more power. More & more microcontrol over our asses. More taylorism in computer developments(and everyy reader of this board knows how “well” it works).

Recently, a friend of mine accepted a job of “technical specificator”. He regrets bitterly. His job? reading the functional specifications, reading the code, writing pseudocode, giving pseudocode to the “coder”(who translates “move the value of b into a, & add 1” into “a = b+1”). Of course, he is not allowed to run the code to check hypothesis. He is not administrator of its computer at work, therefore he cannot cheat with this rule.

Everything obviously goes wrong, people are demotivated, project goes into hell. And suits think that the work need more formalization & divide between steps.

I’ve also heard of programmers required to give feedback of each day of work of each project they’re working on – with a 15 minutes accuracy.

Once again, I don’t know for USA. But France is really badly ill on that topic. Especially as we have here a long tradition of abstract thinkers, the standard answer to most problems are “we need to preplan everything more accurately” and “you should think more before doing anything”(especially when 5 minutes of tinkering is more enlightening than 6 months of abstract thinking).

And the people who made the difference between agile in name, & agile in facts, are right on target. The lone time I was not far from agile(I made regular reports “here is what I have, what is wrong?” & had insightful answers), another team was practicing “agile”(the website team). They were the only ones in the insurance firm, and did make a lot of damage in most other projects – including mine. Thanks to the very good feedback loop I had, I was right on time. Then, I had to divert 2 weeks of my time to adapt our old code(and the new one, but that was easy) so that they could make their “sprint” on time. IMHO, agile implementation in a firm should begin with teams that do not heavily depend upon other teams. website depends heavily upon, well, nearly everything else, contracts(us), customers, marketing….. very bad choice for an agile introduction.

esr > “Instead, they want to write a how-to manual. How to meme-hack your corporation so it’s not wasting most of its energy on authoritarian bullshit and territorial games, how to make it a place where more value is added and people are happier.”

Did they discuss the opposite approach at the conference? Start with an agile development team with a good idea, and let them start up a corporation. On the face of it, growing a small corporation that doesn’t have corporate politics seems easier to me than transforming a big corporation’s culture from below.

In response to Garrett’s assertion that getting it right the first time is not agile’s focus, I gave an example of IC companies, and gave the thesis that agile is a valuable tool for getting it right the first time. It occurred to me that putting a lander on another planet is something that REALLY requires getting it right the first time.

Sure enough, a bit of googling shows they at least claim to use agile methods to do this:

Thinking about this, and thinking about el slapper’s post makes me realize that many of the core tenets of agile programming are deeply ingrained in a fairly mainstream part of the American culture. I think this could be part of the explanation of why we seem to have no trouble going to Mars and other countries haven’t yet gotten that ability together.

I once worked for a large corporation that tried to implement agile development in all the wrong ways, and for all the wrong reasons. By dictating from above, “This is how you’re going to develop software from now on”, they created a gigantic rigid structure, complete with hierarchical teams designed to ensure that the “agile” process was followed the Right Way. From a cultural standpoint it fell flat on its face, as those of us who understood agile methodologies knew that what we were being forced into was far from agile development, and those who didn’t understand agile methodologies (and therefore didn’t recognize that what we were doing was NOT agile development), quickly became disillusioned with the whole idea of agile development and saw it as a barrier to getting real work done. The predictable end result was a bunch of supposedly “agile” teams who couldn’t get any work done because of the barriers put in place by management, and management blaming the lack of progress on developers because we weren’t following the process and “doing agile” the Right Way.

Cultural change has to come from the bottom, not the top. The only way to migrate a team of software developers to an agile methodology is for a group of developers to get together and decide on their own to approach it that way (and then get management to buy into it); it doesn’t work when management tries to dictate how software development “should” be done.

Joel Spolsky, though not affiliated with hacker or open source culture(s) or the Agile school – quite the contrary maybe, seems to have a reasonably good idea about how to let developers be productive (keep them happy and assume they know best) and what the role of management should be (create the right circumstances and get out of the way).
I’m thinking that if you’re really going to have a go at re-engineering a corporation or business culture, he might have something to contribute.

Oh crap! Not another massively thought-provoking, and thus time-consuming, ESR post! Like I don’t have enough to do already! Oh well, here goes …

A few points of possible interest, starting with bigger ideas.

I am highly sympathetic to Libertarianism, consider myself such socially, and have even occasionally voted such as a protest, but have always thought it too ideal and impractical for useful governance. It is seldom used for organizing organizations [sic]. Consider organizations such as many religions, non-profits, businesses (corporate, private), paramilitary (fire-police departments), and military (army, navy, air force). All of them involve matters of life-or-death. These can be organizational (eg., end of a business or department thereof, an army or unit thereof), or personal (eg., members being killed in dangerous conditions such as by fires, criminals, wars). Few organizations are organized via Libertarian principles, such as via markets and democracy. It seems that the more the issues involved are life-or-death, and demand speed, the more rigid the hierarchies grow.

Thus, hierarchy seems inevitable, and as efficient as things can get.

The possibility that alternatives may be possible, and may be created-engineered, and may even be implemented and adopted, is most exciting. I hope this occurs. Go team!

I am not bright enough to think too originally about culture hacking.

I long assumed that, since hierarchy seemed inevitable, the only way to fight it was to reduce it somewhat, via raising productivity at the lowest possible organizational levels, starting with individuals, then small teams, then larger teams, then departments, etc. Many productivity enhancing means-tools-methods exist, including programming languages (www.vpri.org) that are higher-level or more consistent, libraries, many software tools, groupware (www.dougengelbart.org), total quality management, re-engineering, lean production, just-in-time methods, Agile methods, etc.

For years I have wondered if pair programming would be, or was already, implemented electronically for remote use. This could likely be done easily, as a simple form of groupware, via modified Internet Relay Chat, or some similar means. ESR could likely do this sort of thing in a weekend ;-) after all, the first Wiki, by design pattern and Extreme Programming expert Ward Cunningham, was only 400 lines of Perl code.

Once again, I don’t know for USA. But France is really badly ill on that topic.

Edsger Dijkstra once wrote a paper called “On the fact that the Atlantic Ocean has two sides”, which was about the difference between the generalized European style of computer science, which favors formal thought and planning over the generalized American style, which favors quick results.

Alan Kay responded with a paper called something like “On the fact that much more software is written on one side of the Atlantic Ocean than the other”.

I once worked for a large corporation that tried to implement agile development in all the wrong ways, and for all the wrong reasons.

Hell, I’ve worked in places where troublesome employees who annoyed management were disciplined for not following Agile practices enough.

As far as I’m concerned, Agile has become yet another management buzzword. It may have been started by earnest people, but they need management buy-in to make it catch on. As long as management has that veto power, management owns Agile.

As a developer I hate methodologies. Any time you “adopt a methodology” you are practicing more taylorism. There are good practices which you would do well to adopt and adapt to your project, but you are a fool to think that any given package of practices can just be slotted into your organization or team, rigorously enforced, and automatically increase productivity or quality. The whole notion of “Agile methodology” strikes me as a shellgame, akin to the TV typewriter hack, to trick management into thinking that the practices of a group of high-powered developers working at/near the quality plateau, are indeed some sort of taylorist rulebook so they’d shut up and leave the developers alone. The trick worked, but the biggest side effect I’ve seen is that management has a new cudgel to wield against developers. “Step into my office, we need to have a talk about how you’re not Agile/Extreme/Scrummy enough.”

Just want to mention that a guy named Ricardo Semler wrote about flattening corporate hierarchies in ’93 in a book called _Maverick_. Having read said book (and its sequel) it was the first thing I thought of when I read the Valve article(s) that have been floating around. I’m glad to see these ideas catching on ( though I get comments like “..but back in the real world..” from my corporate overlords when I mention them). Hopefully they will come to dominate.

It’s interesting that a better way to get stuff done (Agile) somehow has led to discussion of better organizational structure. I’m not sure the CXX types will be all that open to having their jobs redefined by the engineering group.

“I don’t know in the USA, but here in France, the suits are gaining more & more power. More & more microcontrol…”

I suspect the problem is the lack of entrepreneurial culture in France. Here in the USA, it’s often the small startups that implement stuff like this, and it gets carried over to larger organizations after its proven. Even within a large firm, there can be an intrapreneurial skunk works that experiments with stuff like this while remaining below the corporate radar.

I remember reading that a few years ago France wanted to create a Silicon Valley-style region, and they invited some key players over to explain how it was done. As soon as it was explained to them that a very high percentage of startups would fail, and that this was necessary and healthy, they lost interest.

I am highly sympathetic to Libertarianism, consider myself such socially, and have even occasionally voted such as a protest, but have always thought it too ideal and impractical for useful governance.

American Libertarianism is a nutjob sept of conservatism, without the religious component but certainly with all the attendant xenophobia and the secret desire to see the world go to hell before it adopts a different ideology. Alexei Panshin notes how, for instance, while the USA was the only nation to have ever used nuclear weapons, and while it was flanking the USSR with missiles and sending spy planes into its aerospace, RAH still pigheadedly supported nuclear testing (and the attendant irradiation of Americans) out of sheer Red Scare paranoia. In Starship Troopers he even tried to argue that radiation is “good for us” (cf. current libertarians’ arguments about global warming, or the tobacco industries’ arguments about cigarette smoke).

If you had seen Berlin in the late ’60s you would understand the need to keep up the pressure on the Soviet Empire until their internal contradictions destroyed them. The Soviets turned entire countries into maximum security prisons.

As for Hiroshima and Nagasaki, well, read up on the invasions of Iwo Jima and Okinawa. Nobody wanted to invade the Japanese home islands. The military projected something like 1,000,000 U.S. casualties. The casualties on the Japanese side would have been worse, and largely among the civilian population. Those two bombs *saved* Japanese lives. The Japanese needed a symbol they could surrender to. We gave them two.

In Starship Troopers [Robert Heinlein] even tried to argue that radiation is “good for us” ….

I think you overstated RAH’s case – he (through one of his characters) mentioned that on a planet with almost no background radiation, the natural mutation rate was so low that evolution occurred very much slower, such that the indigenous lifeforms could be trivially out-competed by transplants from Terra. His character then surmised that humans who settled there permanently would begin to evolve slower (and would be out-competed by their fellow species members, in umpity-ump millennia).

None of this is an argument that “radiation is good for you” – merely that [a] a certain amount is inescapable, and [b] it is one of the drivers of evolution. At most you could call it a “necessary evil”.

>>None of this is an argument that “radiation is good for you” – merely that [a] a certain amount is inescapable, and [b] it is one of the drivers of evolution. At most you could call it a “necessary evil”.

It also presumes that radiation is *the* primary driver for mutation.
I don’t have hard info on this, but I don’t believe that is correct.
Granted, high levels of radiation will cause high levels of mutation, but I don’t see evidence that very low levels will bring mutation rates to near zero..

Having been on the business end of a bunch of Enterprise Agile methodologies, and also working in small teams who work extremely agilely, I think esr is missing something.

Agile, at least where I have seen it applied in the enterprise, is focused on the fast iterations and getting it done. This can work against you. For example, Agile is fabulous at uncovering cultural cruft that is often the project’s undoing, but in truth, its iterations are too fast to actually deal with the cruft. And sometimes and enterprise’s cruft is the real target of the program anyway. By the same token, an agile methodology too often delivers great artifacts, but they get lost as the enterprise promoters of agile wipe the white board clean at the end of every iteration.

You might point to this and say, well, these are all problems of the culture of big enterprise. But I think that there are some issues with Agile as well. It is difficult, for example, to manage durable artifacts in agile from iteration to iteration – lore keepers, product managers, and architects are products of an enterprise culture precisely because they bring order out of the top down chaos. But at least in the programs I have seen, there is no counterpart on the Agile team. And the problem with scaling can be summed as this – sometimes these huge artifacts are actually the viable work of Agile teams. But the next Agile team can’t take it as step 1, they need to re-conceive of the entirety of the first team’s efforts before they are ready to move on. Right back to Waterfall. This happens a lot when dealing with large scale integration projects or when there are multiple deploys going on.

Well, there is documentation, you say? Not when most Agile groups are invested to go fast, die young, and leave a good looking prototype. See lore keepers above.

Most enterprises exist to define a widget and then wring every miserable cent that they can from that widget. The problem with Agile, from that perspective, is that the team is on widget3.0 when the rest of the enterprise doesn’t know how to market widget1.0. The point is that once Agile defines a way to systematically leave breadcrumbs for other Agile teams and for the rest of the enterprise, then Agile can scale. Not until.

The real answer, of course, is that enterprises can’t be Agile. Insofar as they can benefit from Agile, they have to do so in very focused ways – special projects, tiger teams, product teams, etc. And having transitioned from massive enterprise scale to small start up, I can tell you, there are a lot of very good reasons why the big don’t eat the small, but the fast eat the slow.

Which leads us to esr’s real point, I think. Can Agile companies become enterprises? Can they have scale and presence and make an impact? Because 12 guys in a basement don’t do that in the business tribe. Parenthetically, that is probably the most important question in this economy right now.

In the big corporations, these things come and go. The employees quickly learn to go to the meetings, nod their heads, and wait them out. Usually, the head cheese imposes them on the company just to justify his exalted leadership.

“The thought that Democrats would choose Obama as their prophet, in order to see themselves better is even more disturbing than his election to high office in the first place.”

Obama took the great mass of them from Stage 2 (“My life sucks”) to Stage 3 (I’m great [and you’re not, and racist/bigoted/dumb also.]). Unfortunately for them, those outside the tribe watched the spectacle with horror. Practical politics demands at least Stage 4.

Too bad the Republican party is the epitome of stage-3 thinking. Christian Whites are great, everybody else is not.

Meanwhile, what is “Yes, We Can” but a terse statement of stage-4 values?

Which party’s learders are calling for bipartisanship and common ground? Which party’s leaders are strenuously advocating factionalism, divisiveness and hate?

That said, Obama’s character is marked by a sunny disposition combined with a sense of entitlement to power, and this disturbs me greatly. Obama doesn’t believe in his stated liberal principles — or his own marketing — enough to make the hard calls.

“Meanwhile, what is “Yes, We Can” but a terse statement of stage-4 values?”

Jeff, seriously?

He’s certainly run on stage-4 values. But that turned out to be a complete fraud – he’s governed at stage-3 since attaining power. Delivering division and a stage-3 ego boost to his supporters is about the extent of his accomplishments.

Thinking about this, and thinking about el slapper’s post makes me realize that many of the core tenets of agile programming are deeply ingrained in a fairly mainstream part of the American culture. I think this could be part of the explanation of why we seem to have no trouble going to Mars and other countries haven’t yet gotten that ability together.

I’m not sure NASA would necessarily be on board with the idea that they were typical representatives of mainstream American culture. Or that getting Curiosity up there was no trouble.

An acceleration devoutly not to be wished. I always tended to blame their, er, focus on the ISS. And scientists love what they’ve been doing with robots, whereas mainstream American culture (or at least the aspect of it which Congress experiences and translates into funding) seems to be a bit “meh” about it.

Making it look easy is always hard. Making it look hard is sometimes easy. Is that your only point?

I’d like that way of thinking reach Big corporation in France. I don’t ask for full “agile”, as it begs for more control by the middle-hierarchy about what agile is. Just, sometimes, you have to trust the programmer(and also the specificator & the tester) for getting the job done. That’s what computer taylorism does not allow. If I look back upon my career, I’ve done great things each time middle management didn’t try to control my work(with one exception, I’m not perfect). I also like Joel Spolsky way of thinking(on that topic), it suits my professional experiences.

“The Soviets turned entire countries into maximum security prisons. ”

Though not that false, that affirmation is not completely true. My wife grew up in communist Poland, and though freedom was low, the main problem was more “how to eat enough & find toilet paper in adequate numbers”. My father in law did own a ZX spectrum & later 2 IBM PCs, before the wall fell down. I will not explain people reading here how much freedom those tools can bring to one’s mind. It was known, & he had no trouble for that. There was censorship, but that cannot compare to today’s North Korea.

Prison? Obviously. Maximum security? Nope. Hey, they didn’t even put to prison Karol Wojtyla building its forbidden church in Nowa Huta!

Don’t make me tell what I didn’t tell : communism was a bad thing, obviously (my wife agrees, and she has first hand information about it). Just, exageration makes your point weaker.

Aw, c’mon. You can’t pin anywhere near all the blame on Obama for this.

Most of the blame goes to the Republicans, who play the role of “bloodyminded obstructionists” when a Democrat gets into office and starts, you know, advocating liberal policy. The 2011 budget crisis, during which the Republicans effectively held the funding and operations of the U.S. government hostage, is one example of this sort of behavior.

Not sure that follows. Unless of course, the definition of “bad” is “any policy promulgated by any Democrat, even if it was originally proposed two decades ago by a Republican.” Then your statement works.

I do take it that the drive is towards more productive, quality, happy software building.
I also believe this is an alternate software methodology being dandied about.

My challenge to all methodology dandies is : Show that the methodology is viable for 50% of what are called non-Softwareplatform-framework, business projects; with not more than three consecutive days of feverish code hacking of more than nine hours (in stealth or in office) in a month, with a content that could meet business acceptance – with a team having 80% members at 70 percentile industry competencies. I am not even talking of deadlines or timelines. That is when you have a method that works.

I also believe – the whole stance in spite of all exhortations, disclaimers, possibly ignorant adamancy – IS POLITICAL.