Striktheid

Veel werk in de IT branche wordt veroorzaakt door systemen en organisaties die niet strikt zijn. Ik denk aan kpi-berekeningen waar met de waarde 0 gerekend wordt als er brondata ontbreekt. Ik denk aan systemen waarin time zone en DST informatie niet meegenomen wordt als er met timestamps gerekend wordt. Ik denk aan organisaties die zich niet houden aan de eigen IT richtlijnen als het gaat om het publiceren van data.

Vaak wordt striktheid als iets lastigs beschouwd. Mensen denken dat het erg veel moeite kost om systemen en processen strikt te maken. En als er dan ‘even’ iets ‘snel’ ‘tijdelijks’ gemaakt moet worden, dan wordt de moeite niet genomen om zaken netjes en volgens de regels te doen.

Totdat het systeem of proces toch minder tijdelijk blijkt dan gedacht. En dat er verder gebouwd wordt op de ‘tijdelijke’ oplossing. Dan blijkt plotseling dat een kleine aanpassing erg veel tijd kost. Of onverwachte effecten heeft.

Net als in de bouw, is het verstandig wat meer tijd te nemen voor het leggen van een goede fundering. Als die eenmaal goed is, kan er op een efficiënte wijze verder gebouwd worden. Dit vergt wel engineers met kennis van zaken. En met enige overtuigingskracht, aangezien niet iedereen begrip heeft voor de extra tijd die bij het begin nodig is om zaken goed op te zetten.

Zaken als case sensitivity, vastleggen van data typen, valideren van input, incorrecte invoer behandelen middels exceptions zijn van belang.

Uiteindelijk besparen strikte systemen en processen veel geld. Dit omdat de bijbehorende documentatie makkelijker te onderhouden is, het systeem makkelijker uit te breiden is en omdat engineers sneller kunnen begrijpen hoe het systeem werkt.

Een andere prettige bijkomstigheid is dat striktheid vaak de bron van fouten blootlegt. Vervolgens kan die aangepakt worden, wat tot een algehele verbetering leidt van systemen en processen.

Dit bericht is geplaatst in IT, Nieuws. Bookmark de permalink.