Trouvé sur le web :

Première Loi de Raskin :

« Un ordinateur ne doit pas porter atteinte à votre travail ni, par son inaction, permettre qu’il soit porté atteinte à votre travail. »

(“A computer shall not harm your work or, through inaction, allow your work to come to harm.”)

Une excellente devise à garder à l’esprit quand on développe.
Dans aucun cas des données ne doivent être perdues. Surtout dans un contexte d’entreprise, de production ou de comptabilité. Bien sûr, la consistance desdites données est primordiale (je parle par exemple des liens entre commandes, livraisons, écritures comptables, etc.), sinon ce n’est pas « porter atteinte » mais « fusiller ».

Et pourtant, combien de fois Word a-t-il corrompu des fichiers ? Combien de fois ai-je vu des programmes qui, plantés en plein élan, laissaient les données dans un état inconsistant, qui interdisait de corriger et relancer ? Alors que par derrière Oracle fournissait tout ce qu’il fallait en terme de transactions et autres sécurités pour être sûr de ne pas détruire les anciennes données, même dans le pire des cas... Grrrrrr... Il n’y a rien de pire que de créer des patchs qui corrigent des données corrompues par d’autres, ou de devoir recourir aux sauvegardes pour importer des fragments de table à réconcilier à la main.

PS : Ce billet a été initialement écrit avant mon nouveau boulot. Depuis, j’ai découvert la joie de l’intégration de données et du datawarehouse, où les incohérences logiques masquées dans le schéma non contraint de la base source explosent lors de l’alimentation dans le datawarehouse contraint à mort. Un délice à débugger... à distance sans accès à la base. Je sens que 50% de mon temps va partir en fumée à cause de ce problème.