lgriffith

An example of a small mind producing a small result.

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.

"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.

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.

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.

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.

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?

and the one ring to control them all.

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 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.

Looks good to me.

The Three Laws of Software

(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.

Rule one: Rules don't always work.

Rule two: Follow the rules.

The challenge is to know which rules to follow and what "works" means.

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.

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".

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.