Anti Xp Ramblings

It seems some people think the brochure is more important than the tour...

From: Krasicki

As a matter of introduction, my experience with methodologies began in 1988 in the integration of CaseTools and has continued for the past dozen years as occasional methodologist, systems architect, and developer.

In that time, I have worked as a project-to-project software contractor and have seen these methodologies and techniques bastardized in hundreds of sometimes reprehensible, amusing, or creative ways. The following comments are based on summary readings of Extreme Programming literature, voluminous forum postings on the subject, and an article called The New Methodology (see: http://www.martinfowler.com/articles/newMethodology.html), MartinFowler describes many of the assumptions and philosophical perimeters of what are becoming known as LightweightMethodologies (LWM).

I commend Mr. Bernard on his initial attempt to apply legitimate standards of expectation, measure, and semantics to the conversations about the merits of these LWMs. In the many years that I've been associated with IEEE and ACM, I've found their discussions of these topics to be intellectually lively, creative, and accurate. I would like to add some additional observations that I hope may stimulate a broader discussion.

One of the most obvious characteristics of the literature discussing LWMs is that many of the authors suffer from mutual-admiration-society syndrome. There is an annoying dependency on circular logic and self-insulating reference (Joe thinks Bill's ideas are great, Bill thinks my ideas are great, I think Joe's ideas are great, and so on). In many cases, examples of methodology deployment deceivingly point interested parties in the direction of companies who profit from the publication or training of professionals in the very thing that they are being cited for. This is always a dubious practice.

The advent of lightweight methodologies is not surprising. A dozen years ago, CASE tools were intended to elevate the masses of programmers into a new hybrid information age worker sometimes referred to as a knowledge engineer. Knowledge engineers, armed with code-generating CASE tools would soon out-perform and render mere programmers obsolete. IBM's Visual Age tools are today's revised implementation of that ideal. Today, just as I did a dozen years ago, I wonder how many programmers can think in the necessary abstractions of design AND code. Contemporary IT vendor-speak often takes this for granted as if all programming activity, by definition, IS design.

There never seems to be any doubt that software design is a by-product of coding activity. Some of us think software and product design is much more than that.

A LWM such as Extreme programming's solution to this problem is that if you cannot grow another head on each programmer, simply make all design and coding activity a shared experience. In this scenario, one person codes while the other observes, coaches, or simply provides the second opinion or designer role. Coders and Software designers are interchangeable entities.

Furthermore, ALL design and coding is done just-in-time. Lightweight methodologies like extreme programming are highly existential in that the only design decisions that matter are those that exist at the moment and, intentionally or not, are reactionary in nature to some recently triggered event (design consideration, bug, itch). The customer and programming team are tightly coupled and achieve design objectives in waves of relatively immediate gratification. There is no unnecessary baggage like a requirements specification or even a design specification to slow down these locomotives of productivity. Oh, and BTW, if you are a programmer that prefers developing code privately, through research, good practice, solitude - that's okay - you just can't do it in most extreme programming environments. That is unless the rules change and programmers make all the rules - whenever.

What is obvious and ominous is that programming for couples is a new idea and one that will introduces some very interesting psychological and corporate policy challenges. LWM proponents are still buzy formalizing the details of managing sick days, vacation time, tight schedules and the like. Needless to say, where there's a will there's a book, a whitepaper, at the very least a certification exam - whatever.

So what about the methodologies? These can be best described as a hybrid set of well-known programming practices infused with a "fast" start-up attitude and decorated with a refreshing social agenda (no more than 40 hour weeks, programmers(lightweight designers/programmers) make most important decisions, tightly coupled business relationships, and more). LWM will appeal to young developers who will feel empowered by the power politics vocabulary.

Methodologies largely consist of sets of techniques that attempt to accomplish a clearly defined Software Engineering objective. What is slightly different about is that the lightweight methodology proponents seem to add an even finer granularity to this mix by concentrating so intensely on a programmer-centric vocabulary. Discetionary programmer best-practices have been introduced as components of the methodology sometimes given equal or greater status than an established technique. So instead of a notation for testing, one might simply write a test or test vehicle.

The overwhelming emphasis on testing and building software component (objects or otherwise) introduces opportunities to refine, fine-tune, and formalize this set of practices.

I suspect that this emphasis is the realization that successful software companies cannot be burdened by heavyweight methodologies. The clear lessons of history show that fast development is more critical to capturing market-share than slower, higher quality product. Generally, lightweight methodologies are merely acknowledging and catering to this phenomenon. The lessons come straight from contemporary development practices described in corporations such as Microsoft, Netscape, and Apple to name a few.

Lightweight methodologies may also more accurately be called post-modern methodologies because the whole of the methodolgy is not much more than a pastiche of practice that fits an immediate need. Lost is an orderly, temporal Software engineering procession of processes that eventually produce a final product. Proponents of lightweight methodologies, unwittingly, propose the idea that there is no "end-product" there is just an ever-evolving prototypical system that the customer can choose to accept or reject at any time. Proponents sell this concept as an embrace and resignation to continuous change. It also has the potential to horrifyingly redefine the excesses of feature creep, product creep, and engineering creep. Some LWM feature bill of rights manifestos for developers, customers, and significant others.

LWM literature expresses a youth bias. LWM are clearly being marketed to a youth engineering segment and are burdened by workplace practice requirements that may render the methodologies unworkable. Employees participating in extreme programming are required to conform to a majority rule that invades privacy and invites "Lord of the Flies" potentials. The literature is laced with petty tyrannies that are taken for granted, the least of which is the "our way or the highway" subtext of extreme programming.

Finally, like it or not, the profitability of selling sexy, fuzzy, vapor-stuff is not to be underestimated. These LWMs may well become the pet rocks of your software engineering library. They are reactionary responses to the bloated, impossible to manage, and pretentious heavyweight methodologies. Companies that cannot afford the cost overhead of heavyweight methodology software development will surely try LWM out and, inevitably - in some round-about way, software will get developed under the auspices of LWM.

Metrics or not, a bastard child awaits at the doorstep crying for attention and consumption.

"Edward V. Berard" wrote:

I have known of KentBeck for quite some time. His published articles were always of interest to me. Kent wrote on topics ranging from agent-based programming, to class-responsibility-collaboration cards, to diagramming techniques for object-oriented software development.

In person, Kent comes across as someone who is genuinely interested in people as human beings. It is no accident that his approach to software development techniques contains generous helpings of the human element.

While I may have serious issues with his latest ideas regarding software technology, I sincerely respect Kent.

Recently, I was approached by both Kent and the IEEE. They are in the process of creating a web page dedicated to discussing and exploring eXtreme Programming (XP). I was asked to contribute a short article addressing the cons (the downsides) of XP -- at least as I saw them. I declined the invitation.

Both Kent and the IEEE were persistent. I reiterated my belief that some of the more vocal XP advocates seem to be on a different playing field than most of the rest of software engineering technology. This "paradigm gulf" (as Kent has described it) makes it difficult to have meaningful discussions.

Kent then asked me to put down some of my concerns in writing. He asked me to address my issues in the form of "when I see A, B, and C, I will feel comfortable discussing XP again." I did this, and sent him my ideas via private e-mail. Kent then asked me to post my concerns to some public forum so that they could form the basis for a discussion. That is what this article is all about.

So, at Kent Beck's request, and in no special order, when I see the following, I will be comfortable discussing XP again: 

    -> A well-defined, and well-documented set of metrics: A "metric" is
       a defined measurement of something. The term is used to mean both
       an actual measuring technique, and the results of applying that
       technique. In software, we measure processes, products, and
       people.


       If you claim that A is bigger/faster/better/cheaper than B, that
       implies that you have a way of measuring the same thing in both
       A and B, and that the results can be compared in a meaningful
       manner. Some metrics are very quantitative (requiring "hard
       numbers"), while others are very qualitative (e.g., true or
       false and good or bad).


       Metrics themselves have metrics. For example, we talk about
       "statistically significant," "representative sample," "objective
       versus subjective," "systematic," "repeatable," and "in context."


       To be meaningful, metrics discussions must:


          - Use a documented definition of the metric


          - Describe what was being measured


          - Describe the precise way in which something was measured


          - Describe the context in which the measurement took place,
            giving special attention to factors that could have a
            major influence on the measurement.


       Realizing that there is often more than one definition for a
       particular term or concept, there should be a bibliography of
       acceptable references for each metric.


       XP discussions are full of words like "quality," "faster," and
       "value." However, in the XP world, metrics are seldom defined, and
       almost never measured. Questions like "did you measure A?" are
       met with responses such as "why would you want to measure that,"
       or "measuring that will result in unnecessary and wasteful
       infrastructure."


       No metrics, no credibility.


    -> Recognition of human psychology: Human beings are all different.
       Just because two humans have the same raw level of intelligence
       does not mean that they will be equally capable (or, equally
       inclined, for that matter) to assume a given task. We are all not
       Renaissance people.


       Further, psychologists, sociologists, anthropologists, and others
       who study the human condition, have been reporting for centuries
       on certain tendencies regarding they way people think. For
       example, most people are reactive thinkers, and relatively few are
       proactive thinkers. Many people are very comfortable with "lots of
       trees," while relatively few actually notice "the forest."


       In reading some of the discussions on XP, I get the distinct
       impression that if you bring up some aspect of the human condition
       that does not put XP in the best light, that aspect is denied.


    -> A resurgence of intellectual curiosity: Some people are aware not
       only of how much they know, but also how much they do not know.
       The seemingly infinite amount of continually-updated technical
       knowledge proves daunting to many people. This problem is further
       exacerbated by the realization that, even if one was handed the
       information on a silver platter, there is still no guarantee that
       one will understand it, or even begin to perceive all the
       ramifications.


       Some within the XP community feel that if they are not aware of
       something, then:


          - it must be theoretical, academic, and definitely not
            practical, or


          - it must be the fault of the vendors or authors for not
            bringing it to their attention.


       Some XPers demand to be spoon-fed, i.e., rather than checking out
       some or all of the references themselves, they ask for a quick
       synopsis of the contents. Others simply deny the existence or
       value of the technology. Still others claim to know about
       something, but in later conversations, often reveal that they
       do not.


    -> A recognition of existing and past software engineering
       technology: Over the past 50 years, software practitioners have
       moved from small machines and small problems, to very large
       (in power) machines and very large problems. Along the way, they
       dramatically increased their understanding, their strategies, and
       their tools, e.g.:


          - We went from flowcharts (late 1940s), to structured
            technologies (late 1960s, early 1970s), to object-oriented
            technologies (1970s, 1980s, and 1990s), to Web-based
            strategies (1990s), and onward.


          - We saw the evolution of many new subdisciplines, including
            analysis, design, testing, debugging, quality assurance,
            configuration management, domain analysis, and software
            project management


          - We created software tools to help automate the processes of
            creating, measuring, maintaining, and otherwise managing
            software.


       To hear some XP advocates talk about it, one might get the
       impression that nothing much of consequence happened before XP.


    -> A major decrease in zealotry: Some XP "acolytes" seem to feel that
       those who do not embrace XP wholeheartedly must:


          - Not fully understand what XP is all about


          - Be intentionally grossly misrepresenting XP
I am not attempting to change anyone's perspectives by listing the above points. Again, I am posting it at Kent's request. 

                       Example Kent Beck Articles


 [Beck and Cunningham, 1989]. K. Beck and W. Cunningham, "A Laboratory
 for Teaching Object Oriented Thinking," OOPSLA 189 Conference
 Proceedings, special issue of SIGPLAN Notices, Vol. 24, No. 10, October
 1989, pp. 1 - 6.


 [Beck, 1991]. K. Beck, "Think Like an Object," UNIX Review, Vol. 9, No.
 10, October 1991, pp. 39 - 43.


 [Cunningham and Beck, 1986]. W. Cunningham and K. Beck, "A Diagram for
 Object-Oriented Programs," OOPSLA 86 Conference Proceedings, special
 issue of SIGPLAN Notices, Vol. 21, No. 11, pp. 361 - 367.


 [Fenton and Beck, 1989]. J. Fenton and K. Beck, "Playground: An
 Object-Oriented Simulation System With Agent Rules for Children of All
 Ages," OOPSLA 89 Conference Proceedings, special issue of SIGPLAN
 Notices, Vol. 24, No. 10, October 1989, pp. 123 - 138.
EdwardBerard

Note that both these people will not actually sit on an XP team and do the feedback thing for an iteration or two.

Note how the elegant wordiness hides the insinuations. XP "doesn't pitch metrics" because XP does not want to be measured compared to other methodologies.

Then we twist "AllEngineersInOneRoom" into "a worker's paradise where anyone can do anyone else's job".

As usual, people use what they refuse to understand as a punching bag for their own issues...

On the other hand, this page is useful, in that it illustrates the problems that non-XP'ers have with XP. XP'er could learn much by this.

I take a more middle-road view. In nearly everything in life, the 'pure' route isn't the best. I find this to be the best approach for most project (contrast this to XP): 

          1. Gather rough requirements (documented from a meeting)
          2. Make a draft design involving the developers
          3. Create a prototype
          4. Solicit feedback from the customer
          5. Begin XP methodology
There are often massive changes from 3 to 4. This approach allows you to discard the inevitable large swaths of design/code without wasting the efforts of inapplicable unit tests (TDD), pairing, debugging, UI redesign based on feedback, etc. Crank something out with a SUPER-lightweight methodology, get feedback, then use any other methodology.

Moved to XpIsMarxism

http://www.hacknot.info

EditText of this page (last edited August 11, 2008) or FindPage with title or text search