1-star reviews of 'Extreme Programming'

http://www.amazon.com/Extreme-Programming-Explained-Embrace-Change/product-reviews/0201616416/ref=cm_cr_pr_top_recent?ie=UTF8&filterBy=addOneStar&showViewpoints=0&sortBy=bySubmissionDateDescending

by narfz • 13 years ago

105 133 13 years ago

amazon.com

Glide4• 13 years ago

I'm reading the reviews and I realize that I don't have the background and years of experience to understand the software development world as it was in the year 2000 (I graduated in 2006).

I get some of it, because of war stories. But I know I'm missing a huge piece of it.

Like when did some of the older practices come about? Was it in the 90s? Late 90s? 80s? Are most of the reviewers curmudgeons that that watched the SDLC landscape change before their very eyes as their certifications lost value?

nickbauman5• 13 years ago

If you mean Waterfall, the term was adapted from civil engineering, which of course made a lot of sense for software (sarcasm). One of the earliest papers on the process was in the 70s by William Royce where the term waterfall was used to describe software development at its worst.

svachalek• 13 years ago

The "spiral" model was documented in 1986 and in common practice long before Extreme Programming hit the shelves. I never saw a waterfall-like process in use in the 90s except in the DoD. It was never more than a strawman for XP to beat up on. (Edit: On a hunch I just looked up when scrum originated: 1986 as well.)

mariusz79• 13 years ago

Like it or not but the waterfall method does make a lot of sense in software development. It may be useless if you're trying to create another billion dollar useless web app, but is very helpful when you have to create software for mission-critical applications.

Glide4• 13 years ago

The part I wanted to understand more was the culture of workplaces that agile would affect in the coming decade. What created cultures that adhered to waterfall. I find asking, "how did we get here?" fascinating.

Joeri• 13 years ago

It's not just software. All business processes have been undergoing change from top-down to bottom-up processes as people realize those companies which allow good ideas to percolate from the bottom win in the marketplace. The driver here is the internet. It used to be the case that you didn't come into contact with good or bad practices except by working in a place they were applied, but the internet ensures everyone can now read online what works and what doesn't.

walshemj• 13 years ago

I think your looking at the internet with rose tinted glasses business practices go in and out of fashion and some times back into fashion again.

I directly saw this as I worked on the BS5750 standard and saw the rise and fall of TQM

I think you will find that in traditional engineering does stick closer to traditional project planning PERT/TQM and so on as its a lot more embarrassing and costly if a bridge falls down :-)

Its also a lot easier to do in manufacturing is easy you can measure the tolerances on a piston on an engine line and flag thats a defect or not - much harder to do in software.

asdasf3• 13 years ago

Certifications? No, the whole "certified bullshit expert" thing started with XP. Before that people just did their jobs and didn't invent religious practices that had to be adhered to in order to do so.

bguthrie• 13 years ago

There has never been an official XP certification. There is a ScrumMaster certification. I'd suggest that you avoid anyone who claims certified expertise in XP.

And no, people didn't "just do their jobs." Management methodology isn't a new idea.

tmcneal• 13 years ago

PMP certifications were established in 1984[1], and while I don't think the certification itself is nearly as abused as "Certified ScrumMaster", PMI and Six-Sigma are definitely touted as panacea, especially in the enterprise.

[1] http://en.wikipedia.org/wiki/Project_Management_Institute

stonemetal• 13 years ago

Grady Booch first published the Booch method around '91. He merged his stuff with a few other guys to make UML and the Unified Process a few years later. The rise of big process in software was fairly fast. The push back you see is more a misunderstanding, they see it as a transition from no process -> process -> no process rather than no process -> too much process -> lighter process.

Glide4• 13 years ago

Thanks, I never heard of the Booch method before.

So time wise something like UML and Unified Process actually occurred after XP and Scrum?

That kind of changes the timeline I had in my head about this. I almost feel like making something to figure out all of this.

galaktor• 13 years ago

my favorite one so far. from my POV today, if I didn't know this was a one-star review I might mistake it for a positive review :-) (except maybe for the obvious "worst practices" comment at the end)

-----------------

This book advocates extreme coding. It's a disguised way to legitimize "dive-into-coding" with no proper analysis and design. This author advocates little if any comments, documentation etc. He actually states that "design is in the code" and documents get out of date and that's an excuse not to do it. How is that in comparison to the "traceability" principle advocated so strongly by Jacobson and Rumbaugh who believe that the final code should be traced back to the analysis documents (use cases in Jacobson book) He advocates programming in pair instead of code reviews! In short, this book gathers the industry "worst practices" exactly the opposite of OMT, OOSE, RUP etc.

jheriko11• 13 years ago

This author advocates little if any comments, documentation etc.

I'm very much of the opinion that good code self documents, and excessive use of comments and documentation is a crutch for bad code.

Some optimised code might be really incomprehensible without commnets, but its the exception rather than the case. By far my biggest use of comments is to highlight inadequate or rushed code that should be revisited later (i.e. TODO: or HACK: rather than NOTE:).

Don't get me wrong - design and documentation is useful in practice as well as being the 'theoretical ideal' that I think should be striven towards. Diving in and making a mess to fix stuff or diverging from an original design is bad in theory - in practice it is a necessary evil with tight deadlines or when rescuing a project that is already in a seriously bad state - or even when the original design was naive or even impossible because it came from an inexperienced or otherwise inadequate source.

enraged_camel• 13 years ago

>I'm very much of the opinion that good code self documents, and excessive use of comments and documentation is a crutch for bad code.

I'm very much of the opinion that you are very much of the wrong opinion.

"Good code self-documents" is a myth. Most programmers have trouble coming back and reading their own code, much less other programmers' codes. Comments and documentation written in spoken language ensure that the code can be understood much more quickly and efficiently and any misunderstandings are prevented.

matthewmacleod• 13 years ago

I'm very much of the opinion that good code self documents, and excessive use of comments and documentation is a crutch for bad code.

We obviously hear this quite a lot, but I think it's inaccurate - it's bad comments and documentation that are a problem, and comments in particular are often most prolific when they're bad. Comments and documentation often suffer from rot, in that they are not kept current with the code and end up being out of date in short order.

But the fact that comments and documentation can be out of date is a reason to do them better, rather than throw them away. I'm one of those people who typically codes "comment first" - writing a simplified english overview of the steps I expect to take, implementing each of them using real code, and taking a final pass to trim or expand comments as required. So I might start with:

  function doit(){
    // Load data from the input
    // Get the correct records
    // Search for the correct field
    // Output the results
  }

This is followed by implementation:

  function doit(){
    // Load data from the input
    records = Data.load()

    // Get the correct records
    records.uniquify(function(e) { return e.group_id })

    // Search for the correct field
    results = records.map(function(e) { return e.timestamp })

    // Output the results
    print(results)
  }

We've now got stupid redundant comments of the type that cause problems. Rule of thumb for me is to decide if the statement in the comment can be trivially deduced from the code immediately following it. If it can, then the comment can go. If there's some additional assumption—perhaps about side effects or properties of data which might not be immediately obvious—then the comment can be expanded to include this information. So we might end up with something like the following:

  function doit(){
    records = Data.load()

    // Disambiguate records by looking at the group id - records will
    // always be sorted by time, so we can do this to make sure we
    // only get the first in a given group.
    records.uniquify(function(e) { return e.group_id })

    results = records.map(function(e) { return e.timestamp })
    print(results)
  }

Obviously not real code, but you get the point.

In general, I find that working on "self-documenting" codebases is actually rather frustrating - especially when I'm coming in on a new project. There's an absolute load of implicit knowledge about software systems that's contained within the code, and while it should be exposed and made explicit wherever possible, it's sometimes not practical - meaning that "self-documenting" code often seems anything but.

gaius2• 13 years ago

... And they were completely right. Who does "extreme programming" nowadays? It was a cult, not a serious software engineering methodology.

mjolk• 13 years ago

It's an amazing way to bill extra hours as a consultant without being held to any standard of quality :)

atomaka• 13 years ago

Even if Extreme Programming isn't followed exactly, many of the practices that these reviews attack are common in today's development.

asdasf3• 13 years ago

But the very core of XP was that it did have to be followed exactly. That there was 12 specific things you had to do. All of those things were existing things, that people already did. It was precisely the "doing all 12 of them exactly as we say" that was XP. And it was total BS.

diroussel• 13 years ago

I think the essence of extreme programming is still with us.

Have a look at http://en.wikipedia.org/wiki/Extreme_programming

Many of those principles and practices are followed by my team. They don't all suit every project, but many do.

SideburnsOfDoom4• 13 years ago

Who does "extreme programming" nowadays?

Xp compared to the things that came before it, or to the things that came after it?

If you compare the opposite poles of Xp, and the things advocated in those 1-star reviews, the way that a lot of successful bushinesses develop software is a lot closer to XP than "pre-Xp" software methods.

It was a watershed for many. In fact, I would agree that the XP and TDD side of the argument won the intellectual debate.

gizmogwai• 13 years ago

I do. I might be biased as my first work experience was using it extensively (and we were quite successful doing it). So far, it is not rare that I can find mission where people, once the mess cleaned a bit with their current environment and trust established, are willing to give it a try, progressively and in good conditions. The general feedback I got is quite positive.

parasubvert4• 13 years 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.

gaius2• 13 years ago

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

abolibibelot4• 13 years ago

Some of the criticisms are still valid: there's a definite "gossip magazine diet plan" vibe to the book, even if the clean cut from waterfall or iterative process horrors (Rational Unified Process anyone?) was sorely needed.

The criticisms about no metrics supporting the book assertions are valid too (we have more metrics now, though).

That said, a lot of things in this book are now considered good engineering practices, and the methodology guys have come back with a vengeance with the Agile/Scrum/Lean/Whatever waves that filled the blanks left by XP (and ensured a nice revenue stream for pure process consultants).

praptak• 13 years ago

the clean cut from waterfall

...was in fact a strawman. The whole horrible waterfall process was an urban legend: http://postagilist.wordpress.com/2012/06/13/the-perennial-wa...

jheriko11• 13 years ago

yeah... i never heard of waterfall until after experiencing a naive use of scrum and having it referred to as 'the alternative'.

abolibibelot4• 13 years ago

Don't know about the formalization by Royce, but I've witnessed and suffered waterfall in practice - let's call it ad-hoc waterfall if you will - and it was no urban legend.

And on moonless nights I still wake up screaming remembering a RUP project I was involved in around 2000.

"No true scotsman" and all, I know.

SideburnsOfDoom4• 13 years ago

The whole horrible waterfall process was an urban legend

Bullshit.

Source: I lived through it in the early and mid 1990s.

forgottenpass• 13 years ago

Some companies did use it. But even at the time (before Beck's book), it was known in programming literature to be a dumb idea. XP didn't introduce the idea that Waterfall was nonsense, it was just the catylist for it's removal.

parasubvert4• 13 years ago

No one ever read Royce's paper, they just accepted the PMI/PMBOK interpretation of it as sacrosanct.

Which was a gross misinterpretation to this day. We still have naive PMPs running $100 million IT projects in the faux-Waterall style.

Morendil• 13 years ago

I'll just leave this here.

https://plus.google.com/+LaurentBossavit/posts/VBJTGru3PeW

Or this.

http://leanpub.com/leprechauns

alextingle2• 13 years ago

Bullshit x 2.

Not only are there projects where waterfall methodologies were applied, but they are sometimes (gasp!) appropriate.

In the majority of cases, iterative development of some sort is necessary, because the requirements keep changing. Waterfall simply doesn't allow for changing requirements, so it's hopeless in those cases.

But where requirements are stable, waterfall is a reasonable approach. Remember, it had its origins in the big iron days, when vast project teams analysed and replaced existing manual systems. For those projects, waterfall worked.

If you're writing the code for a space probe, or a missile, there's a limited opportunity to iterate once the item is deployed... requirements are stable, waterfall can be a rational choice.

vonmoltke3• 13 years ago

iterative process horrors (Rational Unified Process anyone?)

I lived in that world on a DoD program for 3 years. I still have nightmares.

We also had a customer who didn't want to "pay for the same code twice". That meant signal processing algorithm research had to be done in the operational real-time code, and that we could have one and only one codebase (including branches but not including engineer/scientist working copies). The "experts" from Mitre and elsewhere who were managing us were so clueless they didn't realize this was costing them more and adding more risk than allowing the scientists to do their algorithm development in Matlab and Fortran, then have the engineers turn the algorithms into an operational system. Of course, we still had to have requirements and design documentation up-front before we could implement code, so...

raverbashing3• 13 years ago

This is one of the reasons if I see anything "rational" about a job post I ignore it

MartinCron6• 13 years ago

gossip magazine diet plan

In four words you managed to perfectly encapsulate the problem I have with so much writing about development processes and tools.

It's not good enough to claim to be just incrementally better than what you're probably doing, you need to be the best most super awesome EXTREME thing ever!

abolibibelot4• 13 years ago

I wish I had coined the term, but it's taken from an actual comment: http://www.amazon.com/review/RDZBBO2Q4MI6V/ref=cm_cr_pr_perm...

The 1-star reviews roughly fall in three categories:

    - This is not how proper projects are done.

    - We don't need another cult-like methodology

    - This will vindicate cow boy coders

2 and 3 may have a point.

mathattack3• 13 years ago

I think the EXTREME branding hurt corporate adoption.

bazzargh2• 13 years ago

The reviews complaining about evidence did have a point. At the time, XP was based on experiences at Chrysler implementing the C3 project - which was canned http://c2.com/cgi/wiki?ChryslerComprehensiveCompensation

Though tbh the same could be said of any of the mountains of methodology books we waded through in the 90s. The word 'evidence' appears precisely once in the RUP white paper, and it's not in reference to evidence for RUP itself being effective.

robin22• 13 years ago

Projects can be canned for all sorts of reasons, but from what I recall the people involved in C3 blamed the Chrysler management. Perhaps the latter were more interested in having a working payroll system than inventing the future of software development.

One of the criticisms I remember some people making of XP when it first came to prominence was that it shifted a lot of the hard work of software development onto the customer, or rather the customer representative; certainly, ever since I heard about what happened to the first XP customer representative (see http://www.coldewey.com/publikationen/conferences/oopsla2001...) I've taken comments about XP being a humane methodology with a pinch of salt.

bazzargh2• 13 years ago

I don't disagree with what you say about C3; my comment is more to do with the "see one-write one" nature of software books. Even though some books turn out surprisingly well, there's a distinct lack of depth and statistical analysis in the field.

ekidd• 13 years ago

In the late 90s, I worked in two different Lisp companies (one of which went on to become quite successful). They were, in many ways, far more modern than the average C++ shop of the era: They accepted that programming could be exploratory, that unit tests were a great thing, and that you wouldn't know what you wanted until after you'd already built half of it.

And yet…

I remember programmers who disappeared for months at a time to work on "their" modules. Integration phases where we tried to combine wildly incompatible components after 6 months of separate work. The breathless joy of seeing an actual regression test suite for the first time. The endless arguments trying to find the ideal design. And we all thought this was the "right way" to develop software!

I remember Beck's Extreme Programming. For me, it came as a bolt from the sky, obviously radical and brilliant. It turned me from a clueless junior programmer into somebody who took over and turned around a 150,000 line, 14-year-old C++ project, a project which everybody thought had succumbed to terminal bit rot.

Unit tests. Short iterations. The planning game, a.k.a., "Here, let me take your list of features, and tell you what each one costs. Now you decide what order we build them in." Man, does it bring back memories.

Of course, that was pretty much the shining high point. Within just a few years, Beck's idiosyncratic personal vision had been replaced by the "agile manifesto", and then by an entire consulting industry. Good riddance to all that.

But you know, it's been a long time since I heard somebody say "integration phase" or "object-oriented analysis." And I couldn't be happier.

nickbauman5• 13 years ago

I had a similar epiphany when I read Beck's book around 2000 or so. I don't think the Agile community has added much if anything to the work Beck originally laid out, either. In fact the term "Scrummerfall" is now in common usage here in Minneapolis.

Nimi• 13 years ago

Well, that was somewhat predictable. You've got a lot of managers. Some of them don't like to code, and regardless, all of them certainly need to be employed. What would they do if their shop started doing XP? One or two can become PMs or coaches, but what happens if you have much more managers?

At the risk of sounding somewhat loony, I think Marx said something about the middle class (in his definition: the class between the proletariat engaging in production, and the ruling class of capitalists) trying to preserve the benefits it gets from its social role. Can't find a citation though.

jheriko11• 13 years ago

http://programming-motherfucker.com/

Randgalt• 13 years ago

Fuck yeah

Glide4• 13 years ago

The list of resources is pretty comprehensive now.

robin22• 13 years ago

I'd have thought http://zedshaw.com/essays/c2i2_hypothesis.html would be more relevant here.

codegeek• 13 years ago

Whenever I see/hear the word "extreme" in the context of anything, it sounds like a cult to me. Obligatory reference [0]

[0] http://www.youtube.com/watch?v=FO2Abp0FbA0

hyp0• 13 years ago

Fred Brooks advocated most aspects of extreme programming in 1975 (MM-M).

DavidHogue• 13 years ago

And today most people I know who mention it keep saying XP when they mean pair programming. Not as if it's one of many practices in XP, but as if the two were synonymous. Please tell me this isn't common.

parasubvert4• 13 years ago

People latch on to what aspect they don't like of a thing and it becomes synonymous with the thing itself.

With XP, sadly, this is true. Most times you bring up the XP practices individually, and they're "good ideas". You say XP, and they say "fuck pairing!"

dpweb• 13 years ago

Hopefully we've evolved to the point where we can reject any dogmatic approach and realize that there exists certain good practices that can be applied - but it depends on the environment we find ourselves in, size and makeup of available team, timeframe, existing rules we have to adhere to for the particular project etc.. No silver bullet, but we rehash these debates endlessly.

ams6110• 13 years ago

The comment about pair programming resonated with me: What Mr. Beck writes about the paired-programming aspect is contrary to common sense and anyone even the slightest inkling of perception into the personality traits of developers.

Pair programming was THE most distasteful, unpleasant thing I have ever done in any employment. And I include in that my very first job which included cleaning grease traps and bathrooms at McDonalds.

bitwize• 13 years ago

Gurdjieff said that the path to spiritual development is to like what it does not like.

If developers do not like pair programming, is it a problem with pair programming or is it a problem with developers, specifically their unconscious, machine-like it?

The whole point of XP is not only to go against management best practice but also against the comfortable habits of most software developers, in an effort to make them better developers.

JoeAltmaier• 13 years ago

Yeah, so, if XP is based on psychobabble then that explains part of why it seems so repellent to lots of technical people.

andrewflnr• 13 years ago

Pushing against arbitrary comfortable habits is not a way to become better at anything. Some of those habits/inhibitions have very good reasons.

nickbauman5• 13 years ago

I found pair programming preferable to code reviews in both efficacy and enjoyment. Because, you know, you can't really skip this part in most larger systems where more than one developer is involved. You have to do one or the other. So you're doing code reviews ... Right?

danbruc• 13 years ago

What's the problem with pair programming?

rubiquity• 13 years ago

Robert C. Martin (known as "Uncle Bob" to many) wrote a blog post somewhat related to this recently. The gist is that Extreme Programming the name is dead because Extreme Programming the principles have been (mostly) widely adopted. It's a great read and I recommend checking it out.

http://blog.8thlight.com/uncle-bob/2013/12/10/Thankyou-Kent....

1-star reviews of 'Extreme Programming'

Related Stories