9

I am conducting academic research on the topic of Extreme Programming and whether its practices lead to creating space for more errors and bugs in applications.

From the experiences I gathered from many, I have comments that fall on both sides. Many support it and consider it a daily necessity, with dynamics that can facilitate changing project requirements. Many others argue that it leads to many problems, such as:

  • Over-involvement with the customer in the process leads to the expression of customer wishes rather than needs

  • Many products have multiple customers which lead to conflicting needs and opinions, creating unnecessary blockades

  • Many products don’t have any external customers, where the product is made for internal use or to be sold in the future. In these cases, the team itself is playing the user as well as the developer, hence killing the effectiveness of the process.

  • Not many things exist in formal documentation, this informality leads to vague vision and can create problems where the customer might say that this is not what we asked etc. etc.

The questions is why such conflicting opinions exist regarding XP. Is it a matter of different scenarios? Is there something else? To what extent is the claim (as written in the title) true?

I would like people who are working or have worked with XP here to contribute their learning and real world experiences. It would be ideal if you have any facts or references to support you answer.

Matthew Flynn
  • 13,345
  • 2
  • 38
  • 57
SajjadHashmi
  • 215
  • 1
  • 3
  • 6
    Hello and welcome to Programmers.SE! There is a possibility that this question will be closed as "not constructive", meaning that it will likely create debate and arguments (although I think that it should stay open because you specifically ask for concrete references and experiences). In that case you should probably refine the question and ask specifically about one or the other of your bullet points. (BTW: congratulations on asking the 25,000th question!) – Kilian Foth Apr 17 '13 at 10:56
  • 3
    Thank you for pointing it out, i had an idea that this can lead to non constructive discussion and so went through these guideline before posting it [What about subjective questions?](http://programmers.stackexchange.com/faq#what-about-subjective-questions) and i think i did fulfill them as my questions asks for experiences, facts and figures rather than personal opinions. I hope moderators will consider it. while i will also try to improve my question whatever felt necessary. p.s. about the 25,000th question, wow now i can count this as the achievement of the day. – SajjadHashmi Apr 17 '13 at 11:18
  • About the documentation, the agile manifesto (not XP, but closely related) says that code should have higher priority than documentation, but documentation should definitely be done. – Florian Margaine Apr 18 '13 at 09:59
  • Also, XP, like any other methodology, is just a bunch of guildelines -- everything has to be adapted to your business. – Florian Margaine Apr 18 '13 at 09:59
  • 2
    XP creates more errors and bugs _compared to what_? Everything else? Clean room development? Big design up front? – Joris Timmermans Apr 18 '13 at 10:08
  • 1
    all of these points are issues with *any* design process – jk. Apr 18 '13 at 10:40
  • 2
    How can responses from several people about their various experiences be an answer to a question? Who is going to have the best experience, i.e. how can this question have an accepted answer? – JeffO Apr 18 '13 at 16:07
  • I must echo @jk and MadKeithV here: most of the problems you describe exist in any process and methodology. For example, when you don't have external customers and the team must play both the developer and user roles, how is that exclusively an XP problem? Likewise with multiple customers having contradictory requirements: isn't that problem regardless of methodology? – Andres F. Apr 18 '13 at 16:52
  • 1
    Also, the title and first paragraph seem to imply this question is about bugs and errors, when it's actually about process and requirements. When you have the wrong requirements (or implement them wrongly), this doesn't necessarily lead to bugs or errors; maybe it just produces a working piece of software that simply doesn't meet the needs of the customer! – Andres F. Apr 18 '13 at 16:59

5 Answers5

11

Over-involvement with the customer in the process leads to the expression of customer wishes rather than needs.

This assumes that the customer is some sort of perfect oracle for the requirements of the system. One of the fundamental principles of XP is that the customer is not a perfect oracle and that constant feedback based on real shipping software is needed to determine the true needs of the market, the customers, and ultimately the stakeholders.

Many products have multiple customers which lead to conflicting needs and opinions, creating unnecessary blockades.

Yes, and regular involvement from those customers will help to make these conflicts explicit and help to resolve them over time. Hiding the problem won't make it go away.

Many products don’t have any external customers, where the product is made for internal use or to be sold in the future. In these cases, the team itself is playing the user as well as the developer, hence killing the effectiveness of the process.

Internal stakeholders are not fundamentally different from external stakeholders. You haven't explained how non-XP methodologies deal with this issue.

Not many things exist in formal documentation, this informality leads to vague vision and can create problems where the customer might say that this is not what we asked etc. etc.

XP involves frequent, incremental feedback between the stakeholders and the developers. If these failures of communication do exist then they can be discovered during early iterations and can be fixed before they significantly affect later iterations. The alternative is that these communication failures are not discovered until right before the product ships.

I think the fundamental misconception is that XP isn't creating these issues. It's just exposing them. Processes that expose and correct issues early and often are generally less error prone, not more.

Matthew Flynn
  • 13,345
  • 2
  • 38
  • 57
Rein Henrichs
  • 13,112
  • 42
  • 66
  • as far as the first point is concerned i think you have explained it in a great way by saying: `One of the fundamental principles of XP is that the customer is not a perfect oracle and that constant feedback based on real shipping software is needed to determine the true needs of the market, the customers, and ultimately the stakeholders.` +1 for this – SajjadHashmi Apr 18 '13 at 12:36
  • regarding `multiple customers issue` i consider main reason behind this concern is, when two competitors are in one team together (lets say during a meeting) they will may be uncomfortable & hesitant expressing their business logic/needs in front of other competitors. which will kill the efficiency of the process. – SajjadHashmi Apr 18 '13 at 12:40
4

A few thoughts:

  • Too much involvements of the customer in the process make him start expressing his wishes rather than his needs to the software

There is always a balance between having a detailed, stable specification and being responsive to the customer. Extreme is meant to increase responsiveness to the customer, and of course it is possible to go too far in that direction. So this is a legitimate concern (especially depending on how the project is billed: if it is a fixed-price contract, you obviously have to have it well-specified).

In my experience, however, no matter how good your specification is, you often have to change it to do "what the customer wishes" anyway. Extreme helps you make those changes as soon as possible, rather than after you have built a huge, complicated program to specification.

  • Many products have multiple customers which lead to conflicting needs and opinions leading unnecessary blockades

Of course, resolving conflicting needs in such a situation will always be a problem that you need a good process to deal with. If the process of getting customer feedback is time-consuming and complex, then it would make Extreme Programming less effective, so I think this is a legitimate concern.

  • Many products don’t have any external customers (products organization made for them or to be selling in future). In this case the team itself is playing the user as well as the developer hence killing the effectiveness of the process.

I don't think this is legitimate at all. The idea behind Extreme it that customers don't realize what they want until you actually start making it. This is just as true for internal "customers" as external ones.

And if you are developing something that has no customers yet (like a product not yet released) you must have someone (or some group) who is acting as the hypothetical customer and deciding what people will want. Extreme works just as well with them acting as the customer.

I have worked on a product like this, which was intended for external customers but not yet released. While we didn't label it "Extreme Programming", we used a similarly iterative development process without an extensive formal specification and with frequent builds. I found it quite effective.

  • Not many things exists in formal documentation, this informality leads to vague vision and can create problems where the customer might say that this is not what we asked etc. etc.

Yes, anything that is not documented is a problem. Extreme, since it is not driven by a formal specification, might make it easier to not document things. But Extreme doesn't automatically mean "things are not documented". You should still make documentation, but it is created alongside the program rather than beforehand. And in some cases it will mean documenting the behavior after you implement it. This is not a problem in and of itself.

When it comes to billing, you often need written documentation of exactly what will be delivered before you start the work. This can be more difficult with Extreme Programming.

Conclusion: Extreme is a methodology that, like anything, has advantages and drawbacks. You need to keep both in mind when using it (or teaching it).

  • what do you exactly mean here when you says `documentation should be created alongside the program` .. i mean to ask why documentation are you suggesting the we should make alongside program. The concern of the point was mostly because lack of documentation like specifications etc. in planing phases where we decide the scope of the project or particular iteration. – SajjadHashmi Apr 18 '13 at 12:34
  • @SajjadHashmi, that part of the answer does not apply to the issue of specification, that is true. My point is, even if creation of the program is not driven by specification, you still need to document what it does, how it works, etc. –  Apr 18 '13 at 12:41
3

Your questions are dealing only with two main XP topics: "direct customer communication" and "not too much formal documentation". So in my point of view, this is not really an "XP" question, those are topics which are part of any other agile development process I know of.

Here are my thoughts:

Too much involvements of the customer in the process make him start expressing his wishes rather than his needs to the software.

Well, if you have a waterfall-like process, with a fully detailed specification beforehand, with lots of requirements, you may get in trouble either which of those requirements are just wishes and which are real needs. The easiest way of clarifying this is IMHO talking to the customer and showing him different alternatives - whenever you come to a point where clarification is needed. So quite the opposite is true - "agile development" will help you to deal with "needs vs wishes" better.

Many products have multiple customers which lead to conflicting needs and opinions leading unnecessary blockades

Yes, with a fully detailed specification beforehand those conflicts may have been resolved before the development starts (if you are lucky). The solution to this problem in an agile process is to have only few people on the customer side talking directly with the devs, and one responsible representative for the customers who can make final decisions in case of conflicts.

Many products don’t have any external customers (products organization made for them or to be selling in future). In this case the team itself is playing the user as well as the developer hence killing the effectiveness of the process.

No, that's not correct, if you have only internal users belonging to the same company as the devs, "customer on site" is much easier to be installed than when you have only external customers. If you have no direct users at hand, that may be a problem, but that is not an agile-specific problem - you will then have to find someone who takes the role of a potential user instead (and this person is typically not from the developers team).

Not many things exists in formal documentation, this informality leads to vague vision and can create problems where the customer might say that this is not what we asked etc. etc.

To my experience, if you develop following a formal specification without constant customer communication, the chance of developing something where the customers says "this is not what I asked" is >100 times higher than when you talk to the customer daily. If you still run into that problem either, there is a simple solution: after each customer session, make a short written note what you have agreed upon. If necessary, send that note to the customer and give him a chance to make corrections. That works in an agile process as well as in any other kind of project.

Doc Brown
  • 199,015
  • 33
  • 367
  • 565
  • may be I lacked in explaining somewhere but i do mean XP by heart including all its 5 principles in mind and not any other agile method. Regarding first point (in general opinion) `devs`-to-`customer` direct discussion are not usually considers best option as they both have different paradigms devs are usually on extreme technical sides and customers are usually talking in business terms, that's why teams have analyst in between who actually being a lot of documentation so don't you think this discussion could create more problems rather than solving it. – SajjadHashmi Apr 18 '13 at 12:49
  • your answer to the last point is really helpful and clear. Thank you +1 – SajjadHashmi Apr 18 '13 at 12:49
  • @SajjadHashmi: I have worked in teams where you have analysts between the devs and the customer - and I have worked in teams where the "analyst" was a developer of the team who just had not forgotten how to avoid technical terms when talking to business people. IMHO the latter is >10 times more effective. – Doc Brown Apr 18 '13 at 15:01
  • @SajjadHashmi: see my changed introduction why your question is not really an "XP" question. But I think it does not really matter. – Doc Brown Apr 18 '13 at 15:10
0

Too much involvements of the customer in the process make him start expressing his wishes rather than his needs to the software

Are you developing software based upon what a customer needs? What if a customer wants? Will you deny the customer because "hey customer, I only build software based upon need!??"

I interned at an extreme programming and agile shop. I saw first-hand weekly customer interactions that at times drove QA and developers nuts. But they delivered exactly what the customer wanted, when he wanted it, and it was clear during "Show and Tell" with the customer what he did, what he didn't, and what should be as he wanted.

Many products have multiple customers which lead to conflicting needs and opinions leading unnecessary blockades

Not unnecessary blockades if the extreme and agile shop make it clear the objectives of implementation and what will and will not be incorporated in the product. Different versions of the same product is also a possibility and it depends upon what is negotiated. This need not be a point of contention that halts productivity or leads to unnecessary blockades.

Many products don’t have any external customers (products organization made for them or to be selling in future). In this case the team itself is playing the user as well as the developer hence killing the effectiveness of the process.

Not necessarily. Even external user interface whereby one is interviewing people at random on the street to determine what an interface for a particular device would look interesting to them is a possibility.

Not many things exists in formal documentation, this informality leads to vague vision and can create problems where the customer might say that this is not what we asked etc. etc.

Then formal documentation need be employed. Formal documentation holds the customer's feet to the fire and a "this is what you told us you wanted" one-line punch-card coincides with the documentation and customer interaction so there are no excuses. As I had opportunity to see this in action as an intern at an extreme and agile shop, the customer signed off on documentation weekly. The customer also had a chance to implement changes and had to sign off on those too. If there is a lack of documentation, there is an invitation to disaster.

The questions is why such conflicting opinions exists regarding XP, is it the matter of different scenarios or is there something else and till what extent the claim (as written in the title) is true.

I would say that depends upon the intelligence of the shop. XP and Agile are guidelines and not instructions. To operate successfully with XP and Agile, it has to be incorporated into operating practices and utilized throughout whole organization. Mileage will always vary and some will undoubtedly claim it is bad, some will say it is good. where I interned, it was undoubtedly good and much success was had.

From my experience, how rigid one is to the principles of XP and Agile appear to determine if, when incorporated into the "daily grind", how successful it makes software development. Where I interned, customer interaction drove everything and nothing was done without a customer having first stated it should be done. The way this shop ran its' operations provided good, measurable success using sound principles of development as part of the XP and Agile framework tightly integrated into everything they do.

Mushy
  • 345
  • 1
  • 7
  • of course satisfying customer is important, but wants and wishes could be ever going a human can wish for everything and he will keep doing and we cant keep facilitating them cuz if we do wouldn't it kill the XP principle i.e. `KIS` > `Keep it simple`? – SajjadHashmi Apr 18 '13 at 12:52
  • If the customer is willing to pay for it, who cares? Every change and every tweak means dev time that can be billed to the customer. Still doing XP work but money will dictate when it is time to stop all the this and that. Shop can also cut it off too by determining what they are willing to dev. – Mushy Apr 18 '13 at 17:32
0

If we stick to the original question of

I am conducting academic research on the topic of Extreme Programming and whether its practices lead to creating space for more errors and bugs in applications.

I am not sure the concerns expressed are relevant to the question.

If there is a fear of customer over involvement leading to wishes rather than needs, I would look to the team to be sure they are properly breaking items down into small releases with simple designs. After that prioritizing those items in such a way that the team can work at a sustainable pace.

If the effort has multiple customers that can not agree needs and opinions, what hope is there of ever being able to test that the software meets customer needs. It is better to get those things cleared up early in the SDLC rather than later.

If the team has to be the user for XP, this does not kill the XP process. In fact it is specifically stated that the customer is a member of the team. At times this team member is an internal employee rather than a "true customer" it is important that the individual is empowered to represent the needs of the customer. I don't see how this is concern is any more relevant to XP as compared to any other approach, be it agile or traditional.

Not many things exist in formal documentation? If done properly XP teams will spend more time planning than a traditional team. Additionally, because specifications are written jointly between the business and technical minded team members at the beginning of each iteration, the specifications tend to be more accurate when compare to big design up front.

XP focuses on the development (engineering) aspects of a project. Things that should be discussed when considering XP are:

  • Does the learning curve for test driven development interfere with the development of a quality product.
  • How difficult is it to create quality tests that will result in quality code.
  • How likely are developers to "cheat" the test driven development cycle and write the code first, then the test later. Does it matter?
  • How effective are developers who work in pairs when compared to more traditional development (one person writing the code for a function).
  • Does iterative/emergent design lead to more stable, scalable systems than systems the are designed up front.
  • How effective is continuous integration at proactively preventing software defects.

To me those are the questions to consider with XP. The concerns raised above seem to be more suitable for a discussion of Scrum (Which is very commonly paired with XP).

For references I would see:

http://xprogramming.com/index.php

or

http://www.objectmentor.com/resources/omi_reports_index.html

Cheers and Best of luck with your research.

Abstract Class
  • 329
  • 1
  • 3