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.

     aka.  You can't even break even.

    aka.  You are behind before you start.

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.

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.

Who is the customer? You or the child or both?

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

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.

Free is as successful as poverty.

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.

If its US, its BAD!

If its European, its GOOD!

If it has been decided by some unaccountable academic pin head committee to be forced down the throat of others, its GOOD!

If its been around for the better part of a 1000 years and used by common folk in their daily lives, its BAD!

Hmmm.... I see a pattern here. If its used by people who think they have a RIGHT to be free from being FORCED by others to do what they would not otherwise do, its BAD. If its the consequence of arbitrary Governmental decree and enforced at the point of a gun, its GOOD.

In my opinion, there is no amount of rationalization that will make this good.

Hmmmm..... Maybe a not so horrible bad answer is as good as we can do.

I like the notion that productivity should be considered as rate of delivery of value. Unfortunately, this gets into the sticky questions of value to whom and for what purpose. An even more sticky question would be how to measure it if you can answer the first two questions.

On the "somewhat higher up" questions. Are we to hold the programmer responsible for such things as "conversion rates" which may be more impacted by advertising, quality of web site, and momentary media buzz than by anything the programmer did? If so, how is this measuring the productivity of the programmer. Its difficult to make the connection. That is unless you are the whole team from start to finish.

Perhaps the best we can do is compare present and past "productivity" to see what has improved and what has not. If there is a net improvement, then "productivity" has increased else not. Trying to put a number on it beyond plus or minus may be a hopeless dream.

Still, for something that seems to be driving the world's economy, a hopeless dream is not very satisfactory.

Joe paints a three bedroom house in three days and gets paid $300.

Jim paints a 5 ft by 3 ft watercolor landscape in three days and sells it for $1,000.

They both get their job done in three days. One covers far more area with paint than the other. One gets paid more than the other. Both of their customers are happy with the result because they paid for it. Who is the most productive?

Is it even meaningful to ask that question?

Doesn't it depend upon WHAT it is that is produced? Doesn't the WHAT have to be the same in both cases to be able to say which is more or less?

Perhaps before we talk about being more or less productive we need to identify what it is that we are producing. We should make sure its real, meaningful, and relevant to our purpose and that we are all talking about the same thing. Then finally, we must measure something that can't be easily inflated or faked. Only then can we talk about more or less comparisons and be saying something other than words without real meaning.

As I see it we have two questions to answer:

What is it that we are actually producing when we write software?

How can we reliably measure it?

We don't have good answers for either. Actually, I don't think we even have moderately good bad answers.

Isn't it interesting that a large and increasing fraction of the world's economy is based upon something we don't really know what is and can't actually measure?

Evolution produced God. God didn't produce evolution.

Religion and belief in God are brain noise. Its people seeing patterns in random disconnected events where there are no patterns. This has a very likely natural selection basis.

If you see a predator that isn't there, its much less costly than not seeing a predator that is there. So also, if you see food that isn't there, its much less costly than not seeing food that is there. Hence, natural selection will be in favor of the individual/population who overreacts to noise in the environment. This overreaction results in religions and belief in gods.

1% of the population make things happen. 9% of the population watch what happens. 90% of the population wonders what happened.

The majority of what most people believe is wrong in one or more very significant ways. This has been the case since the first people started beliving.

About the only thing that will continue to exist in abundance is stupidity sustained by abysmal ignorance and the taking of stuff that belongs to others.

"...you have to find ways for the larger team to work together and still produce a quality product. "

I am not sure its possible. The communication overhead of so many linkages forces incoherence. The resultant incoherence forces still more additions to process and body count. That adds still more communication overhead. The result is still more incoherence - not less. If something is "finished", its simply because time, money, resources, and toleration ran out. The end result was simply called "done".

Maybe that is the best we can do but I am hard pressed to call products produced that way quality products. See Vista et.al. for instructive detail.

Maybe the problem is that you have the 20-man team. There is no coherence in the code. The design is wrong, coupling is too high, and the module cohesion is too low. The large team makes certain that is the case no matter how "tight" (aka heavy) your quality control process.

I have found from working in large teams, there is a core four who get things done. The rest are simply dead weight dedicated to shuffling paper and attending meetings. At best, they do nothing. At worst they create more work than they do.

Use the right four and dump the other sixteen. You will get at least ten times more productivity and ten times higher quality without even breaking a sweat. If you don't have the right four, you are hosed from the start.

Isn't this rather like saying than since a five pound sledge hammer can't fix watches, tools suck?

I find it best to use the tool that is appropriate for the task. This is true even though you might be able to force fit a particular tool to a mismatched task. Saying that there is only one true way is always wrong. Especially since any of the ways we have are at best only good enough for some tasks, mediocre for many, and really horrible for others.

The title should be translated to "Why One True Ways Suck" or on a really bad day "Everything Sucks".

Then why do such an exhaustive automated test?

Why not have your local tests, automated or not, cover the common cases and error conditions to catch programmer stupidities? Then let the actual humans do the strange corner cases.

If your design is even close to correct, testing repeatedly tested code is pointless. If your design is corrupt and your implementation is sloppy, no amount of testing is going to save your ass.

I do very rapid turns and I am a one man team. I can turn my system in less that 30 minutes and have the user testing it in a live situation on the other coast. If I want 10 turns a day, I can easily do it. Low coupling, high cohesion, clean correct design, and disciplined implementation makes it possible.

I agree that doing things in small chunks is a great way to do it but doing the equivalent of a weeks worth of global automated testing for each small change seems like a silly exercise. That is except for the server hardware salesmen and system admin people.

The sales commissions and payroll look rather good. The production of real value is questionable. Bang for the buck is as important for testing as it is in any other part of product development.

Interesting idea but....

Looks like meeting that goal would constrain you to write code to be used by a robot and not by a human. There may be many cases where this is both doable and acceptable to the end user. So no problem with that.

I am greatly challenged to see how this could be done for a highly interactive, visually oriented, subtle pattern generating response to user input, type application. Computers are still not as bright as earth worms when it comes to generalized pattern recognition. Which means we programmers are about as bright as earth worms when it comes to writing such code.

How then could computers automatically test all the software reactions to the wonderful and totally unpredictable behavior of mere humans as they interact with your software? The test cases would expand to consume all the resources available for development. All you would get done is writing all but impossible test cases. At least you wouldn't ship bugs.

This does not consider the explosion of combination and permutations of inputs that prohibits exhaustive testing that no matter how many systems you run tests on.

It would be much easier and cheaper to go out of business. Your certainty of being free of shipped bugs would be much better than one in a million.