Dailydave mailing list archives
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
From: "Matt Hargett" <matt () use net>
Date: Thu, 5 Feb 2004 11:34:11 -0800
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
Current thread:
- Re: Lame studies that people quote as fact that haveno basis in reality and still don't prove anything even if they did, (continued)
- Re: Lame studies that people quote as fact that haveno basis in reality and still don't prove anything even if they did Gunnar Peterson (Feb 04)
- Re: Lame studies that people quote as fact that haveno basis in reality and still don't prove anything even if they did Sinan Eren (Feb 04)
- Re: Lame studies that people quote as fact that haveno basis in reality and still don't prove anything even if they did H D Moore (Feb 04)
- Re: Lame studies that people quote as fact that haveno basis in reality and still don't prove anything even if they did Sinan Eren (Feb 04)
- Re: Lame studies that people quote as fact that haveno basis in reality and still don't prove anything even if they did H D Moore (Feb 04)
- Re: Lame studies that people quote as fact thathaveno basis in reality and still don't prove anything even ifthey did Matt Hargett (Feb 04)
- RE: Lame studies that people quote as fact that haveno basis in reality and still don't prove anything even if they did Rodney Thayer (Feb 04)
- Re: Lame studies that people quote as fact that have no basis in reality and still don't prove anything even if they did the grugq (Feb 04)
- 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 Halvar Flake (Feb 05)
- 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 (Feb 05)