Als u ervaring hebt met programmeurs, zullen vertraagde projecten u niet vreemd zijn. In het begin lijkt alles goed op stoom, maar als het werk van verschillende teams moet worden samengevoegd, komt de klad er in.

Elke wijziging breekt de code op meerdere plaatsen en wat eerst gestructureerd programmeren heette, lijkt ineens een gevecht tegen vlooien. Men durft
geen datum meer voor de definitieve oplevering af te geven en als men dat toch doet, wordt die continue vooruit geschoven. Er ontstaat de spreekwoordelijke puinhoop!

Intussen worden kostbare uren verbrand en lopen de kosten hoog op.

Beheer doet het enige ding dat zij kunnen. In de hoop de productiviteit te verhogen, voegen zij meer personeel aan het project toe. Maar omdat het nieuwe personeel niet bekend is met het ontwerp van het systeem, worden wijzigingen op verkeerde plaatsen aangebracht, waardoor het originele bouwwerk nog meer wordt verstoord.

Productiviteit vs. Tijd

Grondhouding

De reden dat goede code zo snel verandert in slechte code, wordt vaak verklaard door wijzigingen van de wensen en eisen gedurende het uitvoeren van het project.

Er wordt vooral geklaagd over fouten van anderen en onnadenkende managers die toezeggingen doen waardoor de functionaliteit steeds verandert. Maar de schuld, beste mensen, moeten we bij ons zelf zoeken. Wij zijn onprofessioneel.

Voor programmeurs is dit wellicht een bittere pil om te slikken. Hoe kan een puinhoop hun schuld zijn?

De managers en marketeers zoeken bij hen naar de informatie die ze nodig hebben om anderen te informeren en afspraken over deadlines te kunnen maken.

Zodoende zijn de programmeurs medeplichtig aan de planning van het project en delen een groot deel van de verantwoordelijkheid voor eventuele fouten.

Programmeurs worden geconfronteerd met een raadsel van fundamentele waarden. Alle ontwikkelaars met meer dan een paar jaar ervaring weten dat halve oplossingen alleen maar vertragen.

Het is als een patiënt die aan de chirurg vraagt, om het handenwassen dit keer maar over te slaan. Daarom nemen ontwikkelaars, onder druk om deadlines te halen, niet de tijd om snel te gaan. Want de enige manier om snel te gaan, is door de code altijd zo schoon mogelijk te houden. Echte professionals weten dat.

Gelukkig willen de meeste managers de waarheid, zelfs wanneer het slecht nieuws is. Ook willen zij goede code, zelfs wanneer zij het project snel willen afronden.

De kunst van schone Code

Het schrijven van schone code vereist gedisciplineerd gebruik van talloze kleine technieken.

Het “code-gevoel” is de sleutel. Sommige van ons zijn er mee geboren, maar de meesten hebben moeten vechten om het te verwerven.

Een programmeur zonder “code-gevoel” ziet wel dat bepaalde code slecht is, maar heeft geen idee wat daar aan gedaan kan worden.

Bjarne Stroustrup, de uitvinder van de bekende programmeertaal C++ zegt hierover het volgende:

I like my code to be elegant and efficient. The logic should be straightforward to make it hard for bugs to hide, the dependencies minimal to ease maintenance, error handling complete according to an articulated strategy, and performance close to optimal so as not to tempt people to make the code messy with unprincipled optimizations. Clean code does one thing well.

Bjarne gebruikt het woord “elegant”. Dat is nogal een woord! Het woordenboek in Wiki geeft de volgende definitie: een prettige uitstraling hebbend door de subtiele afwerking.

Ter afsluiting

Schone code is een belangrijk onderdeel om professioneel te werken. Om projecten te laten slagen, moet de wil om alleen schone code te produceren een grondhouding zijn. Automatiseringspijn kan vermeden worden.

In een volgende blog zal ik ingaan op de wijze waarop we een automatiseringsproject structuur kunnen geven, waardoor we niet alleen de dingen goed doen, maar vooral ook de goede dingen doen.