Simple solution: grant software patents but only for three years. The original motivation for 17 years was that it gave the innovator time to profit from his investment but also allowed innovations to diffuse quickly. Three years is plenty for software businesses to profit (if you haven't made money on a patent after three years, you aren't going to except by trolling).
The problem is not with patents per se. The original motivation behind patents, rewarding innovation, still holds. The problem is that the world moves much faster now than it did in Jefferson's day. I got a patent as a young pup that just finally expired. I haven't been able to use the technique for most of my career because my ex-employer, who did absolutely nothing with the idea, held the patent. Aside from allowing me to give the one-finger salute to patent trolls who contacted me about it, it did me no good at all to get the patent.
My proposal is to grant software patents for three years. If an idea is going to take off, that's plenty of time to develop a commanding position based on it. If it isn't going to take off, it's no loss to have the patent expire and better for society (the original purpose of patents, after all, was the good of society) for the idea to be available for others.
How about a model that borrows from micro-generation? Just as power from solar or micro-hydro that isn't used in my house goes into the grid and gets paid for by the power company, computing power that I don't use could be sold to the grid. Then I could decide between buying the cores up front or renting them.
"The bottom line is not to mistake a business model for a work model, and to avoid anything that mixes business with design."
XPers couldn't agree more. That's why there are two sides to every team. In one-week chunks, the suits decide what they'd like to see next. For the rest of the week the geeks make it happen or learn why it's impossible. Next Monday everybody has a better idea of what's valuable and what's possible so the suits pick again.
Sure this has interesting technical implications, like you have to figure out how to design every day instead of all at once at the beginning of the project when you're stupid, but that's just a skill and can be learned by anyone with a lick of architectural vision and at least one ball (er, gonad, sorry ladies.)
As far as this robot/anti-guru crap is concerned, there is nothing like an involved pair partner to make the perfect audience for my genius when we finally smack a nasty problem.
Kent Beck has just published a book on test-driven development. The Java example is kinda lame, but the self-referential testing framework written in Python and used to test itself during development is kinda cool. The patterns at the end are what really helped me, though.
If you want one idea out of XP that makes sense today, download an xUnit and try TDD.
Most coders who sit at a keyboard more than 5-6 hours in a day are dogging it. Done right, coding is mentally exhausting.
Take your basic 60-80 hour a week coder. Subtract time for errands, meals out, sickness, times they should have been home sick but were infecting everyone else instead, debugging stupid mistakes they never would have made if they were fresh, fixing stupid integration problems, repairing technical relationships damaged because they are too tired to be civil, and you come up with a much smaller number. Just spend the smaller number, intensely, and go home.
You can't solve business problems by becoming a stupid programmer. Suits have to solve business problems by making (sometimes tough) decisions.
My advice: spend 40 hours a week and sue the bastard for wrongful termination if he fires you.
I don't know how your project is organized, but I get to sign up for what I want to do, every two weeks. Sometimes I get shit jobs, but so does everyone else. If I'm feeling like SOS, I sign up for about what I did last week (a little biz logic and database changes at the moment). If I'm sick of SOS, I try something different. I came in as a GUI guy, and now I'm getting into junior Oracle wizardom.
If you have stupid customers you can either make all their decisions yourself, help them get smarter, or work somewhere else. You have chosen 1). XP chooses 2). 3) seems reasonable, too.
"Refactoring is where you take crap code and kick it hard enough that you can extend its life a bit longer. The idea behind XP is this: the customer gives requirements. Programmers write test cases to verify these requirements. Then, they kick the code, doing the minimal possible work so that it meets these requirements while not failing the others. Then they repeat this. "
What a stupid idea. What if instead you told me honestly how long you thought it would take to get the code into real good shape, and I told you to go ahead and do that as long as we deliver new functionality to the customer in two weeks. How good could you make the software then?
Fred Taylor figured workers were lazy and stupid, so they needed professional planners to tell them what to do and professional quality people to catch them screwing up. 100 years ago with illiterate blue-collar workers this was a bad idea. Today with programmers it's even worse.
If the programmers are the ones who can affect quality, they have to be the ones responsible for quality. Nothing else makes sense.
"At least have someone else help to think up the test cases."
Um, like your pair partner? What a good idea. Perhaps we'll include that in XP 2.0, whoops, it's already there...
"you don't bother to design anything, just plough on ahead and do your code"
There's a world of difference between not designing and not designing *everything* *first*. I spent 25-30% of my time on design, I just spend it 2-2.5 hours/day instead of a big glurp right at the beginning when I'm as ignorant of the system as I ever will be.
"I just find it highly amusing that someone posted that it's better than one big book, when in fact, if you are buying them all, it isn't. "
The books ARE getting out sooner this way. Desmond d'Souza spent maybe five years getting the fat Catalysis book published, and found UML eating his lunch, even if he kicks sand in UML's face.
It can be difficult to prove that a refactoring preserves semantics in the face of threading. This makes you want to isolate the parts of your code that could possibly be sensitive to threading as much as possible, which is A Good Thing.
If you can get over the scarcity mentality for just a second, imagine this--your pair partner is the perfect audience for your genius. When I have a really great idea, I spend far more time explaining why it's a great idea than I do explaining the idea itself. When I'm pairing, I have a person who understands just what a bitch our problem is, who's frustrated at not finding a sweet solution, and who thus appreciates my genius. Of course, if it's really a stupid idea I only look stupid to one person.
You can sign up for any freakin thing you want. You want to migrate databases until your butt freezes to the chair, have at. Don't do it with nobody kibitzing, that would be stupid, but you can soak yourself as deeply in any truly useful technology as you want. OTOH if you want to be a generalist, why should some PHB be able to tell you, "You can't migrate the database, you're a GUI dweeb." That would be stupid.
If you haven't tried it, you don't know what you're talking about. Make a list of all the tests that need to run today. Code the first test that will teach you something. Make it run. Refactor until you can't think of anything else to take out. Continue all day. Did you get more done or less done? Do you feel more or less stressed? Does the code kick or suck?
One day won't kill you. Try it (even if you have to spend a lot of time refactoring). Report to the gang.
Alternatives:
1. Don't buy the books-read most of it on the web.
2. Wait for the omnibus edition in five years and pay one low low price.
3. Make so much money you don't care about a couple of hundred bucks of books.
4. Write your own book.
5. Continue complaining.
Slashdot Mirror
A Facebooker here. The file we send to Politico looks like this:
Candidate, Date, Mentions, % Positive, % Negative
Lincoln, 21 Aug 1858, 4217, 0.35, 0.12
Lincoln, 22 Aug 1858, 5829, 0.42, 0.08
Douglas, 21 Aug 1858, 3119, 0.28, 0.42
Douglas, 22 Aug 1858, 6339, 0.18, 0.55
The numbers are computed by textually analyzing wall posts. The actual mention counts are in the thousands to hundreds of thousands.
Questions?
Simple solution: grant software patents but only for three years. The original motivation for 17 years was that it gave the innovator time to profit from his investment but also allowed innovations to diffuse quickly. Three years is plenty for software businesses to profit (if you haven't made money on a patent after three years, you aren't going to except by trolling).
Start with Yourdon and Constantine, "Structured Design". Nothing significant has been said about software quality since this book appeared.
The problem is not with patents per se. The original motivation behind patents, rewarding innovation, still holds. The problem is that the world moves much faster now than it did in Jefferson's day. I got a patent as a young pup that just finally expired. I haven't been able to use the technique for most of my career because my ex-employer, who did absolutely nothing with the idea, held the patent. Aside from allowing me to give the one-finger salute to patent trolls who contacted me about it, it did me no good at all to get the patent.
My proposal is to grant software patents for three years. If an idea is going to take off, that's plenty of time to develop a commanding position based on it. If it isn't going to take off, it's no loss to have the patent expire and better for society (the original purpose of patents, after all, was the good of society) for the idea to be available for others.
Stremo
How about a model that borrows from micro-generation? Just as power from solar or micro-hydro that isn't used in my house goes into the grid and gets paid for by the power company, computing power that I don't use could be sold to the grid. Then I could decide between buying the cores up front or renting them.
Stremo
"The bottom line is not to mistake a business model for a work model, and to avoid anything that mixes business with design."
XPers couldn't agree more. That's why there are two sides to every team. In one-week chunks, the suits decide what they'd like to see next. For the rest of the week the geeks make it happen or learn why it's impossible. Next Monday everybody has a better idea of what's valuable and what's possible so the suits pick again.
Sure this has interesting technical implications, like you have to figure out how to design every day instead of all at once at the beginning of the project when you're stupid, but that's just a skill and can be learned by anyone with a lick of architectural vision and at least one ball (er, gonad, sorry ladies.)
As far as this robot/anti-guru crap is concerned, there is nothing like an involved pair partner to make the perfect audience for my genius when we finally smack a nasty problem.
Stremo
Die free or die trying
Kent Beck has just published a book on test-driven development. The Java example is kinda lame, but the self-referential testing framework written in Python and used to test itself during development is kinda cool. The patterns at the end are what really helped me, though.
If you want one idea out of XP that makes sense today, download an xUnit and try TDD.
Stremo
Die free or die trying
Most coders who sit at a keyboard more than 5-6 hours in a day are dogging it. Done right, coding is mentally exhausting.
Take your basic 60-80 hour a week coder. Subtract time for errands, meals out, sickness, times they should have been home sick but were infecting everyone else instead, debugging stupid mistakes they never would have made if they were fresh, fixing stupid integration problems, repairing technical relationships damaged because they are too tired to be civil, and you come up with a much smaller number. Just spend the smaller number, intensely, and go home.
You can't solve business problems by becoming a stupid programmer. Suits have to solve business problems by making (sometimes tough) decisions.
My advice: spend 40 hours a week and sue the bastard for wrongful termination if he fires you.
I don't know how your project is organized, but I get to sign up for what I want to do, every two weeks. Sometimes I get shit jobs, but so does everyone else. If I'm feeling like SOS, I sign up for about what I did last week (a little biz logic and database changes at the moment). If I'm sick of SOS, I try something different. I came in as a GUI guy, and now I'm getting into junior Oracle wizardom.
If you have stupid customers you can either make all their decisions yourself, help them get smarter, or work somewhere else. You have chosen 1). XP chooses 2). 3) seems reasonable, too.
"Refactoring is where you take crap code and kick it hard enough that you can extend its life a bit longer. The idea behind XP is this: the customer gives requirements. Programmers write test cases to verify these requirements. Then, they kick the code, doing the minimal possible work so that it meets these requirements while not failing the others. Then they repeat this. " What a stupid idea. What if instead you told me honestly how long you thought it would take to get the code into real good shape, and I told you to go ahead and do that as long as we deliver new functionality to the customer in two weeks. How good could you make the software then?
Shorten it to like zero. Phases are for people who can't refactor.
Fred Taylor figured workers were lazy and stupid, so they needed professional planners to tell them what to do and professional quality people to catch them screwing up. 100 years ago with illiterate blue-collar workers this was a bad idea. Today with programmers it's even worse. If the programmers are the ones who can affect quality, they have to be the ones responsible for quality. Nothing else makes sense.
"At least have someone else help to think up the test cases." Um, like your pair partner? What a good idea. Perhaps we'll include that in XP 2.0, whoops, it's already there...
"you don't bother to design anything, just plough on ahead and do your code" There's a world of difference between not designing and not designing *everything* *first*. I spent 25-30% of my time on design, I just spend it 2-2.5 hours/day instead of a big glurp right at the beginning when I'm as ignorant of the system as I ever will be.
"I just find it highly amusing that someone posted that it's better than one big book, when in fact, if you are buying them all, it isn't. " The books ARE getting out sooner this way. Desmond d'Souza spent maybe five years getting the fat Catalysis book published, and found UML eating his lunch, even if he kicks sand in UML's face.
It can be difficult to prove that a refactoring preserves semantics in the face of threading. This makes you want to isolate the parts of your code that could possibly be sensitive to threading as much as possible, which is A Good Thing.
If you can get over the scarcity mentality for just a second, imagine this--your pair partner is the perfect audience for your genius. When I have a really great idea, I spend far more time explaining why it's a great idea than I do explaining the idea itself. When I'm pairing, I have a person who understands just what a bitch our problem is, who's frustrated at not finding a sweet solution, and who thus appreciates my genius. Of course, if it's really a stupid idea I only look stupid to one person.
You can sign up for any freakin thing you want. You want to migrate databases until your butt freezes to the chair, have at. Don't do it with nobody kibitzing, that would be stupid, but you can soak yourself as deeply in any truly useful technology as you want. OTOH if you want to be a generalist, why should some PHB be able to tell you, "You can't migrate the database, you're a GUI dweeb." That would be stupid.
If you haven't tried it, you don't know what you're talking about. Make a list of all the tests that need to run today. Code the first test that will teach you something. Make it run. Refactor until you can't think of anything else to take out. Continue all day. Did you get more done or less done? Do you feel more or less stressed? Does the code kick or suck? One day won't kill you. Try it (even if you have to spend a lot of time refactoring). Report to the gang.
Alternatives: 1. Don't buy the books-read most of it on the web. 2. Wait for the omnibus edition in five years and pay one low low price. 3. Make so much money you don't care about a couple of hundred bucks of books. 4. Write your own book. 5. Continue complaining.