I'm the same way. Fortunately, pair programming is an active discussion. It's a lot like the conversation you have in your head while you're writing code, except there are two people involved.
This can be awkward at first, but it's pretty impressive to realize how quickly you can go. If you get stuck, your pair probably has a good idea of what to do next.
You're right, the customer and the developers need to understand the development process. That's why XP requires an active customer.
At least one developer helps the customer write the test cases. The developers work with the customer to refine the story cards until they're estimable. The developers continually go back to the customer to set priorities -- they bring up the technical risks, but allow the customer to decide what to do next.
I know[1] my unit test works because I wrote it before I wrote the code to pass it. Since it failed without the code, I know[1] it's testing what I want to test. Since it passes after I've written the code to pass it, I know[1] it's testing the right thing.
"Profit" and "sell" don't necessarily have anything to do with it. Distributing your derived work without at least offering the accompanying source code is the only way to steal it.
If I write a piece of software, hold the copyright on it, and make it available under the GPL, the GPL gives me no additional rights. I'm not bound by the GPL; as creator and copyright holder, I'm free to charge for the software. I'm free to distribute it under as many licences as I desire. I'm free to relicense it to whomever I choose.
The GPL only covers the rights of third parties who distribute code to which they do not hold copyright. The restriction there is that these third parties must make the code -- or code derived from the code -- available under the same terms as they received it.
Put another way, Red Hat can take my GPLd program and distribute it freely. They can charge for it. They can modify it. If they distribute it to you, either freely or for a fee, they must allow you the same options.
I'm glad to see a group of people with a consistent ethical code -- especially when those ethics haven't compromised for the sake of pragmatism. (I'm even happier when it's an ethical code that complements mine.)
It seems kind of funny to suggest that Debian needs to compromise its principles to "win the desktop", when the goal of Debian has always been to spread free software, not to "win" anything.
XP describes a process without explicit steps for architecture.
I see your point now. Yes, there is no explicit step that says "Only design something right now." However, design is part of the planning game, when developers write and estimate task cards from the stories. (There's your high level design.) Design is part of test-driven development, when the pair asks "What tests can we write to explore the next feature?". (There's your low level design again.) Design is part of refactoring, when the pair asks "This works, but is there a way we can improve its design without changing its functionality?" (There's a mixture of high and low-level design.)
There's no explicit design stage for two reasons. First, it's expected that the ideal design will emerge as the system grows. If the customer is allowed to make changes to the specification, if developers improve their understanding of the business rules and the technology, they're allowed and encouraged to adapt the design accordingly.
Second, because a "proper up-front design" is amazingly difficult to get right, takes a long time to get right, and, if you can reach that point iteratively anyway, doesn't add as much business value as delivering a couple of iterations worth of software in the same time period.
Again, this is most appropriate for projects that are expected to change.
On one project, we had a bug that would always cause a segfault at shutdown. No one had ever been able to track it down -- it wasn't hurting anything as far as we could tell, but it was highly annoying. This was a very small shop and we were just starting XP (or any determinable development process, for that matter), so we hadn't been doing much in the way of pair programming anyway.
Myself and another developer tried pairing to find the bug. We talked it out briefly, and decided to do a binary search of the code with print statements (as the debugger couldn't find it). We'd start the program then exit it, trying to find where in the shutdown process the bug was.
We went over the logs together, and the first person to narrow down another potential location. I'd suggest a spot and add a print statement there, then he'd suggest one. We'd then run the program again, collect our logs, and start over. If I got stuck, he'd have an idea and vice versa.
It took us about ten minutes to track it down and figure out exactly what was going on. I'd spent a couple of hours on it alone without making any progress before, and I think he'd done the same. If we'd paired on that before, we'd have saved a bit of time and money.
I'm not sure where you get the idea that pair programming is having some slob sit behind you and breathe over your shoulder. In my experience, it's like having a conversation about code that produces working code. If you can give up the idea that you have to be right and that your way is the best way and, for goodness' sake, hand over the keyboard about half the time, you'll probably find it's a lot more productive and even more fun than working alone.
By no means! I am merely saying that they're fundamental to XP. If you're attempting to do XP without those, you will need a combination of very lucky and very, very brilliant developers to have a chance of delivering good software on time.
(If you're not doing XP but you are doing those practices, you have a pretty good chance of delivering good software on time.)
Yeah, aren't you glad we live in a world with disciplined designers who don't test their code and never work to customer specifications and don't integrate continually and never run acceptance tests? I'd hate to think about the quality of software we'd have if people did THOSE things!
Exactly. That's a case where XP doesn't provide a compelling benefit. Steve McBreen's Software Craftsmanship draws a sharp distinction between Software Engineering and what the rest of us do.
Re:Design first, or refactor? Re:Origins of XP
on
Why We Refactored JUnit
·
· Score: 2, Informative
That's a good question. Several of the other XP practices work in your favor in that case.
First, if you've been doing the simplest thing that could possibly work, your code is already pretty simple -- it doesn't have superfluous stuff to work around. Second, if you're testing continually, you have a safety net to notify you if you accidentally break the essential behavior. Third, if you've been refactoring continually, the code will be decoupled and much easier to change. Aggressive testing helps this too. Finally, if you're using the planning game to work on half-day features, you're dealing with manageable chunks of code that very rarely touch more than a couple of individual units.
There are times when you have to schedule a couple of days for larger refactorings, but they're not common. If you have intelligent developers who keep up the good practices, the code ends up really clean, really easy to extend, and surprisingly well-designed.
Re:Design first, or refactor? Re:Origins of XP
on
Why We Refactored JUnit
·
· Score: 4, Informative
In a large system it takes a lot of money - an exponential curve, the last 3 bugs will likely take more money than the first 100 - time and a good design.
That assumes that the rate of the cost of change rises over time. XP rejects that assumption, and the XP practices are designed to keep the rate of the cost of change consistent.
Perhaps, if Microsoft were to license its code under GPL so that anyone who wanted to support it in their absence could. Do you see how that improves your analogy?
HanzoSan claimed that the existence of a billion Africans meant that they had an unlimited base of programmers. I responded that there are other factors that exclude many people from being even potential programmers.
Any conclusion involving Americans exists only in your mind, not in my argument.
You can't count every one of a billion Africans as a potential programmer. Not everyone has electricity, for one thing. Of those who do, not everyone can afford a computer -- and there aren't a lot of libraries with public Internet access.
Actually, Alistair Cockburn wrote Agile Software Development (ISBN: 0201699699). Robert Martin wrote Agile Software Development, Principles, Patterns, and Practices (ISBN: 0135974445).
Slashdot Mirror
The only place it's spelled PERL is in the header -- the same place as the LS you quoted. My sincerest apologies for taking your post at face value.
Still, if you're going to be that pedantic, why not use ldc instead of ls?
Parrot has much better support for dynamic languages -- it supports anonymous subroutines, closures, run-time compilation, and other nice features.
Consider calling ls LS then.
I'm the same way. Fortunately, pair programming is an active discussion. It's a lot like the conversation you have in your head while you're writing code, except there are two people involved.
This can be awkward at first, but it's pretty impressive to realize how quickly you can go. If you get stuck, your pair probably has a good idea of what to do next.
You're right, the customer and the developers need to understand the development process. That's why XP requires an active customer.
At least one developer helps the customer write the test cases. The developers work with the customer to refine the story cards until they're estimable. The developers continually go back to the customer to set priorities -- they bring up the technical risks, but allow the customer to decide what to do next.
I know[1] my unit test works because I wrote it before I wrote the code to pass it. Since it failed without the code, I know[1] it's testing what I want to test. Since it passes after I've written the code to pass it, I know[1] it's testing the right thing.
[1] - with about 95% certainty
"Profit" and "sell" don't necessarily have anything to do with it. Distributing your derived work without at least offering the accompanying source code is the only way to steal it.
Cancelling a meeting decreases your productivity? Whoa.
I'm not sure what you mean.
If I write a piece of software, hold the copyright on it, and make it available under the GPL, the GPL gives me no additional rights. I'm not bound by the GPL; as creator and copyright holder, I'm free to charge for the software. I'm free to distribute it under as many licences as I desire. I'm free to relicense it to whomever I choose.
The GPL only covers the rights of third parties who distribute code to which they do not hold copyright. The restriction there is that these third parties must make the code -- or code derived from the code -- available under the same terms as they received it.
Put another way, Red Hat can take my GPLd program and distribute it freely. They can charge for it. They can modify it. If they distribute it to you, either freely or for a fee, they must allow you the same options.
Your understanding is incorrect. See Does the GPL allow me to sell copies of the program for money?
I'm glad to see a group of people with a consistent ethical code -- especially when those ethics haven't compromised for the sake of pragmatism. (I'm even happier when it's an ethical code that complements mine.)
It seems kind of funny to suggest that Debian needs to compromise its principles to "win the desktop", when the goal of Debian has always been to spread free software, not to "win" anything.
I see your point now. Yes, there is no explicit step that says "Only design something right now." However, design is part of the planning game, when developers write and estimate task cards from the stories. (There's your high level design.) Design is part of test-driven development, when the pair asks "What tests can we write to explore the next feature?". (There's your low level design again.) Design is part of refactoring, when the pair asks "This works, but is there a way we can improve its design without changing its functionality?" (There's a mixture of high and low-level design.)
There's no explicit design stage for two reasons. First, it's expected that the ideal design will emerge as the system grows. If the customer is allowed to make changes to the specification, if developers improve their understanding of the business rules and the technology, they're allowed and encouraged to adapt the design accordingly.
Second, because a "proper up-front design" is amazingly difficult to get right, takes a long time to get right, and, if you can reach that point iteratively anyway, doesn't add as much business value as delivering a couple of iterations worth of software in the same time period.
Again, this is most appropriate for projects that are expected to change.
How can there be bugs in code that has never been written?
How can you be sure that your design will never change?
Where do you find customers that give you a complete specification before you start coding?
How do you expect programmers to debug if they can never see the mistakes they make?
On one project, we had a bug that would always cause a segfault at shutdown. No one had ever been able to track it down -- it wasn't hurting anything as far as we could tell, but it was highly annoying. This was a very small shop and we were just starting XP (or any determinable development process, for that matter), so we hadn't been doing much in the way of pair programming anyway.
Myself and another developer tried pairing to find the bug. We talked it out briefly, and decided to do a binary search of the code with print statements (as the debugger couldn't find it). We'd start the program then exit it, trying to find where in the shutdown process the bug was.
We went over the logs together, and the first person to narrow down another potential location. I'd suggest a spot and add a print statement there, then he'd suggest one. We'd then run the program again, collect our logs, and start over. If I got stuck, he'd have an idea and vice versa.
It took us about ten minutes to track it down and figure out exactly what was going on. I'd spent a couple of hours on it alone without making any progress before, and I think he'd done the same. If we'd paired on that before, we'd have saved a bit of time and money.
I'm not sure where you get the idea that pair programming is having some slob sit behind you and breathe over your shoulder. In my experience, it's like having a conversation about code that produces working code. If you can give up the idea that you have to be right and that your way is the best way and, for goodness' sake, hand over the keyboard about half the time, you'll probably find it's a lot more productive and even more fun than working alone.
By no means! I am merely saying that they're fundamental to XP. If you're attempting to do XP without those, you will need a combination of very lucky and very, very brilliant developers to have a chance of delivering good software on time.
(If you're not doing XP but you are doing those practices, you have a pretty good chance of delivering good software on time.)
Yeah, aren't you glad we live in a world with disciplined designers who don't test their code and never work to customer specifications and don't integrate continually and never run acceptance tests? I'd hate to think about the quality of software we'd have if people did THOSE things!
Exactly. That's a case where XP doesn't provide a compelling benefit. Steve McBreen's Software Craftsmanship draws a sharp distinction between Software Engineering and what the rest of us do.
That's a good question. Several of the other XP practices work in your favor in that case.
First, if you've been doing the simplest thing that could possibly work, your code is already pretty simple -- it doesn't have superfluous stuff to work around. Second, if you're testing continually, you have a safety net to notify you if you accidentally break the essential behavior. Third, if you've been refactoring continually, the code will be decoupled and much easier to change. Aggressive testing helps this too. Finally, if you're using the planning game to work on half-day features, you're dealing with manageable chunks of code that very rarely touch more than a couple of individual units.
There are times when you have to schedule a couple of days for larger refactorings, but they're not common. If you have intelligent developers who keep up the good practices, the code ends up really clean, really easy to extend, and surprisingly well-designed.
That assumes that the rate of the cost of change rises over time. XP rejects that assumption, and the XP practices are designed to keep the rate of the cost of change consistent.
Perhaps, if Microsoft were to license its code under GPL so that anyone who wanted to support it in their absence could. Do you see how that improves your analogy?
Nah, that article went up on Thursday afternoon. I'm completely innocent... this time!
They must have missed your review. When did you send it?
HanzoSan claimed that the existence of a billion Africans meant that they had an unlimited base of programmers. I responded that there are other factors that exclude many people from being even potential programmers.
Any conclusion involving Americans exists only in your mind, not in my argument.
You can't count every one of a billion Africans as a potential programmer. Not everyone has electricity, for one thing. Of those who do, not everyone can afford a computer -- and there aren't a lot of libraries with public Internet access.
Actually, Alistair Cockburn wrote Agile Software Development (ISBN: 0201699699). Robert Martin wrote Agile Software Development, Principles, Patterns, and Practices (ISBN: 0135974445).