Re: Re[2]: Lame studies that people quote as fact that have no basis in reality and still don't prove anything even if they did

["Matt Hargett" <matt () use net>]

> MH> effort into. Another giveaway are people who "can't" work without
pointers
> MH> and/or loose typing.
>
> I am not all too sure about this. Loose typing certainly has little
> use, but pointers are so essential to algorithmic and memory
> efficiency that branding them as evil is like declaring that cars
> which go faster than 20mph are too risky. Computing is full of fads,
> and from the PM's to the QA ppl you will find "simple" recipes for
> complex problems -- do not use pointers, do not use strcpy, do not ...
> Most programmers I know are a fairly smart bunch, and trying to cram
> smart people into a box will make them find ways to evade you.
> Convincing them has served me better here -- although it is hard,
> since once they lose respect (if you screw up) you'll have a hard time
> getting them back to listen to you.

I didn't brand them as evil. I said that people who don't know how to work
without them (runtime efficiency is not mentioned and irrelevant in this
context) are not very good coders. In my experience it's indicative that
they have too much intimacy with the language and the design of their data
structures and control flow will suffer as a result. It's perfectly fine to
tweak a design later to deal with deficiencies or more optimal paths in
language features, but to not start with a language agnostic position is not
a good thing in my experience.

There is no silver bullet, you are absolutely right. A cross section of
simple things can be very effective, though none as simple as the examples
you are citing. If you read the slides from my last blackhat talk, there are
some things listed there I have found to be pretty effective over the past 7
years by trial and error. Though, as I said in my talk, it is my personal
experience that I have come to my current approach to development and QA.
Feel free to disagree with me, I might have a different idea of things in a
year's time anyways.

A good deal of programmers are smart, but it doesn't mean they necessarily
have good attitudes or work ethics. If people choose to be passive agressive
about development or QA practices, you try and work it out with them or you
get rid of them. People who can't communicate aren't going to be able to
function properly in a team environment, in my experience. Also in my
experience they usually end up being a liability and aren't worth dealing
with.

It probably sounds like I hate all programmers or I've never worked with
"good" ones, which is not the case. I've worked with a handful of people
that I have such deep professional respect for that I am always trying to
figure out how I can work with them again.


> Rule number one to me was to never ever try to force a rule on them
> just because I was in the position to do so.

As I said, some people eventually figure things out themselves. The only
coding rule enforcement I can remember putting on anyone is to not have
empty catch-all blocks like this: catch(...) {} . They were masking serious
problems in the product I was working on at the time and the development
team pretty universally agreed to scrub the codebase clean of that
construct. And I wouldn't/didn't do such a thing just because I could, it
is/was generally in direct response to very serious bug patterns caused by
specific programming constructs. You seem to keep misinterpreting me here
for some reason. I'll try to use clearer language in the future.

I did try very hard to get developers at the last company I was at to write
unit tests, but they pretty much flatly refused to do so. When my friend and
I started doing it ourselves we found a very serious bug in the behaviour of
a semaphore-like construct after just 4 tests were written. We continued to
find very serious bugs in a matter of days, but this still didn't sway them.
It turned out they were skiving off entirely and not even doing their
regular work, so I didn't take it personally. Now we are doing all our new
code test-driven for a variety of reasons, and the only complaint I have
gotten is that things can't be done as quickly. I think this is mostly an
attitude difference between the programmers I was working with then, and the
programmers I have hired now.


> Condemning pointers reminds me of the condemnation of the BASIC
> command "GOTO" which was then reintroduced as C++ exceptions (in a
> slightly more elegant way).

A C++ wonk once told me that multiple inheritance was the "GOTO" of OO
languages. Again, I wasn't condemning pointers. I think you misunderstood
what I was saying. They have their place like most constructs, otherwise
they would not exist. The same C++ wonk explained a very specific instance
where multiple inheritance makes sense, even. try/catch is cool, but finally
is what makes it pretty elegant IMO. It does seem to cheese the functional
programming weenies, though. I don't see finally used enough in most code I
look at, unfortunately.


> The worst thing that can happen in any software project is an
> antagonism between the PM/QA and the programmers themselves.

No kidding :) Did I ever tell you about the time a coder on a firewall
product I worked on was actually deleting my bugs involving buffer overflows
in the proxies so he wouldn't have to fix them? Or how he tried to get me
fired for using Purify on his code and reporting memory corruption bugs (and
generally suggesting a fix).

As I said in my previous email, it really comes down to getting people with
the right attitudes on board as a first priority. My experience was
reinforced after I read 'Good to Great', which says something like "get the
right people on the bus, then decide where you're going to take it". This
approach has been working pretty good for me in my current venture so far.
Again, though, I may have a different opinion in a year's time.

_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://www.immunitysec.com/mailman/listinfo/dailydave