Huh? I am no fan of RMS, but his mind does not deserve to be described as small. More importantly, the form of play he is describing -- which, as play, isn't trying to produce useful results or large results or necessarily any results at all -- is a deeply human thing. In the long run, it leads to large results much more reliably than serious effort to produce large results does.
At least we now know the words and phrases that can annoy the most individuals most of the time. The net-net is that it can be valuable. However, the bottom line is that it is a challenge to use them in a value added way.
My take away from this article is that its a space filler. It was a slow news day and/or his real news sources were out of pocket.
You know what I mean?
Oh well, if this is the worst we will have to deal with today, its going to be a good day.
TDD means you write your test before you write your code.
Test code is code. You must write test code for your test code before you can write your test code.
Test code for test code is code. You must write test code for your test code for your test code before you can write your test code for your test code.
TDD is trapped in a loop of infinite regression. This means that TDD never produces actual application code. In fact, it can't even produce test code. How do you define a test of a test of a test .... of a test ... of a test ..... so you can write it? You can't define it so you can't write it. You have no starting point.
The answer must be that you really cannot do TDD. You just call it TDD. At some level you rely on the old standby of clean simple design, incremental implementation, inspection, and manual testing. Why not cut to the chase and do that on your application code?
I think you've missed the point. The real utility of coding to pass a test is not to verify the current state of the application. You can easily cross check that you're getting the right return values from any module manually. The real beauty of TDD comes a few months down the road when you've forgotten the current module, and you make some change that affects it. With a unit test framework in place, regression problems like these are found immediately.
Each test you write is a value-add. You get increased safety that what you're testing works the way you think it does, and that it will continue to do so as people modify it.
Not all cases need to be tested; "test to your level of paranoia" is our motto. In the case of tests themselves, the value add for testing individual tests has never been worth the ROI. There are, however, tests for the testing _system_, insofar as that's possible (which it is, for the most part).
As for the "I happen to view TDD as a completely obnoxious and unnecessary exercise" objection, I'd be willing to bet you've never tried TDD. It doesn't take long for proper TDD to _save_ you time. Each iteration cycle is slower, but the marginal cost for adding new code to a complex codebase doesn't increase nearly as much.
Without TDD, you soon have to spend time on manual testing, and then you've got humans in QE basically practicing TDD for you, as the walk through script after script doing things that could be done faster by a computer. The only time it's appropriate to consider skipping TDD, IMO, is on tiny one-man projects.
I see. TDD works on poorly designed, poorly implemented, basically lousy code. Code that is highly coupled, withlow cohesion, and is inappropriately modularized. This necessitates that all code must be tested every time there is a "modification". Add to that the random unthoughtful modifications made by careless programmers who have identified the wrong problem to fix and you get constant disaster.
I say, fix the fundamental problem by not writing lousy code in the first place. THAT would really be adding value rather than simply adding job security busy work. Automated testing cannot fix lousy code. Most of the time, it can't even discover it.
There is no magical way that gets good results without knowledge, skill, understanding, thought, discipline, and effort. With those things, all you need are good enough tools. TDD may be one of those good enough tools in some limited circumstances. It is not a Silver Bullet that cures all, most, or even many software flaws.
Keep in mind that one really good programmer can out produce a team of twenty poor programmers. Also keep in mind that one poor programmer can keep twenty really good programmers busy cleaning up the trash they create.
TDD is a very poor band aid used to cover up an even more fundamental problem: most programmers are lousy at programming. That is the problem that need fixing.
TDD is like bumper lanes at a bowling alley. If your goal is to knock down the pins, it can help prevent problems, like falling in the gutter.
Of course, if you're incredibly good, you don't need the bumpers. You might even forego bumpers to show off that you are -that good-.
Your solution is to make all the bowlers really good. Here's the issue - historically, that doesn't scale across a growing dev team.
Imagine 5+ bowlers all using the same lane. The more bowlers you have, the more you will have balls bumping into each other, getting in the way, crossing paths, and falling into the gutter.
As you increase the number of developers, the more likely it is that tools like TDD and Source Control can help mitigate issues that inevitably arise on a larger team. They aren't silver bullets to great programming, and they aren't a bandaid to cover up bad programming. They are time-tested, proven ways to get people going the right direction.
"Imagine 5+ bowlers all using the same lane. The more bowlers you have, the more you will have balls bumping into each other, getting in the way, crossing paths, and falling into the gutter."
I suggest THAT is the problem. TDD is a band aid to cover the fact that such a team cannot function. The right team of <=4 can blow the roof off of ANY team of 5+ based upon communication network overhead alone. If you don't have the right team, you are hosed no matter what.
It's much easier to arrange for your test code to be extremely modular, with different bits not affecting one another, than it is for the actual application code. And for most problems it's much easier to get evidence that you've solved them right than it is to solve them right. (It's a bit like the difference between P and NP.) Therefore, writing good test code is much much easier than writing good application code. This is the answer to your last question, and the reason why the rest of what you said is wrong.
How do you know your test code is testing what you need it to test without actually testing it? If not by TDD, then are you really using TDD or simply saying that you are?
Like I say. Cut to the chase. Incrementally write good, clean, well designed, application code. Then inspect and manually test. THAT is the ONLY thing that really works. Stop pretending you are doing something that you aren't. Especially don't use it as an excuse for writing lousy, poorly designed, and poorly implemented application code.
TDD is still one more attempt to create a sacred Silver Bullet that gets good results without knowledge, skill, understanding, thought, discipline, or effort. Its at best a very feeble tool in a quiver of feeble tools. It takes a good, well trained brain, paying attention to get good results. Without that, nothing will work.
PS: Writing good code is never easy. It only looks easy when done by someone who really knows what they are doing.
Who here, please, is claiming that TDD gets good results without knowledge, skill, understanding, and all the rest of it? Or that writing good code is easy?
Your infinite-regress argument would be entirely sensible if someone were claiming that all code written without testing it is entirely broken. Fortunately, no one is claiming that. In view of which, what you say is just like this: "How do you know that your reasoning about what the code needs to do is right unless you've checked your reasoning? And then how do you know your checking of your reasoning is correct unless you've checked that? Etc., etc., etc. Therefore, no one is really developing software by thinking about it."
TDD is not supposed to be an alternative to writing good, clean code, inspecting it and testing it. It's supposed to be a way of writing good, clean code. (No, that doesn't mean it's supposed to enable idiots to do that, or supposed to make it effortless.) Maybe it works well -- i.e., enables a person with a given amount of brainpower and a given amount of training and experience to expend a given level of effort and get better code -- and maybe it doesn't; but the objections you've made here don't make any sense.
Sorry. I was attempting to argue with a religion. My bad.
The basic premises cannot be questioned. The words of the sacred order must be followed to the letter. They must be swallowed whole without modification. They are to be held to be applicable to all problems, all contexts, forever, amen. That is except when they don't apply according to some mysterious unwritten set of rules held by the sacred order.
Gad. I can't count the times I have seen this crap since I started developing software back in the mid 1960'sd. It started with designing software using an IBM flow chart template. Each "method" had their very narrow range of applicability. None were the cure all or ultimate solution they were touted to be.
Automated testing has a place. The place is small, narrow, and limited. I seriously question that it can make up for lousy programmers and lousy code. Especially since they are also usually the programmers of the test code.
This is an issue that is indistinguishable from my identified problem of infinite regression. How are you going to test the testers to make sure they are testing what needs to be tested the way it needs to be tested?
Ultimately its do the right things correctly. What that is is much more dependent upon the problem and its context than some sacred text and holy method.
I am not a TDD zealot, nor even a TDD advocate. (I haven't written enough stuff that way to know whether it works well for me, never mind anyone else.) I was just pointing out some flaws in your reasoning. I don't think I'm the one being religious here.
I don't agree with jmathes's diagnosis that you're trolling; I'm sure you really believe that I am a fanatical TDD devotee who thinks TDD is the right thing for every situation, that I regard everything to do with it as sacred and holy, and that I think TDD can make up for lousy programmers and lousy code. Since none of that bears any resemblance to the truth, however, I'm going to leave it here, and just suggest that you go back and re-read what I said, and see whether you can find any actual evidence of zealotry there. Then, when you don't, you might want to work out what's got your zealotry detectors so oversensitive and made you draw such stupid conclusions, and maybe think about fixing whatever it is.
I think your troll detectors are miscalibrated, though not as badly as lgriffith's zealot detectors. But I think you're right that there's not much point in trying to carry on a reasoned discussion with him on this topic. Sorry, all.
The VB version was a working prototype. They had built a war chest on its back but the prototype was blocking their future. It was making them vulnerable to the competition. They smelled blood in the water and it was theirs. The feeding frenzy was about to begin.
Taking the lessons of the past and a clearer understanding of the needs of the market place, they created a path to the future. Not a bad choice in my opinion.
I am not so sure about using C#. That is much too tied to a specific vendor and programming model. I am sure VB is best used as a prototyping and proof of concept tool. If you have need of a disposable program, its great. If it must live long, wide, and numerous, it has trouble being even as good as a poor choice. With the right choice and a good bit of luck, they not only survived but went on to thrive.
(with apologies to The Three Laws of Thermodynamics)
1. Software written by someone else is bad software
aka. You can't get ahead.
2. Software written by me more than six weeks ago is bad software.
aka. You can't even break even.
3. Its been at least two months since I have written software of any significance.
aka. You are behind before you start.
The bottom line is that software universally sucks. The reason we keep trying to make and use it, its far better than what it replaces. Maybe, if we try real hard, we will finally get it right. If history is any guide, don't hold your breath.
Computers are the tools of the devil. ...
Everything I've learned about computers at MIT I've boiled down into three principles:
Unix: You think it won't work, but if you find the right wizard, he can make it work.
Macintosh: You think it will work, but it won't.
PC/Windows: You think it won't work, and it won't.
At least the Unix wizard can pretend he is going to make it work. All he needs to do is pipe this into that and write just one more filter. Then he can ....
By that time both he are you are lost in a blur of keystrokes and flashing characters on the display. As you leave the computer room, you can hear him muttering: "Oh, damn. I am in the wrong shell. I have to do it this other way...tap...tap...tap...."
The truth is, it doesn't really work there either. You are simply tired of waiting and are willing to accept almost anything to stop the annoying tapping noise and the endless muttering.
Hey, it keeps us off the streets so it isn't all bad.
The Cloud absorbs all. Once you live there, your life becomes one with the Cloud. You no longer belong to you. The only answer is never to have joined the Cloud. It is already too late. Resistance is futile.
If the "distinguished professor" wished only to teach his version of political activism, he should sign up to teach a class in his version of political activism. That way, his customers (aka students) would be getting what they paid for rather than an irrelevant rant from a total fraud.
If its Physics, Physics should be taught. If its Math, Math should be taught. If its Politics, Politics should be taught. The purpose, function, and reason the academics are employed is to teach students the content of a defined field of study. An academic does not have the right to refuse to perform his job and still keep his job with all its benefits.
Stallman objected to the fact that software could be sold so he made software that couldn't be sold. I am sure he understood its true value and priced it accordingly.
Create and deliver value. Demand to be paid for it according to its value to the customer. If the customer refuses to pay, find another customer.
Perhaps you are paid for the value you deliver. If not, why did you do it? However, it is a payment that cannot be transformed by exchanging it for other things you need or want. Its primary benefit resides within you and your child.
Money is not the only form of payment but it is an extremely important form. This is because of its use as a medium of exchange in a division of labor economy. The existence of both supports and sustains a far higher standard of living than could otherwise exist.
Stillman's philosophy is to reduce the production of intellectual values to the state of a barter economy. That kind of economy rises only slightly above subsistence. This is why I say "Free is as successful as poverty."
I disagree. What he says is totally and absolutly irrelevant compared to what he actually does accomplish. The purpose of a system is what it does. Reduction to the barter system is what application of Stallman's philosophy accomplishes. THAT is his purpose.
According to Stallman, one should only be able to trade software artifacts for other software artifacts. This is even worse than a barter economy. Its as if an egg producer could only trade his eggs for other eggs or a potato farmer could only trade his potatoes for other potatoes. This in one simple step eliminates a division of labor economy with all of its attendant benefits and multiplication of productivity.
The result of an internal combustion engine is the transformation of heat energy into kinetic energy. Thermodynamics says this conversion cannot be 100%. Hence some of the heat is not converted. The "wasted" heat is not lost. It is simply not used.
To say the purpose of an internal combustion engine is not to use heat energy distorts the meaning of the words to the vanishing point by implying that the purpose of everything is not to use heat to the degree they don't do it.
The statement is "what it does". Its not "what it doesn't do".
But the result of GPLed software is also that it can be freely modified by anyone who cares. I think your stance is to one-dimensional, while remaining interesting. I also cannot prove you wrong. I will think about it. My guess at the moment is, that RMS changed his views over time.
Again, I don't care what RMS says, what he does is what is important. Simply read his re-re-revised EULA. His focus is to prohibit useful and valuable combinations of proprietary and OSS software by requiring the free distribution of the proprietary intellectual property content and abandonment of any applicable patents.
Which result has the most fundamental impact? The restriction to trading software artifact for software artifact no matter what or allowing modification by anyone who cares. For the former, there is no choice. For the latter, there is the choice to modify or not. I suggest the former has a far more profound effect on the final result.
Perhaps our disagreement is that I think the results are mostly detrimental and you think they are mostly good. The question is good for whom and for what reason?
I don't think that I am the one who is being one dimensional here.
Hardware is cheap. People are expensive. However these facts are lost on most upper management.
I have developed software for four decades. I was expected to develop the next generation software on what was essentially obsolete systems. I was never allowed to use development hardware that was much over current entry level capability. I did it but at what cost of lost opportunity and lost productivity? The management was stupid cubed if you ask me.
