I think I've already riffed on the ridiculousness of thinking that any software can be bulletproofed with tools or processes or incentives. Or by convincing yourself that you can hire a team that's too smart to blow anything up. Or that a new language platform will come along that will make failure impossible. So, alas, there are no silver bullets there. Plus, the fact that too many technologies have self-appointed "evangelists" doesn't help when it comes time to make a management decision on the direction a development team will take. Particularly if you yourself don't spend a whole lot of (if any) time in the coding trenches.
But here's one thing that I can confidently recommend, something that probably won't be limited by language, platform, tools, or even so much the quality of programmer: Give your developers room to fail without bringing other people's work down with them.
Practical example: At my first "real" programming job, we each had our own copy of the database, the website and the compiled code that did the heavy lifting for the web pages. Our copies of the code was automatically backed up to the server before the server itself was backed up to tape. The "authoritative" copy of the code was checked in and out of source control, and the "authoritative" version was pushed up to a server for integration & testing before it was demo'd to a potential client or pushed up to the live server for the paying customers.
For the programmer, having your own little universe meant that you could do your work without worrying about tripping up anyone else. Which--perhaps counter-intuitively--is a great incentive to create higher-quality code. Two main reasons behind this reasoning:
- The programmer has complete freedom to fiddle with other parts of the system (be they database values) or code that, technically, is not "hers" or "his," but affects or is affected by what s/he is currently workingone thing that's drilled into you when you have to take on.
- Reason #1 removes any excuse for not performing these kinds of sanity checks. Sure, there's every possibility that another programmer could have changed the upstream/downstream code, but that's why its' all pulled together on an internal testing server before anyone else sees it. And if the other programmer wasn't regularly checking in her/his code, then there's no doubt where the finger needs to be pointed, hey?
Mind you, giving each programmer her/his own sandbox doesn't come without cost. Some of it may be in licensing, depending on what languages/platforms. More likely it will be from setup/maintenance. But the fact is that the cost of a software bug grows as it moves (undetected) up the development cycle. And by "grows" I mean like the archetypal Giant Irradiated Critter straight from the Cold War era monster-flicks.
The fact is, nobody wants to spend the day as "The one who blew up the database." Or "The one who forgot to check for ..." But when you give people the freedom to fail often but also the means to fix it before anyone else finds out, they should be more likely to spend their time checking out those what-ifs, rather than convincing themselves that their code is too l33t to worry about it.
