<dream>
Oh what I would give to convince these people of their
ignorant ways. I dream of a world with people who would
just relax and do it right - the product will get out the
door, and we could all live to be 100, stress-free.
</dream>

Jeff

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
F--F--F--F--F--F--F--F--
(the triplet paradiddle)

I must say that I found this interview a bit annoying.

I respect OpenBSD's commitment to security and code audit, but in the meantime I have to produce code and I have deadlines for that, most of us have.

I guess Perl itself can be described as "good enough", it is full of bugs, just watch p5p (or take a look at the archive), so what? Should we not use it?

And before writing a script in Perl that uses CGI, DBI and XML::Parser, something not unheard of, I should know all about all their interfaces? Plus of course the DBD(s) I am using and probably have a look at the code of Expat, not to mention Illya's regexp engine? I am sorry, but that's not the way it works. I read the docs, figure out what I'm interested in in, look around for examples (yes, examples!), and advice on using the modules, design the software and... start coding. While coding I will make mistakes and learn more about the modules. And at some point, long before the code is perfect, I will have to deliver it. And the next time I have to write a similar program I'll do a better job. That's called learning on the job and frankly I can't see any ways around it

I would _love_ to have enough time to produce perfect code all the time, but who does? I have even been told that books, yes even those written by pretty good coders, usually need errata.

I try to do my best and produce the best code I can given the usual constraints of time, (my usually poor) knowledge and environment.

So I find the contempt for "most programmers" that I read in this interview more than a tad irritating.

It won't prevent me from sleeping at night though...

I can see your point. Certainly I am in the same position; I often need to get things done at work. I guess I just took the words in a more positive way, as an exhortation to hold yourself to a higher standard. I hear plenty at work and elsewhere about getting things done, and very little about becoming a better programmer, or being proud of your code. And if you consider it, a lot of people don't care. I have a problem with those people too.

So I hope you're more sympathetic to my reasons for posting the quotes than to the quotes themselves. Since you are a person trying to do his best, it's a matter of cheering you on, like the spectators in the quote.

First of all, I think Theo is exasperating. The world needs people like him, but I sure don't have to enjoy knowing what they think. And I doubt I'd enjoy a long conversation with him.

In this case, however, his only comment would likely be "Don't call what you do 'secure' then." =) I too wish I had more time to look before I leap when coding.

--
$you = new YOU;
honk() if $you->love(perl)

Half of the responsibility resides with library and module authors. First, they have to create sane and usable interfaces. Second, they have to document them clearly.

Most importantly, they have to make as few assumptions and interdependencies as possible -- and document the side effects where they can't avoid it. If your library can be used in a multi-threaded environment and, for some reason, a function cannot be interrupted for any reason, make it abundantly clear that there needs to be a mutex. Better yet, provide a different entry point to the function yourself.

Given clean and intelligent interfaces and effective documentation, the fault for misuse must lie with other people.

Until then, we all share responsibility.

AgentM Systems nor Nasca Enterprises nor Bone::Easy nor Macperl is responsible for the comments made by AgentM. Remember, you can build any logical system with NOR.

I was one of the 'lucky' people who got my question answered on the Slashdot article, regarding Symmetric Multiprocessing (SMP), and I've used OpenBSD as my web server for about a year now, with much success. While you may not care for Theo's attitude, or some of his theories on what attributes define an excellent programmer, it's likely that most people who try OpenBSD with an open mind will find much to praise about the OS.

It's not perfect, mind you, and sometimes Theo's holier-than-thou attitude creates friction on the mailing lists, but it is my conclusion that without his completely obsessive-compulsive control of the project, it simply wouldn't have anything to differentiate itself from the other BSD variants. Yes, he's a control freak, but he gets results. Here is a system that has but one goal: a secure out-of-the-box, open-source, fully standards compliant BSD Unix distribution.

And even though it would be easy for me to take offense at the 1-sentence answer he gave to my question, I am instead filled with respect for someone who has set a major goal and refuses to be sidetracked by other aspects of the technology, no matter how cool those may be.

As far as what he said about 'knowing your interfaces', I think that's good advice, but certainly our work as programmers is to get the code written first, and worry about perfection later. Perfection in code comes after a tool is written, re-written, then written again, the last time with a real grounding in what interfaces are used, and what the security implications of this will be. It's very difficult to know your interfaces when you may not even know which interfaces you are going to use!

Anyway, I just found Perl Monks about a week ago, and I am very pleased to find a site like this. I use Perl all the time on my OpenBSD box, and although I am a complete newbie, it has been easy for me to get my work done with the great resources the Perl community has to offer.

Has anyone read this yet? (Also found as a link off of slashdot.) The main premiss is that we just don't know how to create software yet...somewhat related to the quotes above.

However, I probably ought to read Theo's article as well.

Because in todays business world there is so much competition to be first to develop something and the need to have the solution right now overshadows the need for perfection.

This is the real world, folks and if you want to thrive or even survive, you have to face up to it. It would be nice to have the time and have our employers and customers wait patiently for the perfect solution but it won't happen.

It's my belief (though I may be wrong) that Theo de Raadt works in his own little bubble and doesn't really expose himself to the real world.

To go a step farther on mrnicks's comments:
I too see secure high quality code (as defined in the article) an impossiblity in the real business world. I'd even go a step farther and say that this aspect of code is the responsibility of the employer.

When code solutions achieve a lifespan longer than a year employers will demand a higher quality, but for now the money goes to the first workable solution, and a programmer is just as much a slave to cash as anybody else.