Alan Cox on writing better software is interesting partly because people might take notice. I think he leaves out the single most important aspect of writing solid software, though: state of mind. You have to focus on robustness.
I remember once reading an article in an industry rag (Dr Jobbs' Journal?) that I don't usually bother with, on writing robust software. It said that the key to robst software is to use lots of assert statements, and gave the example of an interactive editor.
Most users wouldn't consider an editor that crashed as soon as it detected an internal inconsistancy to be very robust. The software might be robust from the programmer's point of view, in that many errors were foundduring testing and development, but assertions are a development tool (and a useful one), not a tool for helping software to be resiliant in the face of errors.
So it's all a question of how you look at it.
If you are wondering, I'd suggest using a good exception mechanism that logs an error and lets your program return to a known safe state with minimum data loss.
If the editor's buffer is known to be corrupt, warn before letting the user overwrite the original (or any other) file, for example. Don't require saving to a new file (disk may be full), but don't make it too easy. Old versions of the vi editor used to do this very effectively, and whether you liked the program or not, it was written to try not to lose data.
A function that accepts an integer in the range 7 to 31 needs to check its argument so that errors don't spread. But in the error case it needs to signal an error to the calling function, with some documented out-of-band value. It's tempting to say, the type system should handle this but that's not actually true. For example, you might define a C++ object that can only handle integers in the right range, but your function needs to be robust against the case where someone uses a cast or otherwise overrides the type, and also where they edit the header file and redefine the type (legitimately or otherwise) and don't change your code. Relying on the calling function, the type system or the compiler to do your checking is an abrogation of responsibility (more commonly called laziness :-)) and is an example of not being sufficiently diligent in writing solid code. It's about writing even a single line of code without asking yourself what are the possible error conditions and the consequences of errors.
So writing better code is about wanting to write better code: if you're not motivated, you won't do it.
A business decision that you are going to trust all data on the local area network can save you a lot of money in programming, but then when your system is deployed on the Internet the cost of making it secure is high. The real cost (as one large operating system vendor has discovered) is that you get programmers with a mindset of trusting data to be correct, trusting values to be within bounds.
Alan is right in that we need to find/create and use tools that can help us to identify and fix problems. If you manage a team of programmers, reward them for fixing bugs and for having fewer defect reports from outside the group, and be careful not to punish them for their errors, but to ask each time, how can we work togeher to stop this from happening again? Well, OK, and maybe confiscate their shoes :-)
devmeet - organised a devmeet for "deviant artists" in and around Toronto, this Sunday. But I am not sure that I'll be there: my 'plane back from Japan may be delayed by a typhoon.
If you're a Deviant Art person feel free to join us!
Japan - been here for meetings about the efficient interchange of XML. Good meetings, although I still find Tokyo a little intimidating. Maybe more on Tokyo later!