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.<p>And yet…<p>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!<p>I remember Beck's <i>Extreme Programming</i>. 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.<p>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.<p>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.<p>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.
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.<p>The criticisms about no metrics supporting the book assertions are valid too (we have more metrics now, though).<p>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).
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)<p>-----------------<p>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.
The comment about pair programming resonated with me: <i>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.</i><p>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.
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).<p>I get some of it, because of war stories. But I know I'm missing a huge piece of it.<p>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?
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 <a href="http://c2.com/cgi/wiki?ChryslerComprehensiveCompensation" rel="nofollow">http://c2.com/cgi/wiki?ChryslerComprehensiveCompensation</a><p>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.
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.<p><a href="http://blog.8thlight.com/uncle-bob/2013/12/10/Thankyou-Kent.html" rel="nofollow">http://blog.8thlight.com/uncle-bob/2013/12/10/Thankyou-Kent....</a>
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.
Whenever I see/hear the word "extreme" in the context of anything, it sounds like a cult to me. Obligatory reference [0]<p>[0] <a href="http://www.youtube.com/watch?v=FO2Abp0FbA0" rel="nofollow">http://www.youtube.com/watch?v=FO2Abp0FbA0</a>
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.