Nonetheless it is sensible that game creators consider this and plan ahead. People using consoles can't choose screen resolution - it'd be a tad expensive buying a 60" TV just to be able to read the subtitles of the conversation you can't hear..
Similarly, historically a lot of console games have been very restrictive in where/when you can save. I suspect this is largely due to limited resources for saved games, but also programmer laziness (or, more formally, time/budget constraints).
How old people cope with a controller such as the one with the Wii will be far more interesting, and if that becomes a trend in controller design then that may limit the older market.
Fighters? Where I grew up, fighters were the Lightning or the Phantom (F4 to you).
For some reason I didn't really see many fighters. Unless you count the Hawk - saw plenty of those, usually painted red.
Far more prevalent were Jaguars (although nobody seemed quite sure why they were still around) and Tornadoes. Standing around 12 feet behind (and a few feet to the side, of course) a Tornado with its engines on full combat reheat (that's Afterburner to you) was quite an experience. Watching them doing circuits and bumps from 60 yards off the end of the runway at night was beautiful - lilac flame from the engines lighting up the whole area.
Always admired the Harrier (erm. AV8B?) for its abilities but it was always too snubby to really get the emotion going. Still, damn good kill record in '82.
I kind of regret not living on military airfields. Civilian aircraft just aren't as pretty:(
Only really saw other (smaller) aircraft at airshows. Although had a chance to scramble over a pair of F15s one time, the pilots were very friendly and happy to show them off. Damn they had big engines (relative to the size of plane). And the F16 is still beautiful in flight.
Back on topic, I don't recall seeing the F14 ever. May well have, but more likely it just never showed up where I was. And as corny as Top Gun was, at least it wasn't Iron Eagle.
I'm responsible for systems that talk to other systems. The users _are_ other systems. Some of them are over 30 years old.
Of course, some of the systems do have users. Internal and over the web.
I'd far rather test my own code than rely exclusively on error messages from a 30yo system to tell me what's not working as expected.
Since I can test my own code, and still use the feedback from other systems, and users, and system testers, I see no real downside. My users don't either; they get far higher quality code from the outset.
>> Personal experience and everything I've read show the exact opposite- its more than twice as slow and has lower quality.
That's very interesting. I'd be interested to see what you've read about it - I've read a couple of case studies, a few academic studies and heard a lot of anecdotal evidence, and you've just contradicted a significant proportion of it.
>> If the methodology requires absolute rigid adherence for it to work, thats a fatal flaw in it right there.
My experience is that XP is very very difficult and also needs a hell of a lot of discipline. That alone makes following it pragmatically impossible for most development teams. That doesn't invalidate the methodology, it just makes a decision to adopt it require far more commitment and certainty than most people are prepared to give.
XP is not a silver bullet. (Fred Brooks seems to be onto a winner there.) I just get irritated as hell at people denouncing it without having actually tried it properly. All too often it rings of "I don't work like that, it must be wrong"
I'm not sure this 'fad' will pass. I doubt XP will ever be mainstream, but I suspect it'll never go completely away.
It has certainly influenced a lot of Agile methods, and influenced a lot of people beyond that. XP as a methodology may not be deemed a 'success' within the industry, but I think a lot of people recognise the contribution it's made.
FFS, Intelliware may be the top XP solution provider in Ontario, but you've said yourself: Feature Creep
In a proper XP project that is impossible. You only implement features for which there are stories. The customer chooses which stories to implement. Feature creep ceases to be an option.
Give me a bloody break, and don't badmouth XP until you've done it properly. I'm quite happy for you to criticise XP - shit, I can give you a couple of pages of solid criticism myself - but at least base it on reality, not your experience of some fucked up cowboy method that someone told you was XP.
I haven't bought into the entire XP religious propaganda. If I had I'd be insisting we use it where I work now. I don't, because I evaluate multiple development methods and I recommend the appropriate one for the work being done, in the environment in which it is happening. I just get pissed off with the dogmatic refusal from a significant percentage of the IT industry to actually objectively evaluate new and different ways of working. Stop holding my industry back you luddite wankers.
Absolutely. None of this is new. Nobody is pretending that this is new.
What is new is trying to get people to do it methodically, all the time, without exception, without excuses.
Although TDD doesn't explicitly force modular design, it very strongly encourages it. Writing tests is much much easier for well designed code, and so the lazy programmer designs well to ease their testing.
My experience is that the top guys in the industry - I'm talking about Beck, Fowler, the three amigos (didn't one of them die?), the Gang of Four, Anders Hejlsberg, Cockburn - are all still very hands on. They do publish a lot, they do put a lot of thought into software engineering, but they do also still get very actively involved in software projects.
No, they're not 100% programming. I must confess, I'd rather Cockburn spent 20% of his time programming and the rest of it writing books and giving subjects on the subject. He's an arch-methodologist, and he puts his ideas into practice, but he makes people think, and he helps them improve how they do what they do.
Hmm. For the definitive description, I can only suggest you acquire (beg, borrow, buy, etc) a copy of Test Driven Development by (eek) Kent Beck.
My brief summary: You write a test. To write the test you must know what it is you are testing. This means you have to think about interface, so you can access the functionality, and function, so you know what it's meant to do.
Thus before you've written any code you're already putting a lot of thought into what's going on with your code. Far more thought than most programmers put in (trust me, I've worked with too many;)
To be able to write a test with small enough scope (so you don't end up testing half the system - you may want to do that, but not right now) you need to be able to isolate the piece of code you're testing. There are multiple mechanisms to achieve this (see the paper "Endo-Testing: Unit Testing with Mock Objects" for an example) but the outcome is this: The code you write, to pass your test, can be isolated from the rest of the codebase. It is inherently decoupled (at least to a degree).
Now extrapolate this across the entire codebase. It's all decoupled. It has to be, so that you can test it all in isolation.
That makes the code easier to re-use too. If a block of code isn't tightly coupled to the things that use it, or to the things it uses, it's easier to re-use with other things.
Which leads to the other aspect of TDD: Eliminate duplication. If you're doing TDD by the book, you ruthlessly excise any duplication in your code. Where you see two blocks of code doing the same thing you refactor them into one block of code.
This is relatively risk-free, because all the code you're changing has a full suite of automated unit tests. Which you're running every few minutes (because they take a couple of seconds to run). So you're getting pretty prompt feedback on any errors you accidentally introduce while changing the code.
Of course, you have a lot of test cases now. These are a form of documentation. They provide examples of how to use your code, and also pretty definitive indications of how it's expected to work.
So the process of writing tests forces you to write testable code. I believe testable code shares many characteristics with well designed code.
You may also want to pick up Michael Feather's book on "Working Effectively with Legacy Code". Many of his techniques revolve around building test cases, and refactoring the code to make it more testable. That's not coincidence (and remember - refactoring means "improving the design of existing code").
As I said, I'm an amateur at explaining this compared to Beck, so find a copy of his book and read through it - it's actually not a long read, the basics really are simple.
I'm not entirely sure what production code he's been working on commercially. I do know that in his spare time he's worked with Erich Gamma (hopefully a name you recognise) writing and maintaining JUnit (http://junit.org/index.htm)
If you're not a Java programmer you wont know that that's probably the second most downloaded and used piece of Java on the planet (behind the Sun SDK).
>> Basically the project was not delivered on time (and as I at the time predicted) went over the original time estimates by about a year
That doesn't sound like an XP project to me at all. How do you go over by a year if you deliver every 2-6 weeks?
>> Sweat shop mentality dominates XP
That's ludicrous. One key tenet of XP is "sustainable pace". Don't burn out, don't work late nights.
>> it takes 2x as many people to deliver the same solution for 2x the money.
You are aware of the body of evidence (academic and business) that shows that while pair programming is less efficient than solo programming (in a lines of code delivered sense) it is nowhere near twice as slow and the code delivered is so considerably higher quality that it more than makes up for the overhead?
I call bullshit on your statement you were using XP. You may have used many of the practices, and you may have called it XP, but you didn't do it.
Don't feel bad - it's a bloody difficult thing to do properly. Possibly too difficult. By far the highest discipline method I've ever used. But don't badmouth it just because the company employing you didn't do it properly.
Managers find it harder to come to terms with XP than programmers.
The people that came up with XP are all (and I hope none of them read this;) old people. They have decades of experience.
They've also published many papers on software engineering and heavily advanced the state of that discipline. They are older, more experienced programmers. Why can't you see XP being any good for them?
Most XP projects start using XP because the programmers wanted to. It makes sense for them.
If you're a professional then why are you bleating about getting shit requirements and being unable to start? Why aren't you doing something about it?
Hint: Some people did do something about it. They even wrote it all down for you. They gave it an odd name, "Extreme Programming". Maybe you'd like to read about it, possibly even give it a go, actually expand your horizons and learn something. Or you could just post to Slashdot about it being buzzword laden crap without understanding the concepts in the slightest. Your choice.
My understanding of XP is that it does not preclude, prevent or deride functional testing, UAT, performance testing or any other traditional test techniques.
Going live every two weeks also means that you don't have to wait long for any bug fixes.
My experience of XP is that the TDD and Pair Programming between them do reduce the bug count to negligible proportions. It took so long to find a bug that it was quicker to release the software and successfully use it for a few months; fixing the bug took days from "found" to "new release deployed". And that was for a multithreaded system using TCP/IP, database access and unix named pipes.
If you did want to slow down the releases to production though, your XP release could be a release to your test teams. Ideally you have someone writing automatic functional tests in conjunction with the development, so most testing is pressing a single button, but the developers can keep adding value just as fast as the testers can validate it.
I don't have experience with real-time systems, but I've been involved in the full project lifecycle for IT developments across multiple systems, in very heterogeneous environments, with frankly daft timescales (thanks Marketing team) and delivered them on time with very low bug counts. The only thing stopping XP working in such environments are organisational issues, team structures, seating plans, availability of the business and commitment from IT.
My current company doesn't use XP. It couldn't, the organisational barriers are too great. That doesn't invalidate XP, it merely highlights issues with my current company. But we're making progress on those.
The tests being discussed are not end-user testing. They are code level unit testing.
It doesn't really matter what colour the UI is if the code underneath it doesn't work. And I can demonstrate in under a second that it works because I have 96% code coverage in my unit tests, which include testing edge cases, error conditions, multiple paths and even that the code does what it's meant to do.
More importantly, TDD (test driven development) is not (just) about testing. The tests are a very important facet, and add tremendous value, but I'd follow TDD even if I threw away the tests afterwards (not that I would, who would turn down a fully automated regression test suite?). That's because TDD gives me better code.
Better design, better decoupling, better coherence, fewer bugs, reduced duplication. All for free.
Of course, once I've written my tests, and my code that passes them, I also then let the users test them. As you say, programmer testing is no replacement for functional tests, UAT, performance testing, etc. It will make all of those go considerably quicker and easier and smoother, but that's just my personal observation.
Sorry, tell me again, why don't you want your code to work?
Beck is not a manager. That doesn't mean he lacks management skills (I've seen evidence that he does have excellent management skills) but reflects his hands-on nature. He writes code, and thinks about the process of writing code. And his thoughts tend to be somewhat broader than most peoples, and more complete, and when he shares them with others, better expressed.
In other words, find books and papers and software written by Kent Beck and read the lot. If every programmer on the planet did that, even if they disagreed with everything he'd said, the IT industry would become immensely more efficient and effective overnight.
Now consider Beck's quote that you have taken affront from. Think about new programmers, software heroes, cowboys, even experienced and capable programmers - they all want more toys, to be left alone to get on with their job (which they perceive as programming), that everything is handed to them on a plate. Your comment even reflects that - "enough time", "features are correctly documented", "spec".
Real life isn't like that. And instead of whining about it, Beck stepped back and re-evaluated how to approach software so that he could deal with those issues, and still write top quality code, and still meet deadlines and give the customer value.
No, Beck isn't a manager. He's quite beyond such limiting labels.
I'm struggling to determine whether your entire post is sarcastic, ironic or sardonic. So I'll skip the rest of it and merely note that you've accidentally said something correct.
The better I get at software engineering the more apparent it becomes that software creation is a social process.
(Note that I'm speaking about software development in a business environment. That is, after all, the context in which XP is predominantly used. If you're writing code to solve a specific personal problem then personally I'd recommend you go and visit the chemist instead)
On a price-per-mile-driven you can compare petrol to diesel. On a gallon to gallon basis you can compare fuel economy.
As for "More people, more cars, more miles of road, more spread-out populace, etc." perhaps you'd care to examine the statistics. More people die per mile driven in the US. That's nothing to do with the miles of road, the number of cars, the number of people (although the deaths per car owned puts the US way down the list too). It may be linked to the spread-out populace, the figures aren't indicative either way.
You CAN compare GASOLINE with DIESEL. They BOTH power AUTOMOBILES. If you're running a power station you definitely do compare coal and natural gas.
If people in the US refuse to buy tiny, underpowered and/or incredibly unsafe vehicles then why are most heavy duty 4x4s and commercial trucks in the UK diesel powered? They're the vehicles that need power and they sure aren't small. And how come more Americans die on the road than in many other countries? (http://www.scienceservingsociety.com/m/data/USran k.htm) Seems to me your arguments are specious.
Oh, come on. I'm driving a 4 gear automatic at very inefficient speeds and still getting well over 30 to the gallon.
21 as an average is terrible. New diesels in the UK are pulling 45-60mpg, including the automatics. Those are decent sized cars, the small town cars are doing even better.
Even the Chelsea tractors are getting 15-40.
P.S. I've never heard of Slashdot being a US-centric website. The significant number of non-US users and the extensive European response to even this article should be a small clue. You'd probably do well to look up UK slang and silently thank the poster that used it for expanding your horizons rather than bitching about its use in the first place.
I live in England and I'm doing around 28k miles a year. Don't even fucking pretend our diesel is cheap, I'm spending $700/month getting to work.
I _could_ move nearer, but I'd lose $15k immediately on the cost of selling/buying/moving house, end up with a smaller house in a worse area and have to move again next year when I switch job.
I _could_ drive slower and get better fuel economy. I'd rather pay extra and get more of my life out of my car. I _could_ buy a smaller, more economical car, but I don't want to drive a small car at the speeds I drive and I do want those 28k miles to be comfortable.
I _could_ take public transport to work. It would only be a 22 mile round trip, and a mere $40/day. Still, nice that I'm subsidising everybody else's public transport.
Slashdot Mirror
Good approach, makes a lot of sense.
Nonetheless it is sensible that game creators consider this and plan ahead. People using consoles can't choose screen resolution - it'd be a tad expensive buying a 60" TV just to be able to read the subtitles of the conversation you can't hear..
Similarly, historically a lot of console games have been very restrictive in where/when you can save. I suspect this is largely due to limited resources for saved games, but also programmer laziness (or, more formally, time/budget constraints).
How old people cope with a controller such as the one with the Wii will be far more interesting, and if that becomes a trend in controller design then that may limit the older market.
Damn, I'd forgotten the Vulcan. I haven't seen one of those since they were in active service.
hmm. that makes me old
Fighters? Where I grew up, fighters were the Lightning or the Phantom (F4 to you).
For some reason I didn't really see many fighters. Unless you count the Hawk - saw plenty of those, usually painted red.
Far more prevalent were Jaguars (although nobody seemed quite sure why they were still around) and Tornadoes. Standing around 12 feet behind (and a few feet to the side, of course) a Tornado with its engines on full combat reheat (that's Afterburner to you) was quite an experience. Watching them doing circuits and bumps from 60 yards off the end of the runway at night was beautiful - lilac flame from the engines lighting up the whole area.
Always admired the Harrier (erm. AV8B?) for its abilities but it was always too snubby to really get the emotion going. Still, damn good kill record in '82.
I kind of regret not living on military airfields. Civilian aircraft just aren't as pretty
Only really saw other (smaller) aircraft at airshows. Although had a chance to scramble over a pair of F15s one time, the pilots were very friendly and happy to show them off. Damn they had big engines (relative to the size of plane). And the F16 is still beautiful in flight.
Back on topic, I don't recall seeing the F14 ever. May well have, but more likely it just never showed up where I was. And as corny as Top Gun was, at least it wasn't Iron Eagle.
>> Also, I'm not fat, which makes all my exercise and healthy eating REALLY pointless.
Bah. I am fat. Imagine how I feel about all my exercise and healthy eating!
I'm responsible for systems that talk to other systems. The users _are_ other systems. Some of them are over 30 years old.
Of course, some of the systems do have users. Internal and over the web.
I'd far rather test my own code than rely exclusively on error messages from a 30yo system to tell me what's not working as expected.
Since I can test my own code, and still use the feedback from other systems, and users, and system testers, I see no real downside. My users don't either; they get far higher quality code from the outset.
>> Personal experience and everything I've read show the exact opposite- its more than twice as slow and has lower quality.
That's very interesting. I'd be interested to see what you've read about it - I've read a couple of case studies, a few academic studies and heard a lot of anecdotal evidence, and you've just contradicted a significant proportion of it.
I did just find http://agilealliancebeta.org/system/article/file/
>> If the methodology requires absolute rigid adherence for it to work, thats a fatal flaw in it right there.
My experience is that XP is very very difficult and also needs a hell of a lot of discipline. That alone makes following it pragmatically impossible for most development teams. That doesn't invalidate the methodology, it just makes a decision to adopt it require far more commitment and certainty than most people are prepared to give.
XP is not a silver bullet. (Fred Brooks seems to be onto a winner there.) I just get irritated as hell at people denouncing it without having actually tried it properly. All too often it rings of "I don't work like that, it must be wrong"
I'm not sure this 'fad' will pass. I doubt XP will ever be mainstream, but I suspect it'll never go completely away.
It has certainly influenced a lot of Agile methods, and influenced a lot of people beyond that. XP as a methodology may not be deemed a 'success' within the industry, but I think a lot of people recognise the contribution it's made.
FFS, Intelliware may be the top XP solution provider in Ontario, but you've said yourself: Feature Creep
In a proper XP project that is impossible. You only implement features for which there are stories. The customer chooses which stories to implement. Feature creep ceases to be an option.
Give me a bloody break, and don't badmouth XP until you've done it properly. I'm quite happy for you to criticise XP - shit, I can give you a couple of pages of solid criticism myself - but at least base it on reality, not your experience of some fucked up cowboy method that someone told you was XP.
I haven't bought into the entire XP religious propaganda. If I had I'd be insisting we use it where I work now. I don't, because I evaluate multiple development methods and I recommend the appropriate one for the work being done, in the environment in which it is happening. I just get pissed off with the dogmatic refusal from a significant percentage of the IT industry to actually objectively evaluate new and different ways of working. Stop holding my industry back you luddite wankers.
Absolutely. None of this is new. Nobody is pretending that this is new.
What is new is trying to get people to do it methodically, all the time, without exception, without excuses.
Although TDD doesn't explicitly force modular design, it very strongly encourages it. Writing tests is much much easier for well designed code, and so the lazy programmer designs well to ease their testing.
All good programmers are lazy.
My experience is that the top guys in the industry - I'm talking about Beck, Fowler, the three amigos (didn't one of them die?), the Gang of Four, Anders Hejlsberg, Cockburn - are all still very hands on. They do publish a lot, they do put a lot of thought into software engineering, but they do also still get very actively involved in software projects.
No, they're not 100% programming. I must confess, I'd rather Cockburn spent 20% of his time programming and the rest of it writing books and giving subjects on the subject. He's an arch-methodologist, and he puts his ideas into practice, but he makes people think, and he helps them improve how they do what they do.
I kind of buy into that.
Hmm. For the definitive description, I can only suggest you acquire (beg, borrow, buy, etc) a copy of Test Driven Development by (eek) Kent Beck.
My brief summary:
You write a test. To write the test you must know what it is you are testing. This means you have to think about interface, so you can access the functionality, and function, so you know what it's meant to do.
Thus before you've written any code you're already putting a lot of thought into what's going on with your code. Far more thought than most programmers put in (trust me, I've worked with too many
To be able to write a test with small enough scope (so you don't end up testing half the system - you may want to do that, but not right now) you need to be able to isolate the piece of code you're testing. There are multiple mechanisms to achieve this (see the paper "Endo-Testing: Unit Testing with Mock Objects" for an example) but the outcome is this: The code you write, to pass your test, can be isolated from the rest of the codebase. It is inherently decoupled (at least to a degree).
Now extrapolate this across the entire codebase. It's all decoupled. It has to be, so that you can test it all in isolation.
That makes the code easier to re-use too. If a block of code isn't tightly coupled to the things that use it, or to the things it uses, it's easier to re-use with other things.
Which leads to the other aspect of TDD: Eliminate duplication. If you're doing TDD by the book, you ruthlessly excise any duplication in your code. Where you see two blocks of code doing the same thing you refactor them into one block of code.
This is relatively risk-free, because all the code you're changing has a full suite of automated unit tests. Which you're running every few minutes (because they take a couple of seconds to run). So you're getting pretty prompt feedback on any errors you accidentally introduce while changing the code.
Of course, you have a lot of test cases now. These are a form of documentation. They provide examples of how to use your code, and also pretty definitive indications of how it's expected to work.
So the process of writing tests forces you to write testable code. I believe testable code shares many characteristics with well designed code.
You may also want to pick up Michael Feather's book on "Working Effectively with Legacy Code". Many of his techniques revolve around building test cases, and refactoring the code to make it more testable. That's not coincidence (and remember - refactoring means "improving the design of existing code").
As I said, I'm an amateur at explaining this compared to Beck, so find a copy of his book and read through it - it's actually not a long read, the basics really are simple.
I'm not entirely sure what production code he's been working on commercially. I do know that in his spare time he's worked with Erich Gamma (hopefully a name you recognise) writing and maintaining JUnit (http://junit.org/index.htm)
If you're not a Java programmer you wont know that that's probably the second most downloaded and used piece of Java on the planet (behind the Sun SDK).
>> Basically the project was not delivered on time (and as I at the time predicted) went over the original time estimates by about a year
That doesn't sound like an XP project to me at all. How do you go over by a year if you deliver every 2-6 weeks?
>> Sweat shop mentality dominates XP
That's ludicrous. One key tenet of XP is "sustainable pace". Don't burn out, don't work late nights.
>> it takes 2x as many people to deliver the same solution for 2x the money.
You are aware of the body of evidence (academic and business) that shows that while pair programming is less efficient than solo programming (in a lines of code delivered sense) it is nowhere near twice as slow and the code delivered is so considerably higher quality that it more than makes up for the overhead?
I call bullshit on your statement you were using XP. You may have used many of the practices, and you may have called it XP, but you didn't do it.
Don't feel bad - it's a bloody difficult thing to do properly. Possibly too difficult. By far the highest discipline method I've ever used. But don't badmouth it just because the company employing you didn't do it properly.
Managers find it harder to come to terms with XP than programmers.
The people that came up with XP are all (and I hope none of them read this
They've also published many papers on software engineering and heavily advanced the state of that discipline. They are older, more experienced programmers. Why can't you see XP being any good for them?
Beck and Andres are also programmers.
Most XP projects start using XP because the programmers wanted to. It makes sense for them.
If you're a professional then why are you bleating about getting shit requirements and being unable to start? Why aren't you doing something about it?
Hint: Some people did do something about it. They even wrote it all down for you. They gave it an odd name, "Extreme Programming". Maybe you'd like to read about it, possibly even give it a go, actually expand your horizons and learn something. Or you could just post to Slashdot about it being buzzword laden crap without understanding the concepts in the slightest. Your choice.
My understanding of XP is that it does not preclude, prevent or deride functional testing, UAT, performance testing or any other traditional test techniques.
Going live every two weeks also means that you don't have to wait long for any bug fixes.
My experience of XP is that the TDD and Pair Programming between them do reduce the bug count to negligible proportions. It took so long to find a bug that it was quicker to release the software and successfully use it for a few months; fixing the bug took days from "found" to "new release deployed". And that was for a multithreaded system using TCP/IP, database access and unix named pipes.
If you did want to slow down the releases to production though, your XP release could be a release to your test teams. Ideally you have someone writing automatic functional tests in conjunction with the development, so most testing is pressing a single button, but the developers can keep adding value just as fast as the testers can validate it.
I don't have experience with real-time systems, but I've been involved in the full project lifecycle for IT developments across multiple systems, in very heterogeneous environments, with frankly daft timescales (thanks Marketing team) and delivered them on time with very low bug counts. The only thing stopping XP working in such environments are organisational issues, team structures, seating plans, availability of the business and commitment from IT.
My current company doesn't use XP. It couldn't, the organisational barriers are too great. That doesn't invalidate XP, it merely highlights issues with my current company. But we're making progress on those.
The tests being discussed are not end-user testing. They are code level unit testing.
It doesn't really matter what colour the UI is if the code underneath it doesn't work. And I can demonstrate in under a second that it works because I have 96% code coverage in my unit tests, which include testing edge cases, error conditions, multiple paths and even that the code does what it's meant to do.
More importantly, TDD (test driven development) is not (just) about testing. The tests are a very important facet, and add tremendous value, but I'd follow TDD even if I threw away the tests afterwards (not that I would, who would turn down a fully automated regression test suite?). That's because TDD gives me better code.
Better design, better decoupling, better coherence, fewer bugs, reduced duplication. All for free.
Of course, once I've written my tests, and my code that passes them, I also then let the users test them. As you say, programmer testing is no replacement for functional tests, UAT, performance testing, etc. It will make all of those go considerably quicker and easier and smoother, but that's just my personal observation.
Sorry, tell me again, why don't you want your code to work?
Beck is not a manager. That doesn't mean he lacks management skills (I've seen evidence that he does have excellent management skills) but reflects his hands-on nature. He writes code, and thinks about the process of writing code. And his thoughts tend to be somewhat broader than most peoples, and more complete, and when he shares them with others, better expressed.
In other words, find books and papers and software written by Kent Beck and read the lot. If every programmer on the planet did that, even if they disagreed with everything he'd said, the IT industry would become immensely more efficient and effective overnight.
Now consider Beck's quote that you have taken affront from. Think about new programmers, software heroes, cowboys, even experienced and capable programmers - they all want more toys, to be left alone to get on with their job (which they perceive as programming), that everything is handed to them on a plate. Your comment even reflects that - "enough time", "features are correctly documented", "spec".
Real life isn't like that. And instead of whining about it, Beck stepped back and re-evaluated how to approach software so that he could deal with those issues, and still write top quality code, and still meet deadlines and give the customer value.
No, Beck isn't a manager. He's quite beyond such limiting labels.
You haven't done much software development in large enterprises have you.
>> you release "deliverables" instead of "stories"
or follow XP properly, and release "working software". Which adds "business value". Is this so hard a concept?
>> The result is that, in theory, any programmer can sit down and work on any part of the system.
That is so naive. In theory, what works in theory will work in practice. In practice...
>> Programming should be a social event!
I'm struggling to determine whether your entire post is sarcastic, ironic or sardonic. So I'll skip the rest of it and merely note that you've accidentally said something correct.
The better I get at software engineering the more apparent it becomes that software creation is a social process.
(Note that I'm speaking about software development in a business environment. That is, after all, the context in which XP is predominantly used. If you're writing code to solve a specific personal problem then personally I'd recommend you go and visit the chemist instead)
On a price-per-mile-driven you can compare petrol to diesel. On a gallon to gallon basis you can compare fuel economy.
As for "More people, more cars, more miles of road, more spread-out populace, etc." perhaps you'd care to examine the statistics. More people die per mile driven in the US. That's nothing to do with the miles of road, the number of cars, the number of people (although the deaths per car owned puts the US way down the list too). It may be linked to the spread-out populace, the figures aren't indicative either way.
You CAN compare GASOLINE with DIESEL. They BOTH power AUTOMOBILES. If you're running a power station you definitely do compare coal and natural gas.
If people in the US refuse to buy tiny, underpowered and/or incredibly unsafe vehicles then why are most heavy duty 4x4s and commercial trucks in the UK diesel powered? They're the vehicles that need power and they sure aren't small. And how come more Americans die on the road than in many other countries? (http://www.scienceservingsociety.com/m/data/USra
You appear to be defending 25.2mpg. And Americans wonder why the world hates them..
Oh, come on. I'm driving a 4 gear automatic at very inefficient speeds and still getting well over 30 to the gallon.
21 as an average is terrible. New diesels in the UK are pulling 45-60mpg, including the automatics. Those are decent sized cars, the small town cars are doing even better.
Even the Chelsea tractors are getting 15-40.
P.S. I've never heard of Slashdot being a US-centric website. The significant number of non-US users and the extensive European response to even this article should be a small clue. You'd probably do well to look up UK slang and silently thank the poster that used it for expanding your horizons rather than bitching about its use in the first place.
I live in England and I'm doing around 28k miles a year. Don't even fucking pretend our diesel is cheap, I'm spending $700/month getting to work.
I _could_ move nearer, but I'd lose $15k immediately on the cost of selling/buying/moving house, end up with a smaller house in a worse area and have to move again next year when I switch job.
I _could_ drive slower and get better fuel economy. I'd rather pay extra and get more of my life out of my car. I _could_ buy a smaller, more economical car, but I don't want to drive a small car at the speeds I drive and I do want those 28k miles to be comfortable.
I _could_ take public transport to work. It would only be a 22 mile round trip, and a mere $40/day. Still, nice that I'm subsidising everybody else's public transport.