I find it odd that nowhere in the article or in the slashdot discussion is there a single mention of Extreme Programming or Test Driven Development.
Writing automated tests, then adding the code to pass the tests, and running the tests frequently has a number of benefits:
1) achieving high test coverage 2) getting lots of practice writing tests 3) getting lots of practice writing testable code. 4) catching introduced bugs 5) simpler designs (easier to maintain, easier to debug)
Under TDD, a full suite of tests is often run many times daily. Mistakes are caught immediately.
Good catch Dan. I'd be embarrassed, except it was actually my wife who wrote that post. Guess what... she's a teacher. Having said that, I have to point out that there is a quantitative difference between one simple mistake and the consistent indifference to (ignorance of) the English language demostrated by the post to which she was responding.
Hmmm... Maybe I've been lucky, 20 years in the business, never been laid off, never even been worried about it, never been out of work longer than I wanted to be...
A teacher?... I think not. Though you have a valid point about software and computer companies hooking our youth, your presentation of information is well below grade avarage. As a respresentitive of the teaching profession you should at least use proper semantics and syntax.
The point is that a programmer really only needs to learn how to write good tests in order to be a good programmer. TDD gives you all the stuff that you would normally have to have gained through experience.
I have to disagree. It's unlikely that a programmer who can write good test won't write good code. TDD isn't about traditional testing. Its about expressing design through testing. In that environment, if you are writing good tests it means that you have correctly and completely expressed the design in a way that can be automatically validated. Also, implementation of the tests depends on virtually all the skills required to write good code. If you can write good tests for TDD, then you can also write good code.
All of the skills for writing good tests and writing good code are gained through experience. TDD is not a substitute for experience, it is a method for exploiting experience.
One other point -- for those inclined towards genetic programming. I think that the XP TDD way of programming suffers from the same problems as the hill climbing algorithm. It tends to produce quality, but I think it's easy to get stuck at a local minimum.
Every development methodology has a tendency to get stuck at a local optimum.
There are techniques in evolutionary computation to get out of a local optimum (adaptive mutation rates, forking, migration, restarts,...).
XP provides a low risk way to do the same. Sweeping design changes that would ordinarily force a project manager to mainline prozac can be handled with very little risk. I've seen it done... I've done it myself.
Like any tool, incorrect use of templates is dangerous. I have a chain saw at home that I won't let my 12 year-old use for that very reason.
Debugging poorly designed and poorly tested templated code is difficult to deal with. Design it properly, test it thoroughly, and its much easier.
Explicit instantiation can sometimes be used to reduce compile times and establish control over which template instantiations are actually available.
Templates are not the silver bullet for every problem. They can be overused, abused. However, when you need them, they can be amazingly helpful, just like the chain saw.
You can put the implementation of a templated class into the cpp file IF it is explicitly instantiated.
Add the following to the bottom of Foo.cpp:
template class Foo(int>;
There is a limitation... you cannot instantiate Foo without adding an explicit instantiation for it. For internally used template classes, this is sometimes quite useful.
You can put the implementation of a templated class into the cpp file IF it is explicitly instantiated.
Add the following to the bottom of Foo.cpp:
template class Foo;
Change references to Foo in
There is a limitation... you cannot instantiate Foo without adding an explicit instantiation for it. For internally used template classes, this is sometimes quite useful.
In this context DFA refers to "Deterministic Finite Automata". Among other things, they can be employed in highly efficient lexical analyzers. If you've got a decent book on compilers around, you can look up the details.
If you actually read the book its clear that the swarm of nanobots actually makes a camera using a synthetic aperture. The effective aperture of the camera is the size of the swarm, not the size of the nanobot. That part, at least, was credible...
The reason I assumed that 'King of the World' hadn't tried pair-programming is that he didn't say he had. What he said was that he "didn't belive" in it. Belief is a funny thing. Most of us has firmly held beliefs that are based on virtually no objective data (like the attitude I used to have toward XP).
I'm not going to tell you that XP in general (and pair programming in particular) will work for everyone. I can say from experience, that it has worked for me... after an overwhelmingly negative initial reaction.
Did 'King of the World' give pair programming an serious attempt. I have no idea. I wouldn't call sitting bored with another programmer for a half a day and then saying that you don't like it a serious try...
BTW: I wouldn't introduce pair programming as the first 'XP' practice. I'd introduce Test Driven Design first. It works better in isolation and it has a faster payoff.
We may need these in Oregon ...
on
GPS Jamming for $50
·
· Score: 2, Interesting
If the idiots in Salem mandate a GPS in every car so they can charge a mileage tax.
I open up my old drives, remove the magnets, and bore holes in the remains with a 30-06. The magnets are powerful, I truly enjoy boring holes that way, and my data is secure. It's a win, win, win situation.
Have you ever tried it seriously? If not, you are falling into the trap of speaking in ignorance.
A few years ago, I would have said much the same thing. After giving pair programming a honest try, I write virtually all of my production code with a pair.
As a result of pair programming and Test Driven Design (TDD), we have been able to write a new embedded, real-time application for one of our systems in just a few months. IIRC: The number of bugs found in this application is 5, and 2 of those were compiler/tool related.
This is just the most recent application we've developed.
at least under linux, VNC is quick enough to make it better than shoving the keyboard back and forth. You have to work out the signals within the pair so you don't 'stomp' on each other.
Under windoze... VNC is less useful.
As for getting the furniture you need... if you're lab isn't set up to do pair programming, then you cannot effectively do pair programming. Then again, I've done useful pair programming under windoze using VNC over a T1 with a headset phone... It's better than nothing.
If you don't know (m)any people that owns guns doesn't mean a thing. I know lots. It has a lot to do with your location, and your personality.
I dug these two articles out of a single medium sized city's website in under two minutes.
When you go looking for a specific pattern it's not surprising that you find exactly what you are looking for.
And frankly, I'm completely surprised by the amount of pro-gun posts I'm seeing, and the amount of venom injected into defending guns.
Possibly you could simply accept that your views are not necessarily the mainstream.
That gun owners are a vocal lot could possibly be explained by the natural tendency to defend yourself when someone else decides to mess around in you chili.
I don't know what to do about all you deer hunters.
Don't wear drab, brown clothing in the woods during hunting season....
I spent 12 (horrible) years working on DoD software as a contractor. The likelihood of finding a "group of knowledgable professionals within the DoD" is vanishingly small. Virtually every technical employee of the DoD that actually has two brain cells to rub together leaves as soon as they can for a much better job.
The ones that stay,... what can I say?
Decisions like this are typically made based on reports generated by consultants, often without a great deal of technical savvy. I have often suspected that the reports are evaluated in the same manner that many of my professors graded papers. Throw the stack of reports down the stairs, the one that reaches the bottom wins.
BTW: I haven't done DoD software for several years now. What a relief!
I've got to agree with you... I've yet to attend any kind of company sponsored training in which the suit that's supposed to train us had a clue about what was really going on.
Once, most of our team walked out of a class during the first session because it was so lame.
Another time, a class on real-time programming featured an instructor that didn't know what Rate Monotonic Analysis was, much less how to apply it.
I see two problems:
1) Management is easily seduced by the marketing of 'training' firms that have much more experience/talent in marketing than in the subject of interest.
2) Firms that actually have the desired knowledge make a great deal more money by directly exploiting the knowledge than teaching others how. Thus, the people we could really use as instructors aren't available.
Slashdot Mirror
I find it odd that nowhere in the article or in the slashdot discussion is there a single mention of Extreme Programming or Test Driven Development.
Writing automated tests, then adding the code to pass the tests, and running the tests frequently has a number of benefits:
1) achieving high test coverage
2) getting lots of practice writing tests
3) getting lots of practice writing testable code.
4) catching introduced bugs
5) simpler designs (easier to maintain, easier to debug)
Under TDD, a full suite of tests is often run many times daily. Mistakes are caught immediately.
Good catch Dan. I'd be embarrassed, except it was actually my wife who wrote that post. Guess what... she's a teacher. Having said that, I have to point out that there is a quantitative difference between one simple mistake and the consistent indifference to (ignorance of) the English language demostrated by the post to which she was responding.
Hmmm... Maybe I've been lucky, 20 years in the business, never been laid off, never even been worried about it, never been out of work longer than I wanted to be...
You would want to be hired by Microsoft? Eeeewww!!!
A teacher?... I think not. Though you have a valid point about software and computer companies hooking our youth, your presentation of information is well below grade avarage. As a respresentitive of the teaching profession you should at least use proper semantics and syntax.
I have to disagree. It's unlikely that a programmer who can write good test won't write good code. TDD isn't about traditional testing. Its about expressing design through testing. In that environment, if you are writing good tests it means that you have correctly and completely expressed the design in a way that can be automatically validated. Also, implementation of the tests depends on virtually all the skills required to write good code. If you can write good tests for TDD, then you can also write good code.
All of the skills for writing good tests and writing good code are gained through experience. TDD is not a substitute for experience, it is a method for exploiting experience.
Every development methodology has a tendency to get stuck at a local optimum.
There are techniques in evolutionary computation to get out of a local optimum (adaptive mutation rates, forking, migration, restarts,
XP provides a low risk way to do the same. Sweeping design changes that would ordinarily force a project manager to mainline prozac can be handled with very little risk. I've seen it done... I've done it myself.
Like any tool, incorrect use of templates is dangerous. I have a chain saw at home that I won't let my 12 year-old use for that very reason.
Debugging poorly designed and poorly tested templated code is difficult to deal with. Design it properly, test it thoroughly, and its much easier.
Explicit instantiation can sometimes be used to reduce compile times and establish control over which template instantiations are actually available.
Templates are not the silver bullet for every problem. They can be overused, abused. However, when you need them, they can be amazingly helpful, just like the chain saw.
You can put the implementation of a templated class into the cpp file IF it is explicitly instantiated.
Add the following to the bottom of Foo.cpp:
template class Foo(int>;
There is a limitation... you cannot instantiate Foo without adding an explicit instantiation for it. For internally used template classes, this is sometimes quite useful.
You can put the implementation of a templated class into the cpp file IF it is explicitly instantiated.
Add the following to the bottom of Foo.cpp:
template class Foo;
Change references to Foo in
There is a limitation... you cannot instantiate Foo without adding an explicit instantiation for it. For internally used template classes, this is sometimes quite useful.
The only requirement for a geosynchronous orbit is that its period is one day. It can be at any inclination.
A geostationary orbit is a geosynchronous orbit that happens to have an inclination of zero (w.r.t. the equator)
In this context DFA refers to "Deterministic Finite Automata". Among other things, they can be employed in highly efficient lexical analyzers. If you've got a decent book on compilers around, you can look up the details.
If you actually read the book its clear that the swarm of nanobots actually makes a camera using a synthetic aperture. The effective aperture of the camera is the size of the swarm, not the size of the nanobot. That part, at least, was credible...
vi: the first 2 letters in the word 'vile', the middle 2 letters in the word 'evil', the initials of the 'village idiot'.
The reason I assumed that 'King of the World' hadn't tried pair-programming is that he didn't say he had. What he said was that he "didn't belive" in it. Belief is a funny thing. Most of us has firmly held beliefs that are based on virtually no objective data (like the attitude I used to have toward XP).
I'm not going to tell you that XP in general (and pair programming in particular) will work for everyone. I can say from experience, that it has worked for me... after an overwhelmingly negative initial reaction.
Did 'King of the World' give pair programming an serious attempt. I have no idea. I wouldn't call sitting bored with another programmer for a half a day and then saying that you don't like it a serious try...
BTW: I wouldn't introduce pair programming as the first 'XP' practice. I'd introduce Test Driven Design first. It works better in isolation and it has a faster payoff.
If the idiots in Salem mandate a GPS in every car so they can charge a mileage tax.
http://www.odot.state.or.us/ruftf/
I open up my old drives, remove the magnets, and bore holes in the remains with a 30-06. The magnets are powerful, I truly enjoy boring holes that way, and my data is secure. It's a win, win, win situation.
Have you ever tried it seriously? If not, you are falling into the trap of speaking in ignorance.
A few years ago, I would have said much the same thing. After giving pair programming a honest try, I write virtually all of my production code with a pair.
As a result of pair programming and Test Driven Design (TDD), we have been able to write a new embedded, real-time application for one of our systems in just a few months. IIRC: The number of bugs found in this application is 5, and 2 of those were compiler/tool related.
This is just the most recent application we've developed.
Don't knock it 'til you try it.
VNC...
at least under linux, VNC is quick enough to make it better than shoving the keyboard back and forth. You have to work out the signals within the pair so you don't 'stomp' on each other.
Under windoze... VNC is less useful.
As for getting the furniture you need... if you're lab isn't set up to do pair programming, then you cannot effectively do pair programming. Then again, I've done useful pair programming under windoze using VNC over a T1 with a headset phone... It's better than nothing.
Sad as it may be, Hotmail does listen to their customers. Its just that the customers aren't who we would like them to be.
...
I don't know anyone who actually pays for a Hotmail account. Do you?
OTOH: The advertisers do pay. That makes them the customers.
Hotmail users have other names: pidgeons, marks, suckers,
When you go looking for a specific pattern it's not surprising that you find exactly what you are looking for.
Possibly you could simply accept that your views are not necessarily the mainstream.
That gun owners are a vocal lot could possibly be explained by the natural tendency to defend yourself when someone else decides to mess around in you chili.
Don't wear drab, brown clothing in the woods during hunting season.
On second thought,
I spent 12 (horrible) years working on DoD software as a contractor. The likelihood of finding a "group of knowledgable professionals within the DoD" is vanishingly small. Virtually every technical employee of the DoD that actually has two brain cells to rub together leaves as soon as they can for a much better job.
... what can I say?
The ones that stay,
Decisions like this are typically made based on reports generated by consultants, often without a great deal of technical savvy. I have often suspected that the reports are evaluated in the same manner that many of my professors graded papers. Throw the stack of reports down the stairs, the one that reaches the bottom wins.
BTW: I haven't done DoD software for several years now. What a relief!
Why does a dog lick itself?
Because it can!
You can change your organization, or ... You can change your organization.
The simplest and most eloquent way to convince such a manager that this is a bad idea is to get another job.
1) It conveys the depth of your feelings in no uncertain terms.
2) It educates the offending manager that his heavy-handed, short-sighted, $#%!@^# style is counter-productive.
3) It removes you from an abusive situation.
Your career is too short, vote with your feet.
I've got to agree with you... I've yet to attend any kind of company sponsored training in which the suit that's supposed to train us had a clue about what was really going on.
Once, most of our team walked out of a class during the first session because it was so lame.
Another time, a class on real-time programming featured an instructor that didn't know what Rate Monotonic Analysis was, much less how to apply it.
I see two problems:
1) Management is easily seduced by the marketing of 'training' firms that have much more experience/talent in marketing than in the subject of interest.
2) Firms that actually have the desired knowledge make a great deal more money by directly exploiting the knowledge than teaching others how. Thus, the people we could really use as instructors aren't available.
Might it be that the value is in the nanoparticles and the method of acquiring them, not the mass of gold?