Agile development/extreme programming
- An important property of TDD tests is that they involve a double-check. [...] Kent has pointed out that this double-check principle is a vital principle, and it's certainly one that humans use all the time. The value of the double check is very much tied into using different methods for each side of the double check. Combining Specification By Example with production code means that you have both things said quite differently, which increases their ability to find errors.
Zed Shaw says (http://www.oreillynet.com/ruby/blog/2006/05/post.html):
Recently, you’ve been putting a lot of work (beyond unit tests) into making Mongrels stable and secure. Would you explain your methodology and the tools you’re using to make it work?
Zed I agree with the OpenBSD group’s assertion that security holes come from defects in general, not from some specific “security hole” that you look for in the source code. This means that I think if I fix all the defects I can find, and try to be proactive about potential errors then I’ll prevent a lot of security holes in the process.
With any of my projects I try desperately to do the following:
- Keep the code as incredibly simple as possible. I call this “The Shibumi School of Software Structure” because I like the letter ‘S’ and because it’s the exact inverse of what most programmers do when they structure software.
- Code reviews of my own code before releasing, constantly trying to find:
- “missed assertions” — Unstated assumptions about inputs and outputs.
- “missed else” — Logical branches that don’t cover all test domains.
- “will it stop” — Looping errors that will cause classic infinite loops or short loops.
- “check that return” — Return values that aren’t dealt with properly (which are really assumptions about other inputs and outputs).
- “unexpected exceptions” — Exceptions are pretty darn evil since they’re rarely documented.
- “simply readable” — Replacing clever code with readable simple code where possible, and documenting complex code so it can be reviewed by others.
- Unit testing as much as possible. [...]
- Usability reviews from potential or current users. My motto here is “If I KMU (Know My Users) they won’t have to RTM [Read The Manual].” I really think if a system is easy to use then the security concerns are lower, but I don’t have much evidence to support this claim.
David Heinemeier Hansson: Frameworks are not designed before the fact
Ruby on Rails: An Interview with David Heinemeier Hansson, 2005-08-30:
ED: One of the things I like about Rails is the differentiation between production and development environments. Those kind of features don't normally come built in with scripting language web tools. Did you consciously set out to provide some "enterprise" features in Rails?
DHH: I set out to serve me. Rails is a very selfish project in that respect. It gained a lot of its focus and appeal because I didn't try to please people who didn't share my problems. Differentiating between production and development was a very real problem for me, so I solved it the best way I knew how.
It's hard enough to solve your own problems with eloquence. Trying to solve other people's problems is damn near impossible—at least to do so to the level of satisfaction that would make me interested in the solution.
That's why we hold the notion that "frameworks are extractions" so very dear in the Rails community. Frameworks are not designed before the fact. They're extracted when you've proved to yourself that an approach works. Whenever we get ahead of ourselves and try to leap over the extraction process, we come back sorely disappointed.
I believe that's why Rails just feels right for so many people—because it's been used by real people for real work before we dished it out for others to reuse.