The customer has no figgen clue about what development is or means.
If the person paying you to write software doesn't get to tell you what the software should do, who does?
I went to a fancy restaurant like that once. You pay $150 and get whatever the meal of the day is. Unfortunately, the main course was salmon and I'm allergic to fish, so I left. I heard it was nice, though I've never gone back.
If they have IP that's infringed and they know it, they have to sue to protect it or they lose it by neglect.
This is why the term "intellectual property" is, at best, vague and meaningless. What you said only applies to trademarks. It does not apply to trade secrets, copyrights, or patents.
Almost all of the money made by open source has been made by exploiting open source.
I'd better take back all of my patches then. I sure hope no one else who's ever written free software that I've used directly or indirectly reads your post!
The entire point of this argument though is that any competent developer already checks for all of the cases they can think of, so any unit test they write will automatically pass their code.
I've seen that happen too, but that's not Test-Driven Development. Nearly every unit test I write during TDD fails. That's the point. If one passes, it's a surprise and a warning that I overlooked something.
I do agree that it's useful to have someone other than the original developer try to break the code by coming up with edge cases and common error patterns. Pair programming tends to help there, but there's also room for exploratory testing done by an experienced QA person or a cautious and paranoid developer.
Having the developers create them themselves seems to be a waste of time.
In my experience, any developer worthy of the title "developer" already tests his code, though perhaps not in an automated fashion. I've seen plenty of developers (and I've done this myself) use debug statements to build up a function or method in pieces, checking the output manually each time.
Actual test-driven development (not after-the-fact writing a few half-hearted test cases) is a refinement of that process. It has three benefits. First, it captures those manual tests in a permanent format that I can run any time I want. Second, it gives immediate feedback as to the state of the code and allows me to work in much smaller increments of time. Third, it changes the way I approach code and low-level design. My code tends to be simpler and shorter and more cohesive and less coupled (and much, much easier to test) this way.
Having a poor developer create dozens of lousy tests does no one any good. However, my experience with doing TDD myself (and teaching other people how to do it and writing libraries to help them do it) makes me think that any decent developer who tries to do it seriously and with discipline will produce better code.
For anything other than small projects, XP generates generally unmaintainable code unless it's coupled with strict architectural design guidelines.
... such as refactoring? I'm curious what other XP practices these projects didn't practice.
XP won't make good coders out of bad coders, or allow bad or moderate coders to generate "good" projects, despite what they want you to believe.
I agree with the problem of bad coders, but I'm not aware of any development process that can generate good results from monkeys by anything other than occasional happy accident.
XP is a guaranteed nightmare down the road for maintenance....
Precisely why?
If you require meetings, the team lead should summarize, and then call on anyone needing to supply deeper info, otherwise a small open session for questions, and off to work you go.
Yeah, all those terrible practices such as testing, refactoring, incremental design, customer involvement, coding standards, and ubiquitous language shared with the customer's business domain really get in the way of coding sometime.
Re:Perl Out, Ruby In - Thank God
on
The Ruby Way
·
· Score: 3, Interesting
A language that came out slightly before Java did is new?
Microsoft doesn't dominate because it is better, it dominates because of great marketing and ease of use (even for groups such as the disabled).
Very true. It's difficult enough for me as a fully-capable technical user to buy a computer with Linux preinstalled. I can't imagine how someone different might possibly avoid the Windows tax.
Wow, I had no idea that there was a genetic disposition toward releasing proprietary software. Now I feel sorry for those people. Perhaps we should start a fund to detect this sad, sad condition in the womb and offer counseling to the parents.
To expect manufacturers to allow you to run modified software on their hardware is ridiculous - they have every right to limit their hardware to working only with their software configurations. If you don't like that, don't buy their hardware.
If I don't like it and I don't buy their hardware, can I somehow prevent them from using code I've written in a way that prevents modification by people who do buy their hardware?
There's more than one way to do it, in Perl, so choose the most maintainable. Problem solved.
Before you counter "But I have to maintain code written by monkeys, and it's hard to read," consider not hiring monkeys to write code you care about. Not even Haskell or Java or Ruby prevents monkeys from writing bad code. The problem is, they're monkeys, not that they're using the wrong language.
Slashdot Mirror
If the person paying you to write software doesn't get to tell you what the software should do, who does?
I went to a fancy restaurant like that once. You pay $150 and get whatever the meal of the day is. Unfortunately, the main course was salmon and I'm allergic to fish, so I left. I heard it was nice, though I've never gone back.
Perhaps Mail::TempAddress might work for you.
RedHat == Red Hat
This too is basic economics: provide someone with some incentive to give you the goods you want, or you won't get them.
This is why the term "intellectual property" is, at best, vague and meaningless. What you said only applies to trademarks. It does not apply to trade secrets, copyrights, or patents.
I'd better take back all of my patches then. I sure hope no one else who's ever written free software that I've used directly or indirectly reads your post!
What do you mean "natively"? Ruby 1.8, at least, doesn't use OS threads. Perl ithreads map to native threads, where they're available.
I've seen that happen too, but that's not Test-Driven Development. Nearly every unit test I write during TDD fails. That's the point. If one passes, it's a surprise and a warning that I overlooked something.
I do agree that it's useful to have someone other than the original developer try to break the code by coming up with edge cases and common error patterns. Pair programming tends to help there, but there's also room for exploratory testing done by an experienced QA person or a cautious and paranoid developer.
In my experience, any developer worthy of the title "developer" already tests his code, though perhaps not in an automated fashion. I've seen plenty of developers (and I've done this myself) use debug statements to build up a function or method in pieces, checking the output manually each time.
Actual test-driven development (not after-the-fact writing a few half-hearted test cases) is a refinement of that process. It has three benefits. First, it captures those manual tests in a permanent format that I can run any time I want. Second, it gives immediate feedback as to the state of the code and allows me to work in much smaller increments of time. Third, it changes the way I approach code and low-level design. My code tends to be simpler and shorter and more cohesive and less coupled (and much, much easier to test) this way.
Having a poor developer create dozens of lousy tests does no one any good. However, my experience with doing TDD myself (and teaching other people how to do it and writing libraries to help them do it) makes me think that any decent developer who tries to do it seriously and with discipline will produce better code.
... such as refactoring? I'm curious what other XP practices these projects didn't practice.
I agree with the problem of bad coders, but I'm not aware of any development process that can generate good results from monkeys by anything other than occasional happy accident.
Precisely why?
Hm, sort of like an XP meeting then. Hm.
Yeah, all those terrible practices such as testing, refactoring, incremental design, customer involvement, coding standards, and ubiquitous language shared with the customer's business domain really get in the way of coding sometime.
A language that came out slightly before Java did is new?
I'm sure it is, for everyone else you're making filter your mail for you. Challenge-response system users are psychopaths.
NVidia and ATI are the failings of the X server for gaming.
Didn't you know? Fun is proportional to price.
Very true. It's difficult enough for me as a fully-capable technical user to buy a computer with Linux preinstalled. I can't imagine how someone different might possibly avoid the Windows tax.
The first paragraph of Wine HQ explicitly says that Wine runs on x86 Unixes. That's hardly ambiguous.
Wow, I had no idea that there was a genetic disposition toward releasing proprietary software. Now I feel sorry for those people. Perhaps we should start a fund to detect this sad, sad condition in the womb and offer counseling to the parents.
If I don't like it and I don't buy their hardware, can I somehow prevent them from using code I've written in a way that prevents modification by people who do buy their hardware?
1913 just called. It wants its historically inevitable utopianism back.
Remember kids, if your process is IO-bound, you want the fastest possible code ever to make sleeping on those system calls as efficient as possible!
There's more than one way to do it, in Perl, so choose the most maintainable. Problem solved.
Before you counter "But I have to maintain code written by monkeys, and it's hard to read," consider not hiring monkeys to write code you care about. Not even Haskell or Java or Ruby prevents monkeys from writing bad code. The problem is, they're monkeys, not that they're using the wrong language.
Consider this an opportunity to learn how to write maintainable code.
Surely a blanket comes from soft wear developers.