In some mail from George Capehart, sie said: > > <rant> > This is truer than you know. I've been writing code since 1974, and I > see the same mistakes being made over and over and over and over . . . > again. Just as in wars, it seems that every generation is destined to > make the mistakes that their elders made. There is no industry-wide > repository of "Lessons Learned." Each generation is left to make the > same mistakes over and over. If one were to do a root-cause analysis, > what would one find? Programming courses teach grammar and syntax. > They do not teach "safe programming." (Except Crispin and Dave, of > course . . .) Programming managers are programmers who grew up and > decided they'd had enough of the 80-hour weeks and wanted to become > managers. They don't know/care, either. It's only when the "powers > that be" decide that it's better business to deliver bug-free, secure > code than shipping mostly-working code out the door that things will > change. Wanna take a bet on how long that'll be? > </rant> So, you seem the same mistakes being made over and over... While I agree there isn't enough of "lessons learned" in programming, I think this also applies to the people who develop languages. The unfortaunte case is that potentially the only languages that aren't susceptible to being "exploited" are those like prolog/lisp, but who uses them to write an application? I think this is the case with PHP - it and the problem it is solving needs to be reexamined and a better language developed that is written with the actual target audience (and their skill levels) in mind. Whilst I can't comment on what every project does, I'll comment on what two projects do do in order to produce better code. 1) openbsd commits generally require the approval of two others when they're commiting code. to what level the code is reviewed I can't say - it is all internal. 2) OpenSolaris projects will all post code changes to the Internet before code is committed to the project. Review of that code is generally open for at least 2 weeks. When it comes time to put that code into OpenSolaris, the review process requires the code team to enumerate and discuss every issue brought up. Internally the goal is to try and select people who are faimilar with different areas/functionality to review code. While management don't like all the delays, they're there for a purpose and the steps cannot be walked around, so they might grumble but they do accept it. For other projects, people post diffs and there is a less formal review process - and possibly only one person to decide yes/no. If you want to be part of the solution, rather than just the rant, feel free to join the opensolaris community and contribute ideas on source code changes or how the processes work. Doing open code reviews is a process we are just starting to come up to speed with, so there are no easy indexes of this activity available. Darren
