4 ms·
No. In college, I followed the c2 wiki where XP was crafted, out of the ashes of the Smalltalk-based Chrysler payroll system. It was a bunch of practitioners
by parasubvert 13y ago
No. In college, I followed the c2 wiki where XP was crafted, out of the ashes of the Smalltalk-based Chrysler payroll system.
It was a bunch of practitioners sick of being told by MBA-types (or modelling "architects" that couldn't code) of the proper way to write software.
Almost everyone in modern software development has been impacted by XP, if you think through some of the practices that almost no one mainstream had heard of or were discussing in 1999 until XP:
- Customer is on the team (Often the biggest factor in IT projects)
- Test driven development (now BDD)
- Continuous integration (now Continuous delivery and Devops)
- Design improvement (refactoring)
- Small releases (now "Lean Startups")
- Planning game (or estimation without Gantt charts and WBS)
Detractors focus on the controversial practices like pair programming as if they were lunatic. Or on consultants making money flogging a crap methodology. I don't think consultants could make money on XP back in the day - it was too foreign and extreme.
Agile was born off the fumes of XP, to give people methodological freedom while agreeing to the same principles. This unfortunately enabled legions of consultants to invent their own whatever-the-hell method for their client and subject employees to it. But it also helped some teams to deliver faster and higher quality than they would have otherwise.
- gaius 13y agoXP - to actually be XP - is no less prescriptive. Either you follow the 12-step program, or you're a heretic. Now small-a agile is certainly a good thing - but like Nietzsche I am suspicious of any attempt to systematize what should be organic.
- benjiweber 13y agoOne of the XP rules is "fix XP when it breaks". I dispute that it is prescriptive. Retrospectives provide a mechanism for changing process.
- Jtsummers 13y agoFor the curious [1]. Which brings up a point that I try to make with colleagues about any method/process. If you apply them blindly you might get lucky, but you'll probably get terrible results. They have to be modified to suit the personalities and capabilities and needs of the team, the company, the industry. [1] http://www.extremeprogramming.org/rules/fixit.html http://www.extremeprogramming.org/rules/fixit.html