All IT systems have roughly equal hassle rates. Should you improve the quality of your software (by means of thorough automated testing and so forth), other components of the system (such as the RDBMS, or the hardware) will take up the slack by failing more frequently.
Posted to Software development by Simon Brunning at December 08, 2005 01:39 PMOn I think so - can we theory-of-everything it to
Any X will expand to fill the room available for it...
...Where X in {Expenditure, Train Delays, System Hassle, etc}
I like this one...
"Any system that depends on reliability is unreliable." -- Nogg's Postulate
...which I first came across on Squishdot.
Posted by: Mark Matthews on December 8, 2005 02:02 PMOh, so do tell, what is todays hassle quotient actually coming from?
Posted by: Mark Matthews on December 8, 2005 02:13 PMThe, err, the system that we were all working on just as you left. Again. The software we wrote has been impeccable, but we've had SQL server replication screw up, a corrupt database, more network problems than you can shake a stick at, and now a server's HDD has died.
The system still works fine, due to the failover setup we have, but there's still all the hassle...
Posted by: Simon Brunning on December 8, 2005 02:22 PMQuestion: Given that you're using Spring and Hibernate on the new product you're crafting there, do you think that he hassle can go down, and if not, where will it go?
Posted by: Mark Matthews on December 9, 2005 09:59 AMThere's still an RDBMS, an OS, a network, and hardware under there, Mark. Plenty of stuff to go wrong even if our code were to be 100% reliable.
Which it won't be. We are aming for it, and with good testing we hope to get close.
Posted by: Simon Brunning on December 9, 2005 10:17 AMThe closer to production, the more obscure the bugs. A moments' thought will tell you that the easy bugs have already been encountered.
The best bugs are the non-negotiable demands from the users the night before go-live.