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

[ reply ]