>>Walter is deliberately harassing me. Yet you permit it. That was my complaint to Koen. They cannot understand the simplest techniques. No one in the community accuses Walter, like I was accused.
>>
>>I have seen so much stupidity and I'm sick of it. We can do better. Transactions should be a standard, which is better than the piece-meal approach too often used.
>
>OK, time out on the field.
>
>Mike, at this stage, I'm really perplexed. I'm sorry to have to say this, but I'm going to - you need to calm down.
>(I'm not "permitting" anything). Yes, Walter has made comments I also don't agree with, but truthfully, you seem to be instigating much of this.

I am the one promoting a technique that works for all situations, because of the way FoxPro is built. I have had to adopt this technique because of other stupid programmers "out there". That does not give anyone the right to say my position is illadvised.

I promote only the facts and the science. If Walter disagrees he's free to do so, I only am not going to tolerate his or anyone's deliberate and admitted abuse. Nor should anyone.

If you think people are not stupid, I am providing examples from my experience where stupid choices have led to a bunch of hardship and companies don't know a good developer from a bad one.

Take for example, hiring someone without checking with the developers. The girl shows up with a FoxPro for Dummies. She spends an entire week studying the code. Then is asked how much longer she needs. She says another week. Her Dunning Kruger let her think she was good enough for the job. She wanted 80 hours to do a report change. I estimated 8 hours and completed it in 6.

We are not all equal, and we cannot promote good practices by being attacked by others. THAT is the problem with all of these so-called communities.

>
>You and Walter are both swiping at each other, and quite frankly this entire thing is getting silly and out of hand. You are both smart guys and less experienced developers can learn from both of you....but not in this way.
>
>Both of you have made some valid points. All I was doing was building on a good point that Walter made - transactions are, among other things, the framework for the "ooops, never mind, I take it back" protection for integrity of the data. I was merely talking about one particular context of transactions. I agree, they should always be used.
>
>Final comment....these "if you do this, you might be a crappy coder" posts are not going to advance any ideas.
>
>I agree.....hard-coding names is a bad idea. Guess what, I've seen source code from commercial applications that do it.
>Copy/paste is a bad idea....guess what, I've seen source code from commercial applications where a change is required across X modules, simply because the authors didn't think about a level of abstraction.
>
>I could go on, but hopefully you get my point.
>
>There's bad code all around. It can happen for many many reasons.
>
>My boss wrote a 1.0 version of a cost piece before I showed up. It "worked", but he and I both agreed it didn't work well. There was repetitive code....there were things hard-wired...there were assumptions made that a query would only return one result. I took it over, was able to devote more time to it, and cleaned up a lot of things. My boss never felt any "pride of ownership" and never got defensive. Also, he built that 1.0 version out of NOTHING. I was able to fine-tune and clean up things because he had done much of the initial leg work on the project. Systems evolve...and even though his code probably broken about 50 of your rules, it doesn't mean he was necessarily a "crappy coder". I think that's kind of a simplistic way to look at it. There is a balance between business and time/resource realities, and writing good clean code that's nice and elegant and less likely to break.
>
>Now, some shops try to mitigate this by having code reviews. They can be good ideas, if they are run by experienced folks who know how to pick battles. I've been in some good code reviews and I've been in some that clearly resulted in making solutions far more complicated by over-abstracting.
>
>But seriously, this "if you do this, you might be...." is going nowhere, fast.