«

»

Apr
09

Creatieve destructie

Programmeurs blijken geregeld problemen te hebben met refactoring, een soort creatieve destructie. Merkwaardig is dat niet: het vernietigen van iets dat werkt en goed is lijkt inderdaad niet de meest economische aanpak en verbreekt tevens de band die de maker heeft met zijn eigen werk. Gevolg is dat de bestaande code blijft en dat er op voortgeborduurd wordt met vaak negatieve gevolgen – het eindproduct wordt slecht te onderhouden en zal mankementen gaan vertonen.
Hoe anders ligt het als toerist waar je je in een ander tijd waant als je een stad als Venetië bezoekt, waar je blij bent dat de inwoners de middelen niet meer hadden om verder te gaan met creatieve destructie. Heel lang hoeft men niet te wachten voordat de mensen waardering uitspreken voor iets ouds. Stop de creatieve destructie een 50 jaar en men spreekt lovende woorden – Cuba is een mooi voorbeeld. Hoeveel “kunstschatten” zijn er niet verloren gegaan, ook in ons eigen land, omdat het goede beter moest? Jammer, maar toch niet helemaal onlogisch.
Midden in een crisis, die we ondertussen wel als de nieuwe status quo kunnen beschouwen (immers globalisering is mondiale nivellering), zoeken we naar middelen om groei te realiseren. De beste manier is niet het oude bij het oude te laten of te proberen zieltogende bedrijven van de ondergang te redden, maar met een soort forward thinking, innovatie te stimuleren door creatieve destructie. De econoom Joseph Schumpeter stelde dit in 1942 al voor als het panacee (en daarmee bedoelde hij niet de vernietigingen die de Duitsers toentertijd uitvoerden). Stimuleer vernieuwing en zorg voor een goed aanpassingsvermogen. Creatieve destructie is juist goed voor de economie, zo luidde zijn stelling en inderdaad is innovatie een weg uit de misère.

Het denken van Joseph Schumpeter zien we terug binnen SCRUM, veranderen en vernieuwen is ook hier het adagium. Creatieve destructie is dus nog meer vereist binnen SCRUM-projecten waar er (in eerste instantie) waarde voor de product owner gecreëerd moet worden aan de hand van features. De features kunnen gezien worden als losse componenten (trek de parallel met een stad: huizen, scholen, kantoren, etc.) zonder de benodigde infrastructuur (want dat laatste heeft voor de product owner geen directe waarde). Refactoring is onontkoombaar (de huizen, kantoren en scholen moeten met elkaar verbonden worden om bereikbaar en bruikbaar te blijven). Als toerist is Venetië een geschenk, maar als inwoner niet. Wie wil daar tegenwoordig nog voor een langere tijd leven, een stad met een infrastructuur uit een ver verleden?