6 ms·

Google is failing me right now, but I remember Kent Beck explaining why he used the term "extreme" in XP. It refers to things like extreme skiing. You can hel

Google is failing me right now, but I remember Kent Beck explaining why he used the term "extreme" in XP. It refers to things like extreme skiing. You can helicopter to the top of a mountain and do crazy things, but you will get killed. Extreme skiers avoid getting killed by reducing risk. You break down all of your movements to their absolute basics and you perfect them. Then when you are skiing, you stick to those basics, performing them almost perfectly time after time. You never do anything extraordinary. By doing this you de-risk each movement to the point that you can chain them together and do something astonishing. In reality, though, extreme skiing (and extreme programming) is simply monotonous repetition of basic skills executed to near perfection. To me, this is what "agile" means. It means boiling it all down to a small set of skills that you can perfect and repeating them over and over again without exception. Because you are never taking any risks, the overall project can appear to be insane, but still be accomplished. If you are negotiating what you are doing by saying, "maybe we can get away with X", or "maybe this will be good enough", then you will not be able to achieve this kind of agility. And before someone asks: yes, the code will still not be perfect in the end. You goal is the perfection and de-risking of your actions not your artifacts. It is a subtle but important point.

seivan 11y ago
No risk, no experiments, no innovation and getting caught in a rut of mediocrity and boredom. I love experimenting and taking chances with code and ideas. Yeah you end up spending more nights and it might take more time or it might blow up in your face but what's the point of being a programmer if you can't push limits.
- jtfairbank 11y ago
  You can certainly experiment and innovate. Nothing about agile stops you from adding an issue to spend half a day investigating the right tool to solve a problem, or implementing something two different ways to determine the best one. But by explicitly defining that objective and blocking out time to do that you de-risk the development process related to it. These "extreme" processes force you to define the motions (issues, work tasks) and allow you to practice getting them done using the same process over and over again.
- mikekchar 11y ago
  This is actually a good point. In XP this is one of the reasons you do spikes. Often you will throw away all of your rigour when you do a spike and just see what comes out the other side. Then you throw away the code and reimplement it using your rigour. That way you get the best of both worlds with a small penalty of having to do some rewrites. It takes a considerable amount of discipline, though, to throw away working code when people are screaming at you to deliver ;-)
  - seivan 11y ago
    Haha, I thought it needed more discipline to keep working coder as I keep renaming and rewriting.
bdavisx 11y ago
I think part of the "Extreme" was also to "turn the practices up to 11" - eg. Code Reviews are good? Then we'll have continuous code reviews thru Pair Programming. Short Development Cycles are good? Then we'll have cycles that go on the order of minutes or even seconds (Red/Green/Refactor). Customer Involvement is good? Then we'll have them actually sit with the dev team. etc.
lukesan 11y ago
"maybe we can get away with X", or "maybe this will be good enough" I think it is important to ponder about what is the best (efficient, best matching, ...) solution to the problems the user has. In your definition agility sounds like the absence of pragmatism.
- mikekchar 11y ago
  I've tried about 3 times to respond to your comment because I believe it deserves a response. Alas, I am not yet expert enough to write what needs to be said in a format smaller than a book ;-) Hopefully a few clues will lead you to a better understanding of what I am trying to convey. There is a difference between the artifacts you are building and the practices you are using to build them. When you are pondering different solutions to the user's problems, you are pondering about the artifacts that you wish to build. In such things, you must be as free as you can be. On the other hand, the practices you use to build those artifacts must necessarily be more strict. If you use a haphazard approach to choosing your practices, you will not be able to refine them. If you choose complicated practices that require large amounts of coordination with other people, you will likewise not be able to refine your practices. The goal, IMHO, is to simplify your practices and maximize your facility with them. There isn't just one way to write software. You need to choose practices that will work for you and your team. The choice of those practices is of paramount importance to the success of your team. It must be things that you are good at and that you can coordinate efficiently on. There isn't a one size fits all. Having said that, you must be very strict about what you are doing because (at least in my experience) most practices are not compatible. Even very subtle changes or misunderstandings can cause various practices to misalign and backfire. So far, what I have said is not specific to "agile" processes. To talk about agile in a public forum is difficult because for many of us old guys the term has been diluted considerably. So keep in mind that this is my opinion (a non-famous, random guy on the internet) and there will be luminaries that disagree (possibly violently ;-) ). I believe that an "agile" process is one in which the main artifact (the software that you are delivering) maintains at least a constant potential for modification over time. Your goal is maximize throughput over time. In my experience, you can actually accelerate throughput over time with the right team/practices. I will steal Ron Jeffries term, "hyper productivity" to refer to this condition. In more clear terms, what you want to say is that at the beginning of the project adding a feature is easy. If you are "agile" then a month or a year from now it is just as easy. If you are "hyper productive", then a month from now it is easier to add a feature. A year from now it is much easier to add features. My assertion (which I can not back up in such a small space) is that if you are inconsistent applying your practices, then you will never reach the level I call "agile", much less "hyper productive". Some people might call this kind of inconsistency, "pragmatism". I do not know if you would be one of those people. I will say, though, that one of the reasons I have put such an effort into writing this response is that I recognise your name from other postings you have made and think that it is not a wasted effort ;-) I have experienced what I refer to as "hyper productivity" on a few projects. It is magical. I know of only one way to get there. In the 30 years I've been in this industry I have never seen a flexible approach to practices achieve it. That doesn't mean it is impossible, but I am doubtful.

seivan 11y ago

No risk, no experiments, no innovation and getting caught in a rut of mediocrity and boredom. I love experimenting and taking chances with code and ideas. Yeah you end up spending more nights and it might take more time or it might blow up in your face but what's the point of being a programmer if you can't push limits.

jtfairbank 11y ago
You can certainly experiment and innovate. Nothing about agile stops you from adding an issue to spend half a day investigating the right tool to solve a problem, or implementing something two different ways to determine the best one. But by explicitly defining that objective and blocking out time to do that you de-risk the development process related to it. These "extreme" processes force you to define the motions (issues, work tasks) and allow you to practice getting them done using the same process over and over again.
mikekchar 11y ago
This is actually a good point. In XP this is one of the reasons you do spikes. Often you will throw away all of your rigour when you do a spike and just see what comes out the other side. Then you throw away the code and reimplement it using your rigour. That way you get the best of both worlds with a small penalty of having to do some rewrites. It takes a considerable amount of discipline, though, to throw away working code when people are screaming at you to deliver ;-)
- seivan 11y ago
  Haha, I thought it needed more discipline to keep working coder as I keep renaming and rewriting.

bdavisx 11y ago

I think part of the "Extreme" was also to "turn the practices up to 11" - eg. Code Reviews are good? Then we'll have continuous code reviews thru Pair Programming. Short Development Cycles are good? Then we'll have cycles that go on the order of minutes or even seconds (Red/Green/Refactor). Customer Involvement is good? Then we'll have them actually sit with the dev team. etc.

lukesan 11y ago

"maybe we can get away with X", or "maybe this will be good enough" I think it is important to ponder about what is the best (efficient, best matching, ...) solution to the problems the user has. In your definition agility sounds like the absence of pragmatism.

mikekchar 11y ago
I've tried about 3 times to respond to your comment because I believe it deserves a response. Alas, I am not yet expert enough to write what needs to be said in a format smaller than a book ;-) Hopefully a few clues will lead you to a better understanding of what I am trying to convey. There is a difference between the artifacts you are building and the practices you are using to build them. When you are pondering different solutions to the user's problems, you are pondering about the artifacts that you wish to build. In such things, you must be as free as you can be. On the other hand, the practices you use to build those artifacts must necessarily be more strict. If you use a haphazard approach to choosing your practices, you will not be able to refine them. If you choose complicated practices that require large amounts of coordination with other people, you will likewise not be able to refine your practices. The goal, IMHO, is to simplify your practices and maximize your facility with them. There isn't just one way to write software. You need to choose practices that will work for you and your team. The choice of those practices is of paramount importance to the success of your team. It must be things that you are good at and that you can coordinate efficiently on. There isn't a one size fits all. Having said that, you must be very strict about what you are doing because (at least in my experience) most practices are not compatible. Even very subtle changes or misunderstandings can cause various practices to misalign and backfire. So far, what I have said is not specific to "agile" processes. To talk about agile in a public forum is difficult because for many of us old guys the term has been diluted considerably. So keep in mind that this is my opinion (a non-famous, random guy on the internet) and there will be luminaries that disagree (possibly violently ;-) ). I believe that an "agile" process is one in which the main artifact (the software that you are delivering) maintains at least a constant potential for modification over time. Your goal is maximize throughput over time. In my experience, you can actually accelerate throughput over time with the right team/practices. I will steal Ron Jeffries term, "hyper productivity" to refer to this condition. In more clear terms, what you want to say is that at the beginning of the project adding a feature is easy. If you are "agile" then a month or a year from now it is just as easy. If you are "hyper productive", then a month from now it is easier to add a feature. A year from now it is much easier to add features. My assertion (which I can not back up in such a small space) is that if you are inconsistent applying your practices, then you will never reach the level I call "agile", much less "hyper productive". Some people might call this kind of inconsistency, "pragmatism". I do not know if you would be one of those people. I will say, though, that one of the reasons I have put such an effort into writing this response is that I recognise your name from other postings you have made and think that it is not a wasted effort ;-) I have experienced what I refer to as "hyper productivity" on a few projects. It is magical. I know of only one way to get there. In the 30 years I've been in this industry I have never seen a flexible approach to practices achieve it. That doesn't mean it is impossible, but I am doubtful.