"Great. If I ever propose a change, I'll keep that in mind."
So you've never suggested to anyone that they should change to XP or TDD?
"I guess if you've never had good managers that treat your team like professionals, it's no wonder you're suspicious about methodologies"
I see. You want to ignore my argument against methodologies and pretend that it's all about bad managers.
"Me, I'm used to employers telling me what they want done and getting out of the way, so to me it's all just things I might try."
Given that you said this as a response to my comment about a vote on methodologies, I suspect that you've never participated in one either or you would have mentioned it.
"Hmmm, I guess I missed the double-blind studies on object orientation."
You missed the point. The value of object orientation can be derived by studying systems, human behavior cannot. Of course, I recognize that not everybody believes that objection orientation is the ultimate approach, so your invocation of it isn't as effective as you might imagine.
"Hmmm... I guess I'm not seeing how that's possible. If you're working with other people, then you need to agree on some sort of way of working together.... And I think a team also has the right to do work the way they see fit."
Sure there has to be a way to work together as a team, but if you do TDD and I test after coding, that isn't problem unless we want to make it one. In any case, "the team" rarely decides what methodogy is going to be used, it's usually dictated by management or pushed by the team's most anal member. In my 20+ years of experience I've never heard management say "The team is going to vote on what methodology to use".
"Could you point me to the solid, non-anecdotal evidence you based your previous methodology choices on? I'd be fascinated to see it."
There's a long-standing principle of debate that says that he who wants to propose a change has the burden of proof. In any case, I'm not pushing any methodology in particular. The problem with methodologies is that they attempt to replace judgement that takes place with all the facts at hand with a judgement that takes place with none of the facts at hand. Those creating a methodology don't know anything about your project, your team, your company, your business, your budget etc.
"But I don't feel any obligation to get some, any more than I need scientific proof of the value of object orientation, clear naming, preferring simple designs over complex ones, or the particular knot I use tying my shoes"
There's a big difference between having a theory about aspects of code and having a theory based on human behavior. If there's as much evidence that Agile methods are better than there is for object orientation or simple designs I certainly haven't heard about it.
I think it's rather begging the question and insulting to say "I'm always looking for ways to boost my skills, but I'm sure that's not true for everybody."
If methodolgies were typically optional on a person-by-person basis, I'd have no problem with them, but that's almost never the case. So I'm not arguing against people doing what works for them, I arguing for the right to do things the way that works best for me.
If there's solid, non-anecdotal evidence that a new methodology is better, I'll adopt it. Otherwise, I'll do it my own way when I'm allowed to.
MS has a long history of understating system requirements.
I think Linux fans have a tendency to do the same although the practical defintion of "linux" can be a bit fuzzy. It seems when talking about features, we hear about the big linux and when talking about system requirements we hear about the little linux.
"If you write the test first and then make it pass, it feels good. If you're doing TDD properly, your day is a series of small wins, with occasional setbacks. Because you have the safety net of tests, the setbacks are generally small, so your frustration level is low. This is much, much more pleasant than writing tests afterward"
I think this is really a personal statement of how you feel about it, but like any personal opinion, it doesn't necessarily apply to other peoplle.
"The second is the that you can't unlearn something. Once you have written the code, you already have a number of notions and assumptions about the problem. For me at least this makes it harder to come at the problem with the fresh perspective that lets me cover all the interesting angles in my tests"
One must have a number of "notions and assumptions" about the problem before you can write the code or the unit test. I don't think this is a problem.
"The third is that after-the-fact testing can feel kinda pointless. I already think the code works, so the best case is that the tests don't tell me anything. Or, worse, they tell me that I screwed up at some point in the past and now need to rework things. Either way, it's dispiriting."
Again, that's how you feel about it. What I find pointless is rewriting unit tests again and again to follow the rules when writing the unit test once is just as effective.
"Whereas with with post-construction testing, it's usually something that people think they should do, or started to do but gave up."
Just as those managing a TDD project can require that tests be written before code, the manager of a non-TDD project can require unit test for all modules before check-in. Why is it always assumed that some magical transformation of management occurs when an agile process is used?
I think all of these arguments are rather weak. They're all based on an unproven theory of how people are supposed to think, act, and feel.
I was responding within the context of your claim that paired programming is an aspect of XP that makes you more likely to follow the rules. I wasn't suggesting that was the only value it had, although I think it's value is outweighed by it's cost.
I get sooo tired of hearing that xxx is not a silver bullet, but it's really great and we should all use it anyway. We have plenty of holy water and crosses, if you don't have any silver bullets today please don't come back until you do.
If you look back at this thread, what we are really talking about is the alleged benefits of TDD (swithing to a more broad statement about XP in this thread was my error, you were just responding to what I wrote) which really isn't about pair programming.
"Pairing is one obvious thing: for a pair to slack requires a conspiracy rather than an accident or a moment of weakeness."
As far as the idea of paired programming as a way to keep programmers in line is concerned, that goal could probably be acheived without using up an extra programmer. Without a lot of training a clerical worker could probably insure that unit tests were written first, etc.
"Common code ownership is a second: if you are working as a team and truly share the code base, you will have plenty of incentive to get your colleagues to do things right."
As has been noted by others in this discussion, the "incentive to get colleagues to do things 'right'" can be a source of irritation and inefficency. Some programmers have the same traits as retired ladies that sit on their porch looking for tiny infractions of the homeowner association rules.
"You are aware of the body of evidence (academic and business) that shows that while pair programming is less efficient than solo programming (in a lines of code delivered sense) it is nowhere near twice as slow and the code delivered is so considerably higher quality that it more than makes up for the overhead?"
I'm aware that a number of studies like this were conducted improperly. If you indentify which ones you are referring to, I can let you know if they've been debunked.
Although I'm sure one could build a version of Linux that can run on a typical Win98 PC configuration, I doubt that contemporary mainstream distros would run very well on it (if it all).
Anyone who is still using Win98 isn't particularly concerned with system stability and probably wants compatiblity with their old applications: Linux doesn't sound like a good fit.
A better analogy for XP would be for you to give me not a specific recipe for cake, but rather instructions on a baking process that includes rules such as:
Taste the cake before you bake it. Make sure you have another cook working with you. Change the shape of the cake constantly.
I'd say that interfaces rarely matter as much as implementations. The current fad these days is to write modules as if the whole world is going to start using them any day now. Don't hold your breath.
In any case, the fact that you think about interfaces first doesn't necessarily mean you'll create better ones. You could just as easily argue that a programmer thinks "Gee, I've got to write this unit test before I can write any code, so I'll just throw something together".
"What is new is trying to get people to do it methodically, all the time, without exception, without excuses."
This is common to all methodologies. There's nothing in XP that is more likely to get individuals to follow the rules than there is in any other approach.
Some of these guys are great at what they do, but I won't necessarily consider them working programmers. In any case, I doubt that Anders Hejlsberg sits down at his keyboard with somebody looking over his shoulder.
"Thus before you've written any code you're already putting a lot of thought into what's going on with your code."
You describe what developers should do when designing, but there's nothing that forces them to do it just as in more traditional methods.
"The code you write, to pass your test, can be isolated from the rest of the codebase. It is inherently decoupled (at least to a degree)."
Modular code concepts have been around for 25 years, same for unit testing. Nothing new here.
"Which leads to the other aspect of TDD: Eliminate duplication. If you're doing TDD by the book, you ruthlessly excise any duplication in your code. Where you see two blocks of code doing the same thing you refactor them into one block of code"
I'm not sure if that's technically part of TDD or just part of a broader methodology like XP. In any case, this principle also goes back to structured techniques of the 70's.
Yes, these guys are old and experienced, but one shouldn't conclude from that other equally old and equally experienced developers necessarily buy into XP.
I'd also say that most of the methodologists haven't been working programmers for many years. You can't write books, give lectures etc and still work full time as a programmer.
One of the reasons that many methodologists miss this point is that they typically have experience only in simple business applications. Rarely do they have any real-world experience in multi-threaded, multi-process, or real-time systems.
"What XP tries to do, with its "whole-shebang" methodology, is to build in safeguards in the process so that neither managers nor programmers can avoid them"
It's a nice theory, but it doesn't wash. The fact is that under XP companies can still not give you enough time to do all the work, programmers can still avoid writing a good test (even in pairs) etc.
XP advocates are trying to claim that somehow the rules will be followed in XP, but not anywhere else. I can propose methodology ZP where the rules say you must unit test, perform code reviews etc. Then if people don't follow the rules, I can just say "that's not ZP, because you didn't follow the rules to the letter".
It seems to me that test driven development is a great way to generate throw-away code. Writing solid unit tests after you have written the code, provides the same benefits as writing it before except you don't have to write as many incremental tests.
"Most programmers have, at some point or another, had an 'OMG - why on earth did I do that?' moment"
Sure, but the question is what percentage of the time does this happen and is it often enough to justify tying up two programmers all the time.
"The code only gets committed if *both* developers are happy - and that is a sure way to increase the quality of code, since the foibles of an individual are subsumed."
That's an idealistic view. It would be more accurate to say the code gets committed when the more aggressive developer is happy.
Slashdot Mirror
"Great. If I ever propose a change, I'll keep that in mind."
So you've never suggested to anyone that they should change to XP or TDD?
"I guess if you've never had good managers that treat your team like professionals, it's no wonder you're suspicious about methodologies"
I see. You want to ignore my argument against methodologies and pretend that it's all about bad managers.
"Me, I'm used to employers telling me what they want done and getting out of the way, so to me it's all just things I might try."
Given that you said this as a response to my comment about a vote on methodologies, I suspect that you've never participated in one either or you would have mentioned it.
"Hmmm, I guess I missed the double-blind studies on object orientation."
You missed the point. The value of object orientation can be derived by studying systems, human behavior cannot. Of course, I recognize that not everybody believes that objection orientation is the ultimate approach, so your invocation of it isn't as effective as you might imagine.
"Hmmm... I guess I'm not seeing how that's possible. If you're working with other people, then you need to agree on some sort of way of working together.... And I think a team also has the right to do work the way they see fit."
Sure there has to be a way to work together as a team, but if you do TDD and I test after coding, that isn't problem unless we want to make it one. In any case, "the team" rarely decides what methodogy is going to be used, it's usually dictated by management or pushed by the team's most anal member. In my 20+ years of experience I've never heard management say "The team is going to vote on what methodology to use".
"Could you point me to the solid, non-anecdotal evidence you based your previous methodology choices on? I'd be fascinated to see it."
There's a long-standing principle of debate that says that he who wants to propose a change has the burden of proof. In any case, I'm not pushing any methodology in particular. The problem with methodologies is that they attempt to replace judgement that takes place with all the facts at hand with a judgement that takes place with none of the facts at hand. Those creating a methodology don't know anything about your project, your team, your company, your business, your budget etc.
"But I don't feel any obligation to get some, any more than I need scientific proof of the value of object orientation, clear naming, preferring simple designs over complex ones, or the particular knot I use tying my shoes"
There's a big difference between having a theory about aspects of code and having a theory based on human behavior. If there's as much evidence that Agile methods are better than there is for object orientation or simple designs I certainly haven't heard about it.
I think it's rather begging the question and insulting to say "I'm always looking for ways to boost my skills, but I'm sure that's not true for everybody."
If methodolgies were typically optional on a person-by-person basis, I'd have no problem with them, but that's almost never the case. So I'm not arguing against people doing what works for them, I arguing for the right to do things the way that works best for me.
If there's solid, non-anecdotal evidence that a new methodology is better, I'll adopt it. Otherwise, I'll do it my own way when I'm allowed to.
MS has a long history of understating system requirements.
I think Linux fans have a tendency to do the same although the practical defintion of "linux" can be a bit fuzzy. It seems when talking about features, we hear about the big linux and when talking about system requirements we hear about the little linux.
"If you write the test first and then make it pass, it feels good. If you're doing TDD properly, your day is a series of small wins, with occasional setbacks. Because you have the safety net of tests, the setbacks are generally small, so your frustration level is low. This is much, much more pleasant than writing tests afterward"
I think this is really a personal statement of how you feel about it, but like any personal opinion, it doesn't necessarily apply to other peoplle.
"The second is the that you can't unlearn something. Once you have written the code, you already have a number of notions and assumptions about the problem. For me at least this makes it harder to come at the problem with the fresh perspective that lets me cover all the interesting angles in my tests"
One must have a number of "notions and assumptions" about the problem before you can write the code or the unit test. I don't think this is a problem.
"The third is that after-the-fact testing can feel kinda pointless. I already think the code works, so the best case is that the tests don't tell me anything. Or, worse, they tell me that I screwed up at some point in the past and now need to rework things. Either way, it's dispiriting."
Again, that's how you feel about it. What I find pointless is rewriting unit tests again and again to follow the rules when writing the unit test once is just as effective.
"Whereas with with post-construction testing, it's usually something that people think they should do, or started to do but gave up."
Just as those managing a TDD project can require that tests be written before code, the manager of a non-TDD project can require unit test for all modules before check-in. Why is it always assumed that some magical transformation of management occurs when an agile process is used?
I think all of these arguments are rather weak. They're all based on an unproven theory of how people are supposed to think, act, and feel.
I was responding within the context of your claim that paired programming is an aspect of XP that makes you more likely to follow the rules. I wasn't suggesting that was the only value it had, although I think it's value is outweighed by it's cost.
I get sooo tired of hearing that xxx is not a silver bullet, but it's really great and we should all use it anyway. We have plenty of holy water and crosses, if you don't have any silver bullets today please don't come back until you do.
If you look back at this thread, what we are really talking about is the alleged benefits of TDD (swithing to a more broad statement about XP in this thread was my error, you were just responding to what I wrote) which really isn't about pair programming.
"Pairing is one obvious thing: for a pair to slack requires a conspiracy rather than an accident or a moment of weakeness."
As far as the idea of paired programming as a way to keep programmers in line is concerned, that goal could probably be acheived without using up an extra programmer. Without a lot of training a clerical worker could probably insure that unit tests were written first, etc.
"Common code ownership is a second: if you are working as a team and truly share the code base, you will have plenty of incentive to get your colleagues to do things right."
As has been noted by others in this discussion, the "incentive to get colleagues to do things 'right'" can be a source of irritation and inefficency. Some programmers have the same traits as retired ladies that sit on their porch looking for tiny infractions of the homeowner association rules.
"You are aware of the body of evidence (academic and business) that shows that while pair programming is less efficient than solo programming (in a lines of code delivered sense) it is nowhere near twice as slow and the code delivered is so considerably higher quality that it more than makes up for the overhead?"
I'm aware that a number of studies like this were conducted improperly. If you indentify which ones you are referring to, I can let you know if they've been debunked.
Although I'm sure one could build a version of Linux that can run on a typical Win98 PC configuration, I doubt that contemporary mainstream distros would run very well on it (if it all).
Anyone who is still using Win98 isn't particularly concerned with system stability and probably wants compatiblity with their old applications: Linux doesn't sound like a good fit.
A better analogy for XP would be for you to give me not a specific recipe for cake, but rather instructions on a baking process that includes rules such as:
Taste the cake before you bake it.
Make sure you have another cook working with you.
Change the shape of the cake constantly.
I'd say that interfaces rarely matter as much as implementations. The current fad these days is to write modules as if the whole world is going to start using them any day now. Don't hold your breath.
In any case, the fact that you think about interfaces first doesn't necessarily mean you'll create better ones. You could just as easily argue that a programmer thinks "Gee, I've got to write this unit test before I can write any code, so I'll just throw something together".
"What is new is trying to get people to do it methodically, all the time, without exception, without excuses."
This is common to all methodologies. There's nothing in XP that is more likely to get individuals to follow the rules than there is in any other approach.
Some of these guys are great at what they do, but I won't necessarily consider them working programmers. In any case, I doubt that Anders Hejlsberg sits down at his keyboard with somebody looking over his shoulder.
"Thus before you've written any code you're already putting a lot of thought into what's going on with your code."
You describe what developers should do when designing, but there's nothing that forces them to do it just as in more traditional methods.
"The code you write, to pass your test, can be isolated from the rest of the codebase. It is inherently decoupled (at least to a degree)."
Modular code concepts have been around for 25 years, same for unit testing. Nothing new here.
"Which leads to the other aspect of TDD: Eliminate duplication. If you're doing TDD by the book, you ruthlessly excise any duplication in your code. Where you see two blocks of code doing the same thing you refactor them into one block of code"
I'm not sure if that's technically part of TDD or just part of a broader methodology like XP. In any case, this principle also goes back to structured techniques of the 70's.
Yes, these guys are old and experienced, but one shouldn't conclude from that other equally old and equally experienced developers necessarily buy into XP.
I'd also say that most of the methodologists haven't been working programmers for many years. You can't write books, give lectures etc and still work full time as a programmer.
Please explain in detail how TDD insures better code? And please, don't just list unproven claims (e.g. "better design, better decoupling..").
"He writes code, and thinks about the process of writing code."
What production code has Beck personally written in the last 5 years? Or perhaps you mean he's a "paper" programmer.
One of the reasons that many methodologists miss this point is that they typically have experience only in simple business applications. Rarely do they have any real-world experience in multi-threaded, multi-process, or real-time systems.
Even if you write the test after the code, you still have the test around to rerun, so writing the test first offers no advanage there.
"What XP tries to do, with its "whole-shebang" methodology, is to build in safeguards in the process so that neither managers nor programmers can avoid them"
It's a nice theory, but it doesn't wash. The fact is that under XP companies can still not give you enough time to do all the work, programmers can still avoid writing a good test (even in pairs) etc.
XP advocates are trying to claim that somehow the rules will be followed in XP, but not anywhere else. I can propose methodology ZP where the rules say you must unit test, perform code reviews etc. Then if people don't follow the rules, I can just say "that's not ZP, because you didn't follow the rules to the letter".
Since Ken Beck isn't really a programmer it isn't surprising.
As any old married couple can tell you, being in the same room doesn't guarantee communication.
It seems to me that test driven development is a great way to generate throw-away code. Writing solid unit tests after you have written the code, provides the same benefits as writing it before except you don't have to write as many incremental tests.
"Most programmers have, at some point or another, had an 'OMG - why on earth did I do that?' moment"
Sure, but the question is what percentage of the time does this happen and is it often enough to justify tying up two programmers all the time.
"The code only gets committed if *both* developers are happy - and that is a sure way to increase the quality of code, since the foibles of an individual are subsumed."
That's an idealistic view. It would be more accurate to say the code gets committed when the more aggressive developer is happy.