The code done yesterday should be as good as you could make it yesterday. The fact that you know more today, and are more capable today, is good news about today, not bad news about yesterday. --Ron Jeffries
In my experience, pair programming works for debugging and integrating code -- and not so well for creating it.
How odd. In my experience pair programming works really well for writing code... and, together with TDD and other practices, dramatically reduces the need for debugging.
An immortal and single-minded worm sits at one end of a 1km long rubber rope. The worm travels at a steady 1cm/sec toward the other end. The rope in infinitely and uniformly elastic. At the end of each second, the rope stretches (uniformly) by 1km. Does the worm ever reach the other end of the rope? If so, when?
my mother, and my kids will click on the ads. Then I have to spend time cleaning up the mess.
Ads in magazines aren't active, they don't make a mess in your living room just because you read them. If web ads didn't leave a bunch of pop-ups and malware, I probably wouldn't bother.
Last time I looked, gEDA had no support for VHDL. There is a GHDL project that is sort of useful, for simulation only. For FPGA synthesis, you're pretty much stuck with the Xilinx (or other commercial) tools. Xilinx webpack is available for free (though it's limited), and I've heard that the command line utilities can be made to run under wine. There are also linux versions of the tools, but I don't know if they have the same availability as Webpack.
I have a copy of a cherished memo written by a colonel in the Marine Corp. The title of the memo is "Ada Compilers Don't Work". The Colonel wrote this memo because on two projects he was in charge of, Ada was incapable of providing the required performance. I worked on one of those projects and the worst part of the codebase was the part that dealt with the inadequacies of Ada threading. It's been several years since I worked in for a DoD contractor, but the last time I talked to my former employer, the directive to use Ada for everything had been rescinded. The DoD simply got more bang for its buck by following what was commercially viable.
I'd like some clarification. Consider a device running a plain vanilla distribution of uClinux. In addition to the uClinux and associated code, there is a driver and an application written from scratch.
Exactly what source code would the company be required to produce on demand?
1) uClinux (a given) 2) the custom driver? 3) the application source code?
By suggesting that XP is hacking, you've done damage to the XP community.
XP is most definitely not hacking. XP does not suggest coding without considering design. In fact, XP means designing each and every step of the way, redesigning as (if) necessary, and ensuring that the design is not only testable, but tested (frequently).
Your comments are typical for someone talking about XP without actually learning anything about it.
I think you should figure out your approach first, then do some coding, then figure out how best to test your idea, but that's just me
Writing a test first means: 1) the code is testable (it's amazing how much sh^Htuff out there isn't)
2) You know how to test it.
3) The test can be run any time, many times.
4) If somebody (maybe even you) comes along later and breaks the code, the test will likely catch it.
1. I'm antisocial. I definitely do NOT want to hang around with some other programmer day in, day out. I would be extremely uncomfortable with the constant presence of another person.
How sad. If you don't see anything wrong with the situation, there isn't anything anyone can do to help. I'm pretty certain we have a lot more fun than you do at work.
2. Pair programming basically means that one person is actually coding while the other harasses him, making him explain every little thing he's doing. I'd last about an hour in this sort of arrangement; then I'd probably do something unspeakably rude. Nobody likes to be constantly nagged, and no one likes to be second guessed.
Clearly you've never pair programmed. Pair programming is sharing the ideas and the workload. Nobody just sits back and nags. If anybody does that, they aren't pair programming.
3. While I'm on the subject, I need peace and quiet to think. I need a cubicle where I can stretch out and just ponder what I'm doing every now and then; to reflect on a bug, for instance, and let ideas come rolling in out of my subconscious. The constant yammering of another person would eliminate any chance of any of that.
Everyone needs peace and quiet from time to time. If you have so little respect for your coworkers that anything they say is 'constant yammering', then I submit that the problem is not with your coworkers.
4. Finally, two people on one computer? Shouldn't they be breaking up their modules and programming in parallel, getting done in half the time? Why is only one person coding at a time, and why doesn't anyone think the second person is mostly being wasted?
If you actually looked into the economics of it you'd find that pair programming only increases the initial cost of the code. Over the life cycle of the application, the reduction in bugs brings the cost down so pair programming beats separate programming.
It's so nice to find out that I'm not the only person who hates this idea...
You're certainly not the only one who hates XP. And certainly not the only one who hates it without actually knowing anything about it.
Questions:
How many open bugs are there on your current project? Or,... maybe it would be easier this way: How many digits do you need to represent your bug count?
If you could reduce your bug count to zero, or so close to zero that it almost didn't matter, would that be worth something to you? Would it be worth reconsidering your blind rejection of something that has been shown to work?
If you read even a little bit of the XP literature, you will find that it advocates continuous design, not a lack of design.
When you design all the time, and you get immediate feedback about how your design decisions are working out,... you get better (even if you are good already).
Certainly, some people use XP as a facade for shoddy programming practices. XP requires discipline, the ability to want to do what is neccesary even if it is unpleasent. I'd love to revoke the scam artist's rights to claim that they are using XP, when they are really using Code/Fix/Pray.
Printing out a hardcopy of a design, so some PHB's can sign it, makes some people feel better. Not me... not after 20 years of seeing the requirements change every time the phone rings.
XP practices currently include 'sustainable pace', which/may/ mean no overtime, but doesn't impose an artificial constraint. What it really means is that developers need to be responsible for their own well being so that they can be productive.
Commercial aircraft operate in a relatively safe environment.
Combat helicopters spend a lot of their time close to the ground, hiding behind ridge-lines, trees, buildings, medium sized rocks, tall tarantulas,... In this environment, the pilot's attention is OUTSIDE the cockpit. He doesn't get to look at his instruments nearly as often as other pilots. If he did, he'd run into something in seconds. Now add night vision goggles, which kills a lot of depth perception. I have a lot of respect for those rotor-heads.
You simply cannot compare commercial aviation with combat avaition. If you want a comparison, you need to look at commercial rotorcraft vs. commercial aircraft... or some other apples & apples comparison.
Slashdot Mirror
Actually, I think it's the equivalent of bringing a club to a gunfight.
The code done yesterday should be as good as you could make it
yesterday. The fact that you know more today, and are more capable
today, is good news about today, not bad news about yesterday.
--Ron Jeffries
Don't allow pillage and paste coding. Duplicated code should be refactored.
How odd. In my experience pair programming works really well for writing code... and, together with TDD and other practices, dramatically reduces the need for debugging.
I saw this one first in Scientific American (a long time ago). As I recall the answer was:
e^(10000 - y), where y is Euler's constant.
I think it works out to 10^43429
An immortal and single-minded worm sits at one end of a 1km long rubber rope. The worm travels at a steady 1cm/sec toward the other end. The rope in infinitely and uniformly elastic. At the end of each second, the rope stretches (uniformly) by 1km. Does the worm ever reach the other end of the rope? If so, when?
Ads in magazines aren't active, they don't make a mess in your living room just because you read them. If web ads didn't leave a bunch of pop-ups and malware, I probably wouldn't bother.
I hate playing whack-a-mole.
If petroleum is dino-juice, what do we call this stuff?
Last time I looked, gEDA had no support for VHDL. There is a GHDL project that is sort of useful, for simulation only. For FPGA synthesis, you're pretty much stuck with the Xilinx (or other commercial) tools. Xilinx webpack is available for free (though it's limited), and I've heard that the command line utilities can be made to run under wine. There are also linux versions of the tools, but I don't know if they have the same availability as Webpack.
I have a copy of a cherished memo written by a colonel in the Marine Corp. The title of the memo is "Ada Compilers Don't Work". The Colonel wrote this memo because on two projects he was in charge of, Ada was incapable of providing the required performance. I worked on one of those projects and the worst part of the codebase was the part that dealt with the inadequacies of Ada threading. It's been several years since I worked in for a DoD contractor, but the last time I talked to my former employer, the directive to use Ada for everything had been rescinded. The DoD simply got more bang for its buck by following what was commercially viable.
Burnin's too good for him...
He should be torn into itsy bitsy pieces and BURIED ALIVE!
We've slashdotted the Mayo Clinic.
I'd like some clarification. Consider a device running a plain vanilla distribution of uClinux. In addition to the uClinux and associated code, there is a driver and an application written from scratch.
Exactly what source code would the company be required to produce on demand?
1) uClinux (a given)
2) the custom driver?
3) the application source code?
Thank you very much
By suggesting that XP is hacking, you've done damage to the XP community.
XP is most definitely not hacking. XP does not suggest coding without considering design. In fact, XP means designing each and every step of the way, redesigning as (if) necessary, and ensuring that the design is not only testable, but tested (frequently).
Writing a test first means:
1) the code is testable (it's amazing how much sh^Htuff out there isn't)
2) You know how to test it.
3) The test can be run any time, many times.
4) If somebody (maybe even you) comes along later and breaks the code, the test will likely catch it.
How sad. If you don't see anything wrong with the situation, there isn't anything anyone can do to help. I'm pretty certain we have a lot more fun than you do at work.
Clearly you've never pair programmed. Pair programming is sharing the ideas and the workload. Nobody just sits back and nags. If anybody does that, they aren't pair programming.
Everyone needs peace and quiet from time to time. If you have so little respect for your coworkers that anything they say is 'constant yammering', then I submit that the problem is not with your coworkers.
If you actually looked into the economics of it you'd find that pair programming only increases the initial cost of the code. Over the life cycle of the application, the reduction in bugs brings the cost down so pair programming beats separate programming.
You're certainly not the only one who hates XP. And certainly not the only one who hates it without actually knowing anything about it.
Questions:
How many open bugs are there on your current project? Or,
If you could reduce your bug count to zero, or so close to zero that it almost didn't matter, would that be worth something to you? Would it be worth reconsidering your blind rejection of something that has been shown to work?
(apologies to Ron Jeffries)
If you read even a little bit of the XP literature, you will find that it advocates continuous design, not a lack of design.
... you get better (even if you are good already).
When you design all the time, and you get immediate feedback about how your design decisions are working out,
Certainly, some people use XP as a facade for shoddy programming practices. XP requires discipline, the ability to want to do what is neccesary even if it is unpleasent. I'd love to revoke the scam artist's rights to claim that they are using XP, when they are really using Code/Fix/Pray.
Printing out a hardcopy of a design, so some PHB's can sign it, makes some people feel better. Not me... not after 20 years of seeing the requirements change every time the phone rings.
XP practices currently include 'sustainable pace', which /may/ mean no overtime, but doesn't impose an artificial constraint. What it really means is that developers need to be responsible for their own well being so that they can be productive.
a slashdotting improved a site.
I won't given the color scheme.
Another list that might bear fruit is the WELC list. a.k.a. Working Effectively with Legacy Code.
But you can boot from flash...
Commercial aircraft operate in a relatively safe environment.
... In this environment, the pilot's attention is OUTSIDE the cockpit. He doesn't get to look at his instruments nearly as often as other pilots. If he did, he'd run into something in seconds. Now add night vision goggles, which kills a lot of depth perception. I have a lot of respect for those rotor-heads.
Combat helicopters spend a lot of their time close to the ground, hiding behind ridge-lines, trees, buildings, medium sized rocks, tall tarantulas,
You simply cannot compare commercial aviation with combat avaition. If you want a comparison, you need to look at commercial rotorcraft vs. commercial aircraft... or some other apples & apples comparison.
I'm not a teacher either... I'm a developer. There's a reason I have computers around to count things for me :-)