So, you're saying that in an instance where you are unsure of who your customer is, or what they want, then XP doesn't make sense, and traditional methodologies are more effective?
One of the requirements of XP is that the customer is on-site, so if you don't even know who the customer is you can't do XP. If you don't even know who your customer is no methodology will be effective.
What about instances where what the customer wants changes over time (new business strategy; new tactical goals; change in company emphasis) - how well does XP deal with those cases?
That's one of the main points of XP. What the customer wants always changes over time. XP deals with that by working in short (three-week) iterations instead of trying to figure the whole thing out up front. Every iteration the customer can completely change their mind about what they want.
Please check out XProgramming.com and ExtremeProgramming.org. You'll get a much better idea of what it's about from those sites than you will from me or from a short article.
j
"It's not whether or not you're paranoid. It's whether or not you're paranoid enough."
XP is NOT against design. It's against designing the entire thing up-front, because that never works. In XP the design is continuous and iterative, and is expressed in code instead of in documentation.
j
"It's not whether or not you're paranoid. It's whether or not you're paranoid enough."
> For instance, what you're going to run into is a situation whereby design decisions you made during round 1 of development hamstring possibilities for developing rounds 3 or 4.
That's what refactoring is for.
> Good design can help to take some of this into account. If you know that the customer is going to want Y in 6 months, then you'll develop to be compatible with Y, as opposed to doing something different that will be faster to develop now but harder to integrate later.
Sure, if you know that the customer is going to want Y is 6 months, and you know how Y is going to be designed. If you know everything that the customer is going to want and how it will be designed and none of that is going to change between now and when the project is finished, use a waterfall methodolgy. For the other ~99.99%
of software projects, refactoring works, and you don't waste time developing to be compatible with something that probably won't happen anyway.
> Overall XP does seem to have some good points, but so does the general writing on making programmers' lives easier in general. I'm afraid I view XP as merely a way of getting rid of Configuration Management
You haven't read what XP is, then. It's a way of developing the software that the customer wants. There's nothing about getting rid of configuration management.
j
"It's not whether or not you're paranoid. It's whether or not you're paranoid enough."
No offense, but it's obvious you didn't take the time to learn what XP is before posting that. It reads much more like an argument for XP than an argument against it.
XP is an iterative approach in which the design evolves naturally and the customers and programmers are always involved in constant communication. In XP there are no "specs handed to us from project managers." The "Planning Game" involves customers and programmers and produces "User Stories" (which replace requirements specs) that the programmers understand and are simple enough to estimate. The customer decides which stories to have the programmers implement during the next three-week iteration, based on the programmers' estimates of how much can be done during that time. The customer is required to be on-site and availabe to converse with the programmers whenever questions arise. XP is most definitely not designed to take power away from the programmers. Why on earth would programmers design a methodolgy to take power away from themselves?
j
"It's not whether or not you're paranoid. It's whether or not you're paranoid enough."
> First of all do customers ever even know what they want.
Never. XP assumes that customers don't really know what they want and will change their minds anyway. That's why iteration planning is conversation between the progammmers and the customers, the iterations are short (three weeks), and the customer is on-site to answer questions as they come up.
> Second, I am sure that programmers can program given just one feature but from my experience I think that its important to get a good look at the forest over the trees.
Given that customers don't know what they want and will change their minds, how can you possibly see the forest? What you think is the forest today will most likely turn out to be completely different a month from now.
> Many good programmers are not good at evaluating their own work.
That's another reason why iterations are short. Programmers can with a little practice estimate for the next three weeks pretty accurately, and certainly better than somebody who has no concept of the technical issues. Anything much longer than that is just a guess no matter who does the estimating.
j
"It's not whether or not you're paranoid. It's whether or not you're paranoid enough."
That's why the iterations are short (XP suggests 3 weeks) and the customer must be on-site and available to answer the programmers' questions as they come up.
The article is just a brief overview and so it may be misleading, but XP most definitely does not assume that any up-front information, from the customer or otherwise, is perfect. Quite the contrary, it assumes that requirements will change, and that the current design will need to change.
j
"It's not whether or not you're paranoid. It's whether or not you're paranoid enough."
In XP, design is not missing, it's continuous. You don't stop designing until the software is finished.
Trying to design everything up front and then just code it never works, for several reasons. First of all, no customers can ever tell you exactly and completely what they really want up front, and even if they could, they always change their minds before the project is finished. Secondly, the design is never completely correct anyway. You will always learn things about the problem during coding that you didn't take into account during design. XP accepts these realities and provides a way to deal with them.
j
"It's not whether or not you're paranoid. It's whether or not you're paranoid enough."
XP has unit tests and acceptance tests. The unit tests are for the programmers, so they're written by the programmers. They test the classes to make sure that they do what they're supposed to do. They allow the programmer to spend more time programming and less time debugging, which is beneficial in any methodolgy. They also allow the programmer to make design changes to existing code without breaking it, which is essential to XP. j
"It's not whether or not you're paranoid. It's whether or not you're paranoid enough."
"...we should boycott rubbish authors like katz and en masse not post in response to this threads, thus killing off this dubious dabble in journalism."
Why? So much wonderfully intelligent discussion results from posting in response to his rubbish.
Seriously.
j
"It's not whether or not you're paranoid. It's whether or not you're paranoid enough."
For those of you who don't want to wade through that entire post, here it is with the noise filtered out to reveal the clean signal.
"The sky is falling...how valuable information has become in the Digital Age...the sky is falling"
Yes, there is a kind of war going on, but the enemy is anybody who would suppress the free exchange of information, and most of these oppressors are NOT coporations.
Of course, I could be totally wrong.
j
"It's not whether or not you're paranoid. It's whether or not you're paranoid enough."
> And if someone actually found a fast way to factorize large numbers, then not only is RSA "dead in the water" but also pretty much every single other widely-used crypto algorithm.
Actually, no. It wouldn't affect symmetric algorithms or elliptic curve public-key algorithms at all, and it would (probably) only affect Diffie-Hellman if the technique also solved discrete logarithms quickly.
j
"It's not whether or not you're paranoid. It's whether or not you're paranoid enough."
Not to mention the volume of intelligent discussion that results from his posts. I'm all for the open exchange of ideas and a JonKatz post is an incredibly effective catalyst for that, whether or not you agree with what he says. In fact, it's probably because so many people disagree, myself included. j
"It's not whether or not you're paranoid. It's whether or not you're paranoid enough."
I couldn't agree more, and I don't think it's limited to Slashdot. I've been on the Internet for a decade now, and I don't see this growing problem. If anything, I think it already peaked and is getting better. I think the social "problems" that Jon points out are just characteristics of human nature that have been around for thousands of years. The net just made them much more visible. In fact, the problems will probably begin to go away, if they haven't already, because they're much more visible now.
What I am seeing is an increasingly well-informed general public as a result of the beautifully unrestricted nature of the net. I don't think it's an exageration to say that the Internet has had the most profound positive effect on the free exchange of information since the printing press. Of course there will be growing pains initially, but the future looks very bright to me. People want to exchange information freely and nothing is going to stifle that.
j
"It's not whether or not you're paranoid. It's whether or not you're paranoid enough."
Actually, Bruce recommends 3DES over Blowfish or Twofish or any other block cipher, citing the fact that DES has been around for so long and still no major weaknesses have been found. In his comment in the Cryptogram that you refer to, he uses Twofish as an example of one of the fastest block ciphers, which it is. He makes no claims about its security. And I don't know exactly how long Twofish has been around, but I know it's been longer than 4 months. As another reader pointed out, it's been around at least since the AES candidates were announced in August of 1998, and I very clearly remember reading about Twofish and the fact that Bruce was planning on submitting it in mid '97. j
"It's not whether or not you're paranoid. It's whether or not you're paranoid enough."
Actually, Bruce recommends 3DES over Blowfish or Twofish or any other block cipher, citing the fact that DES has been around for so long and still no major weaknesses have been found. In his comment in the Cryptogram that you refer to, he uses Twofish as an example of one of the fastest block ciphers, which it is. He makes no claims about its security. And I don't know exactly how long Twofish has been around, but I know it's been longer than 4 months. As another reader pointed out, it's been around at least since the AES candidates were announced in August of 1998, and I very clearly remember reading about Twofish and the fact that Bruce was planning on submitting it in mid '97. j
"It's not whether or not you're paranoid. It's whether or not you're paranoid enough."
Slashdot Mirror
j
"It's not whether or not you're paranoid. It's whether or not you're paranoid enough."
One of the requirements of XP is that the customer is on-site, so if you don't even know who the customer is you can't do XP. If you don't even know who your customer is no methodology will be effective.
That's one of the main points of XP. What the customer wants always changes over time. XP deals with that by working in short (three-week) iterations instead of trying to figure the whole thing out up front. Every iteration the customer can completely change their mind about what they want.
Please check out XProgramming.com and ExtremeProgramming.org. You'll get a much better idea of what it's about from those sites than you will from me or from a short article.
j
"It's not whether or not you're paranoid. It's whether or not you're paranoid enough."
XP is NOT against design. It's against designing the entire thing up-front, because that never works. In XP the design is continuous and iterative, and is expressed in code instead of in documentation.
j
"It's not whether or not you're paranoid. It's whether or not you're paranoid enough."
> For instance, what you're going to run into is a situation whereby design decisions you made during round 1 of development hamstring possibilities for developing rounds 3 or 4.
That's what refactoring is for.
> Good design can help to take some of this into account. If you know that the customer is going to want Y in 6 months, then you'll develop to be compatible with Y, as opposed to doing something different that will be faster to develop now but harder to integrate later.
Sure, if you know that the customer is going to want Y is 6 months, and you know how Y is going to be designed. If you know everything that the customer is going to want and how it will be designed and none of that is going to change between now and when the project is finished, use a waterfall methodolgy. For the other ~99.99% of software projects, refactoring works, and you don't waste time developing to be compatible with something that probably won't happen anyway.
> Overall XP does seem to have some good points, but so does the general writing on making programmers' lives easier in general. I'm afraid I view XP as merely a way of getting rid of Configuration Management
You haven't read what XP is, then. It's a way of developing the software that the customer wants. There's nothing about getting rid of configuration management.
j
"It's not whether or not you're paranoid. It's whether or not you're paranoid enough."
It's finished when all the user stories that the customer selected have been implemented.
j
"It's not whether or not you're paranoid. It's whether or not you're paranoid enough."
No offense, but it's obvious you didn't take the time to learn what XP is before posting that. It reads much more like an argument for XP than an argument against it.
XP is an iterative approach in which the design evolves naturally and the customers and programmers are always involved in constant communication. In XP there are no "specs handed to us from project managers." The "Planning Game" involves customers and programmers and produces "User Stories" (which replace requirements specs) that the programmers understand and are simple enough to estimate. The customer decides which stories to have the programmers implement during the next three-week iteration, based on the programmers' estimates of how much can be done during that time. The customer is required to be on-site and availabe to converse with the programmers whenever questions arise. XP is most definitely not designed to take power away from the programmers. Why on earth would programmers design a methodolgy to take power away from themselves?
j
"It's not whether or not you're paranoid. It's whether or not you're paranoid enough."
> First of all do customers ever even know what they want.
Never. XP assumes that customers don't really know what they want and will change their minds anyway. That's why iteration planning is conversation between the progammmers and the customers, the iterations are short (three weeks), and the customer is on-site to answer questions as they come up.
> Second, I am sure that programmers can program given just one feature but from my experience I think that its important to get a good look at the forest over the trees.
Given that customers don't know what they want and will change their minds, how can you possibly see the forest? What you think is the forest today will most likely turn out to be completely different a month from now.
> Many good programmers are not good at evaluating their own work.
That's another reason why iterations are short. Programmers can with a little practice estimate for the next three weeks pretty accurately, and certainly better than somebody who has no concept of the technical issues. Anything much longer than that is just a guess no matter who does the estimating.
j
"It's not whether or not you're paranoid. It's whether or not you're paranoid enough."
That's why the iterations are short (XP suggests 3 weeks) and the customer must be on-site and available to answer the programmers' questions as they come up.
The article is just a brief overview and so it may be misleading, but XP most definitely does not assume that any up-front information, from the customer or otherwise, is perfect. Quite the contrary, it assumes that requirements will change, and that the current design will need to change.
j
"It's not whether or not you're paranoid. It's whether or not you're paranoid enough."
In XP, design is not missing, it's continuous. You don't stop designing until the software is finished.
Trying to design everything up front and then just code it never works, for several reasons. First of all, no customers can ever tell you exactly and completely what they really want up front, and even if they could, they always change their minds before the project is finished. Secondly, the design is never completely correct anyway. You will always learn things about the problem during coding that you didn't take into account during design. XP accepts these realities and provides a way to deal with them.
j
"It's not whether or not you're paranoid. It's whether or not you're paranoid enough."
XP has unit tests and acceptance tests. The unit tests are for the programmers, so they're written by the programmers. They test the classes to make sure that they do what they're supposed to do. They allow the programmer to spend more time programming and less time debugging, which is beneficial in any methodolgy. They also allow the programmer to make design changes to existing code without breaking it, which is essential to XP.
j
"It's not whether or not you're paranoid. It's whether or not you're paranoid enough."
XP is a software development methodology. Check out XProgramming.com or ExtremeProgramming.org for more information.
j
"It's not whether or not you're paranoid. It's whether or not you're paranoid enough."
"An entire generation railed against the pot laws, and did not prevail. So what in the HELL can we do about RealAudio? Nothing, I fear."
That generation didn't have the Internet.
j
"It's not whether or not you're paranoid. It's whether or not you're paranoid enough."
"...we should boycott rubbish authors like katz and en masse not post in response to this threads, thus killing off this dubious dabble in journalism."
Why? So much wonderfully intelligent discussion results from posting in response to his rubbish.
Seriously.
j
"It's not whether or not you're paranoid. It's whether or not you're paranoid enough."
For those of you who don't want to wade through that entire post, here it is with the noise filtered out to reveal the clean signal.
"The sky is falling...how valuable information has become in the Digital Age...the sky is falling"
Yes, there is a kind of war going on, but the enemy is anybody who would suppress the free exchange of information, and most of these oppressors are NOT coporations.
Of course, I could be totally wrong.
j
"It's not whether or not you're paranoid. It's whether or not you're paranoid enough."
> And if someone actually found a fast way to factorize large numbers, then not only is RSA "dead in the water" but also pretty much every single other widely-used crypto algorithm.
Actually, no. It wouldn't affect symmetric algorithms or elliptic curve public-key algorithms at all, and it would (probably) only affect Diffie-Hellman if the technique also solved discrete logarithms quickly.
j
"It's not whether or not you're paranoid. It's whether or not you're paranoid enough."
Not to mention the volume of intelligent discussion that results from his posts. I'm all for the open exchange of ideas and a JonKatz post is an incredibly effective catalyst for that, whether or not you agree with what he says. In fact, it's probably because so many people disagree, myself included.
j
"It's not whether or not you're paranoid. It's whether or not you're paranoid enough."
...and some very good points. Please keep moderating that post (the one I'm replying to) up so that everybody sees it.
j
"It's not whether or not you're paranoid. It's whether or not you're paranoid enough."
I couldn't agree more, and I don't think it's limited to Slashdot. I've been on the Internet for a decade now, and I don't see this growing problem. If anything, I think it already peaked and is getting better. I think the social "problems" that Jon points out are just characteristics of human nature that have been around for thousands of years. The net just made them much more visible. In fact, the problems will probably begin to go away, if they haven't already, because they're much more visible now.
What I am seeing is an increasingly well-informed general public as a result of the beautifully unrestricted nature of the net. I don't think it's an exageration to say that the Internet has had the most profound positive effect on the free exchange of information since the printing press. Of course there will be growing pains initially, but the future looks very bright to me. People want to exchange information freely and nothing is going to stifle that.
j
"It's not whether or not you're paranoid. It's whether or not you're paranoid enough."
Actually, Bruce recommends 3DES over Blowfish or Twofish or any other block cipher, citing the fact that DES has been around for so long and still no major weaknesses have been found. In his comment in the Cryptogram that you refer to, he uses Twofish as an example of one of the fastest block ciphers, which it is. He makes no claims about its security. And I don't know exactly how long Twofish has been around, but I know it's been longer than 4 months. As another reader pointed out, it's been around at least since the AES candidates were announced in August of 1998, and I very clearly remember reading about Twofish and the fact that Bruce was planning on submitting it in mid '97.
j
"It's not whether or not you're paranoid. It's whether or not you're paranoid enough."
Actually, Bruce recommends 3DES over Blowfish or Twofish or any other block cipher, citing the fact that DES has been around for so long and still no major weaknesses have been found. In his comment in the Cryptogram that you refer to, he uses Twofish as an example of one of the fastest block ciphers, which it is. He makes no claims about its security. And I don't know exactly how long Twofish has been around, but I know it's been longer than 4 months. As another reader pointed out, it's been around at least since the AES candidates were announced in August of 1998, and I very clearly remember reading about Twofish and the fact that Bruce was planning on submitting it in mid '97.
j
"It's not whether or not you're paranoid. It's whether or not you're paranoid enough."