3 ms·

XP, the real catalyst to agile, was born out of the Smalltalk hacker community with Kent Beck and Ward Cunningham in particular. They're the furthest from me

XP, the real catalyst to agile, was born out of the Smalltalk hacker community with Kent Beck and Ward Cunningham in particular. They're the furthest from methodologists I could imagine. The only professional methodologists on the agile manifesto, for that matter, were Alistair Cockburn and maybe Jim Highsmith. And even they were all about preaching for less paperwork & process. The rest were in the trenches software team leads or (at worst) software consultants like Martin Fowler.

gruseom 16y ago
I'm talking about people who prescribe rules for others about how to make software. In this sense, XP is thoroughly methodological. I know something about the Smalltalk history. It doesn't change the point: there is a gulf between people who live by selling prescriptions about how to make software (writing, consulting, training, and so on) and people who live by making software. This is the fundamental problem with Agile, not dilution-by-becoming-mainstream as the OP and others say. Why does the gulf arise in the first place? I think it's because in the dysfunctional corporate software economy, programmers are low-status and there is a ceiling on how much money and status can be accrued in that role. One way to break the ceiling is by becoming a high-end consultant, writing and speaking and so on. If you pull this transition off, you can charge thousands of dollars a day and be esteemed. The trouble is that now you are no longer making software for a living. You are in the world of hype and ideology. Your customers are people inside corporations who write cheques, a constituency that has nothing to do with the culture or practice of software. This has consequences: it casts you adrift, it dulls the mind, it encourages bullshit. Then the rationalizations begin: I'm trying to make the system a little better, etc., I can have leverage by reaching more people this way, etc. This path may lead to billable hours but it puts one at risk of creative rot. The fundamental mistake of Agile was trying to improve the broken world of corporate software by selling to it rather than competing with it.
- parasubvert 16y ago
  Ahh, I see the disconnect, based on your last sentence. I basically don't think it's a mistake to improve corporate software from within. It's not going away. And there are many decent programmers who will work in that environment because of a lifestyle choice. I also think you have an incorrect interpretation of history: the folks who did XP were contractors on a _project_, and actually writing _code_. Yes, they published books afterwards, but continued running _projects_ and writing _code_ afterwards. Finally, I think the culture and practice of software has a lot to do with those who write cheques, since that's in the end what funds it, like any engineering endeavour. Unless you're speaking of software-as-a-hobby.
  - gruseom 16y ago
    It's not a mistake except insofar as it's impossible to any significant degree. It's only self-deception (encouraged by consulting cheques and/or ideological blinders) that says otherwise. At least that's been my experience through careful observation. I'm not speaking of software (only) as a hobby but of the startup community of hackers building and running their own companies. Look around you here. There are many people practicing what the word "agile" actually means, as opposed to these process doctrines. If the Agile processes are really a better way to build software, why don't most startups bother with them?
    - jdlshore 16y ago
      How do you know they don't? Mojang Specifications, this year's hottest new game studio, uses Scrum. The Lean Startup movement combines customer discovery with Agile practices. That said, my experience is that development practices have little to do with startup success (unless they're overly rigid or formal, in which case they get in the way of success). They affect organizational scalability and long-term maintenance costs, which fall in the category of "nice problems to have" for a new startup. I do see ideological blinders here, but not the ones you meant.

gruseom 16y ago

I'm talking about people who prescribe rules for others about how to make software. In this sense, XP is thoroughly methodological. I know something about the Smalltalk history. It doesn't change the point: there is a gulf between people who live by selling prescriptions about how to make software (writing, consulting, training, and so on) and people who live by making software. This is the fundamental problem with Agile, not dilution-by-becoming-mainstream as the OP and others say. Why does the gulf arise in the first place? I think it's because in the dysfunctional corporate software economy, programmers are low-status and there is a ceiling on how much money and status can be accrued in that role. One way to break the ceiling is by becoming a high-end consultant, writing and speaking and so on. If you pull this transition off, you can charge thousands of dollars a day and be esteemed. The trouble is that now you are no longer making software for a living. You are in the world of hype and ideology. Your customers are people inside corporations who write cheques, a constituency that has nothing to do with the culture or practice of software. This has consequences: it casts you adrift, it dulls the mind, it encourages bullshit. Then the rationalizations begin: I'm trying to make the system a little better, etc., I can have leverage by reaching more people this way, etc. This path may lead to billable hours but it puts one at risk of creative rot. The fundamental mistake of Agile was trying to improve the broken world of corporate software by selling to it rather than competing with it.

parasubvert 16y ago
Ahh, I see the disconnect, based on your last sentence. I basically don't think it's a mistake to improve corporate software from within. It's not going away. And there are many decent programmers who will work in that environment because of a lifestyle choice. I also think you have an incorrect interpretation of history: the folks who did XP were contractors on a _project_, and actually writing _code_. Yes, they published books afterwards, but continued running _projects_ and writing _code_ afterwards. Finally, I think the culture and practice of software has a lot to do with those who write cheques, since that's in the end what funds it, like any engineering endeavour. Unless you're speaking of software-as-a-hobby.
- gruseom 16y ago
  It's not a mistake except insofar as it's impossible to any significant degree. It's only self-deception (encouraged by consulting cheques and/or ideological blinders) that says otherwise. At least that's been my experience through careful observation. I'm not speaking of software (only) as a hobby but of the startup community of hackers building and running their own companies. Look around you here. There are many people practicing what the word "agile" actually means, as opposed to these process doctrines. If the Agile processes are really a better way to build software, why don't most startups bother with them?
  - jdlshore 16y ago
    How do you know they don't? Mojang Specifications, this year's hottest new game studio, uses Scrum. The Lean Startup movement combines customer discovery with Agile practices. That said, my experience is that development practices have little to do with startup success (unless they're overly rigid or formal, in which case they get in the way of success). They affect organizational scalability and long-term maintenance costs, which fall in the category of "nice problems to have" for a new startup. I do see ideological blinders here, but not the ones you meant.