-3

As developers and as professional engineers have you been exposed to the tenants of Extreme Programming as defined in the "version 1" by Kent Beck. Which of those 12 core principles do you feel you have been either allowed to practice or at least be a part of in your current job or others?

* Pair programming[5]
* Planning game
* Test driven development
* Whole team (being empowered to deliver)
* Continuous integration
* Refactoring or design improvement
* Small releases
* Coding standards
* Collective code ownership
* Simple design
* System metaphor
* Sustainable pace

From an engineers point of view I feel that the main engineering principles of XP arevastly superior to anything else I have been involved in. What is your opinion?

Piotr Dobrogost
  • 41,292
  • 40
  • 236
  • 366

5 Answers5

2

We are following these practices you've mentioned:

  • Planning game
  • Test driven development
  • Whole team (being empowered to deliver)
  • Continuous integration
  • Refactoring or design improvement
  • Small releases
  • Coding standards
  • Collective code ownership
  • Simple design

And I must say that after one year I can't imagine working differently.

As for Pair programming I must say that it makes sense in certain areas, where there is a very high difficult area or where an initial good design is essential (e.g. designing interfaces). However I don't consider this as very effective. In my opinion it is better to perform code and design reviews of smaller parts, where Pair programming would have made sense.

As for the 'Whole team' practice I must admit that it has suffered as our team grew. It simply made the planning sessions too long, when everybody can give his personal inputs. Currently a core team is preparing the planning game by doing some initial, rough planning.

Yaba
  • 5,979
  • 8
  • 38
  • 44
1

I consider myself lucky, all except "Pair programming" we can do it, but only to solve big issues not on a day-to-day basis. "Collective code ownership" is hard to achieve as well, not doing pair programming we tend to keep the logical next user stories from iteration to iteration.

pmlarocque
  • 1,704
  • 1
  • 18
  • 26
0
  • Pair programming[5]

It is hard to convince management of this aspect. But I have found this is doable when an engineer gets stuck or we have an engineer who is new to a technology or effort.

  • Planning game

Yes.

  • Test driven development

Easy sell to management. However the hard part of some management is adding in more time. A lot of managers believe that Extreme and Agile programming will save them time. They don't save time to deliver you something. In fact, the testing constant requirements gathering adds effort. What it does do, is it gets the customer what they want faster.

  • Whole team (being empowered to deliver)

Definitely, this is an amazing facet to Xtreme.

  • Continuous integration

At the end of each iteration (sprint) full integration occurs. Daily full integration does not occur.

  • Refactoring or design improvement

Your first effort is rarely the best. So yes, I find Xtreme constantly yields better and better solutions.

  • Small releases

I find that given the infrastructure and resources that can lengthen the suggested length of an iteration of 1 or 2 weeks. A lot of this depends on where you are deploying to. If you system is being deployed to a production environment, formal systems and stress testing can add a lot of overhead. So in this environment, we go with iterations lasting a month or even 2 months. If the system is being deployed to a development area and has not been deployed to production, even something as tight as an iteration lasting 1 day can be doable.

  • Coding standards

Pair programming for new team members can promote this. Code reviews also can help here. A lot of this depends on how long you have been working with each other.

  • Collective code ownership

I haven't found that Xtreme really helps here. Everyone naturally falls into certain areas of the code base. So people get ownership of things they spend a lot of time with. This can actually be a good driver as good software engineers will take pride in what ever they write this way.

  • Simple design

Short iteration cycles do in fact promote a simple design. It needs to be maintainable for the short releases.

  • System metaphor

Not sure what is meant here?

  • Sustainable pace

Velocity of a team is a task that can only be acutely estimated with proper metrics. Metrics need to be kept on task estimates and task completions durations.

Art Solano
  • 99
  • 11
0
  • Whole team (being empowered to deliver)
  • Small releases
  • Coding standards
  • Collective code ownership

But then, I do work in a mission-critical development team that's quite conservative. I don't necessarily thing XP is a good way to develop, you must find a way that's right for you and ignore the dogma.

gbjbaanb
  • 51,617
  • 12
  • 104
  • 148
0

We've done everything except small releases and it's been great. I can't imagine working any other way. From my experience, the tenets I value most are:

  • Continuous integration (with a solid test suite).
  • Collective code ownership.
  • TDD
  • Team empowerment and decision making.
  • Coding standards.
  • Refactoring.
  • Sustainable pace.

The rest are very nice to have too, but I've found that I can live w/o pairing so long as we have TDD, collective ownership, and refactoring.

Mike Reedell
  • 1,567
  • 15
  • 23