Do you have that backwards? I've only known a few companies where techies -- much less standard office workers -- could choose their own operating system. Most of those were already quite friendly to Linux or the *BSDs.
Why would a company have to start over if they wanted to sell software licensed under the GNU GPL? Do you mean they'd have to write completely new code?
I agree strongly with the rest of your post, but the word "belongs" may not be appropriate here. If their code is indeed derived from a GPLd program, they must abide by the terms set by the copyright holder to distribute the modified work. The power rests with the copyright holder.
I do urge caution and good faith, though, hoping that this can be resolved amicably.
I meant to offer a suggestion why some people argue for throwing out X and starting over from scratch while removing useful (and even definitive) features. I certainly don't mean to belittle honest experiences or perceptions, nor to suggest that only successful programmers should have opinions of software.
I am willing to be somewhat dismissive of development strategies from people who've never participated in a successful project, though. (Your opinion on that strikes me as reasonable. X11 won't last forever.)
Perhaps many people making that suggestion have never had the luxury of having people actually use their software (if they've ever even written a program before). Practical experience often demonstrates which well-meaning ideas don't actually work out as well anyone'd like.
Tom responded with what I should have responded. My comment was pretty terse and inaccurate. I should have said "Just watching someone code over his shoulder isn't pair programming" the impression I got from your first two points.
Your other points are a matter of opinion and preference; there are some people who honestly try pair programming and really dislike it. That's fine. It's definitely not for everyone or every situation. I work mostly from home these days and wish I could pair more often.
One of the rules of XP is that developers are responsible for their estimates. If you estimate that it will take two weeks to implement a story card per team guidelines (that is, at acceptable levels of quality, testing, and accuracy that the customer and the developers have agreed to), then any team doing XP should abide by that estimate.
The bet is that by doing it right and having a pretty good idea of how long that will take we'll attach a reasonably accurate cost to each development task. Doing it "quick and dirty" tends to build up a technical debt that will have to be paid later.
I won't pretend that I make a good manager, but I agree with you that it's worth doing tasks right.
The problem with XP is that it encourages fast building of extremely (no pun intended) rigid applications, which are a nightmare to extend or maintain, so, unless, you are planning to leave project early, i am not even sure, how you can consider XP as anything more serious then a hype.
If you read past the title of any XP book, you should come across principles such as Testing, Coding Simply, and Refactoring. If you still can't manage to write maintainable code with those practices in place, might I suggest a different career?
XP requires quite a bit of discipline, just like any good process does. The real power, I believe, comes from the interaction of the processes. For example, tt'd be crazy to refactor all of the time, unless you had a comprehensive test suite. It'd be crazy not to design ahead for features you will need in the future, unless you let the customer choose which features to add and when and if you can keep the cost of changing the code low.
A lot of projects adopt a couple of the easier practices without really understanding why they're important and how they fit into XP as a whole. (Extreme Programming Pocket Guide spends most of its time talking about these interactions.) Without either tremendous skill and discipline or other supporting practices that provide what the unpracticed XP practices do, you're bound to crash and burn eventually.
It's okay to pick and choose from the XP practices that your team needs most, but you have to understand what they can and cannot provide.
I think what you're seeing is a lot of teams who like the idea of not doing a lot of up front design and getting rid of a lot of process but who aren't replacing that with the appropriate XP practices or equivalents.
That's why when someone says "We tried XP, but our code turned into a big ball of mud", people who've used XP successfully will ask "How well were you testing?" and "Were you refactoring?" It's not that XP is always appropriate for every situation and every team. It's that if you just copy a few practices without thinking about why they're important, you can get in a lot of trouble.
What I don't like about pair programming as a methodology is that it hides incompetent programmers, reduces the learning that comes from failing at a certain approach, and discourages leaps of faith.
I'm not sure I follow your reasoning.
How does pair programming hide incompetent programmers? If you're switching pairs often, everyone will have the chance to work with everyone else.
Do you prefer a learning style that requires everyone to make the same mistakes? In my teams, I prefer not to make mistakes at all. In practice, I'll settle for making a mistake once then letting everyone know what it was and how to avoid it. Given experienced programmers, it's pretty handy to start down a path and have your pairing partner say, "Wait... we did something like this before. Here's how we solved it then."
I don't know what you mean by "discourages leaps of faith" at all. That sounds like a positive thing to me. I'd rather go by the empericism of the test suite than mystical intuition that can't be verified. XP's pretty firmly in the realm of "solving the customer's actual problems" than any Kierkegaardian philosophy.
Admittedly, I'm a fan of pair programming. I've used it on a couple of projects and plan to use it on several more in the future.
I would have to say that pair programming isn't really worth it. I personally can't stand the lack of productivity that is inherent to having two programmers sit around and watch each other type.
Non sequitur. Your first sentence talks about pair programming. Your second sentence talks about something that is almost entirely unlike pair programming.
Pair programming is "Hey, let's talk about this problem and write some code as we're going along!", not "Hey, sit behind me and shut up unless I make a typo!" If someone's made you do the latter and called it "pair programming", he was quite wrong.
Slashdot Mirror
Do you have that backwards? I've only known a few companies where techies -- much less standard office workers -- could choose their own operating system. Most of those were already quite friendly to Linux or the *BSDs.
Why would a company have to start over if they wanted to sell software licensed under the GNU GPL? Do you mean they'd have to write completely new code?
We have an entire cable channel dedicated to weather!
Do you have a source for this? I'm interested in seeing some statistics. Thanks!
What, throwing away compatibility with thousands of programs that had been developed for years? QuarkXPress users might disagree.
Maybe you do, but I think that's an unfair generalization.
I agree strongly with the rest of your post, but the word "belongs" may not be appropriate here. If their code is indeed derived from a GPLd program, they must abide by the terms set by the copyright holder to distribute the modified work. The power rests with the copyright holder.
I do urge caution and good faith, though, hoping that this can be resolved amicably.
I apologize for being unclear.
I meant to offer a suggestion why some people argue for throwing out X and starting over from scratch while removing useful (and even definitive) features. I certainly don't mean to belittle honest experiences or perceptions, nor to suggest that only successful programmers should have opinions of software.
I am willing to be somewhat dismissive of development strategies from people who've never participated in a successful project, though. (Your opinion on that strikes me as reasonable. X11 won't last forever.)
Perhaps many people making that suggestion have never had the luxury of having people actually use their software (if they've ever even written a program before). Practical experience often demonstrates which well-meaning ideas don't actually work out as well anyone'd like.
A huge step forward for 2003 or for 2005? I can't think of a positive meaning for that claim.
Coroutines go back a lot further than, say, 2001 (when Python 2.2 was released).
Do you mean that PHP does not provide class libraries with names of Decorator and Factory or that a good developer cannot use design patterns in PHP?
Do you mean that languages such as Smalltalk should never have been used for "enterprise applications"?
What stops you from making money from people who want to pay you to create original software?
Tom responded with what I should have responded. My comment was pretty terse and inaccurate. I should have said "Just watching someone code over his shoulder isn't pair programming" the impression I got from your first two points.
Your other points are a matter of opinion and preference; there are some people who honestly try pair programming and really dislike it. That's fine. It's definitely not for everyone or every situation. I work mostly from home these days and wish I could pair more often.
One of the rules of XP is that developers are responsible for their estimates. If you estimate that it will take two weeks to implement a story card per team guidelines (that is, at acceptable levels of quality, testing, and accuracy that the customer and the developers have agreed to), then any team doing XP should abide by that estimate.
The bet is that by doing it right and having a pretty good idea of how long that will take we'll attach a reasonably accurate cost to each development task. Doing it "quick and dirty" tends to build up a technical debt that will have to be paid later.
I won't pretend that I make a good manager, but I agree with you that it's worth doing tasks right.
I dislike those things too.
I like pair programming.
What you describe is not pair programming.
If you read past the title of any XP book, you should come across principles such as Testing, Coding Simply, and Refactoring. If you still can't manage to write maintainable code with those practices in place, might I suggest a different career?
That's a good question.
XP requires quite a bit of discipline, just like any good process does. The real power, I believe, comes from the interaction of the processes. For example, tt'd be crazy to refactor all of the time, unless you had a comprehensive test suite. It'd be crazy not to design ahead for features you will need in the future, unless you let the customer choose which features to add and when and if you can keep the cost of changing the code low.
A lot of projects adopt a couple of the easier practices without really understanding why they're important and how they fit into XP as a whole. (Extreme Programming Pocket Guide spends most of its time talking about these interactions.) Without either tremendous skill and discipline or other supporting practices that provide what the unpracticed XP practices do, you're bound to crash and burn eventually.
It's okay to pick and choose from the XP practices that your team needs most, but you have to understand what they can and cannot provide.
I think what you're seeing is a lot of teams who like the idea of not doing a lot of up front design and getting rid of a lot of process but who aren't replacing that with the appropriate XP practices or equivalents.
That's why when someone says "We tried XP, but our code turned into a big ball of mud", people who've used XP successfully will ask "How well were you testing?" and "Were you refactoring?" It's not that XP is always appropriate for every situation and every team. It's that if you just copy a few practices without thinking about why they're important, you can get in a lot of trouble.
How would you achieve this? I'd probably do things like:
Of course, by the time you do all that, you've got the heart of XP.
I'm not sure I follow your reasoning.
How does pair programming hide incompetent programmers? If you're switching pairs often, everyone will have the chance to work with everyone else.
Do you prefer a learning style that requires everyone to make the same mistakes? In my teams, I prefer not to make mistakes at all. In practice, I'll settle for making a mistake once then letting everyone know what it was and how to avoid it. Given experienced programmers, it's pretty handy to start down a path and have your pairing partner say, "Wait... we did something like this before. Here's how we solved it then."
I don't know what you mean by "discourages leaps of faith" at all. That sounds like a positive thing to me. I'd rather go by the empericism of the test suite than mystical intuition that can't be verified. XP's pretty firmly in the realm of "solving the customer's actual problems" than any Kierkegaardian philosophy.
Admittedly, I'm a fan of pair programming. I've used it on a couple of projects and plan to use it on several more in the future.
Non sequitur. Your first sentence talks about pair programming. Your second sentence talks about something that is almost entirely unlike pair programming.
Pair programming is "Hey, let's talk about this problem and write some code as we're going along!", not "Hey, sit behind me and shut up unless I make a typo!" If someone's made you do the latter and called it "pair programming", he was quite wrong.
You don't pay for bandwidth, system administration, and hardware? I do. Spam definitely costs money and time I'd rather spend elsewhere.
How will making it easier to detect and to reject spoofed e-mail force more spoofing?
Add a TXT record in your domain's DNS saying that senders are permitted from your ISP's SMTP server. See Setting up SPF.
That's the best kind. Those win-win situations where somebody loses are just so sad.