Reading the latest paper from Daniel J. Bernstein named "Some thoughts on security after ten years of qmail 1.0" [archive info], I was impressed by the overall tone of his paper. Often in scientific papers, we don't see the full path from the errors made by the author(s) to the solution that could help the reader to avoid the same pitfalls. I have really appreciated the following part :
In retrospect, it was stupid of me to spend code not just this file parsing code, but also code to distribute message files across directories dealing with a purely hypothetical performance problem that I had not measured as a bottleneck. Furthermore, to the extent that measurements indicated a bottleneck (as they eventually did for the message files on busy sites), I should have addressed that problem at its source, fixing the filesystem rather than complicating every program that uses the filesystem. That's a great lesson of humility to all of us when we are programming. Moving the issue by creating complexity somewhere else instead of fixing the source of the problem. I made that too for various reasons but we should try harder to avoid such case. That's very difficult for me (and I'm pretty sure for you too…).
When you are more and more involved in software security assessment, you are more and more convince that simplicity and small code is a good helper to produce more secure software. The paper of Daniel J. Bernstein is reinforcing the point with his historical perspective on his own software. Again Edsger W. Dijkstra is cited and with a nice word of wisdom :
... idiot software managers measure "programmer productivity" in terms of "lines of code produced", whereas the notion of "lines of code spent" is much more appropriate. from [archive transcription of EWD962-4]. I just hope that simplicity in software engineering will be a requirement when distributing software. But I'm just dreaming and really need to get up this morning.
When trying to get up, I was there : geo: Les Bulles, Chiny