I’ve seen the vision … it is a tool!
16/08/17 00:42
Het kerkhof ligt vol met onmisbare tools
Ik hoor een aloude discussie. De Commodore 64 was immers ook vele malen beter dan de ZX Spectrum. En OS/2 was beter dan Windos. En Tokenring was trouwens ook veel beter dan Ethernet, Appletalk was beter dan IP. Appletalk was beter dan alles. Netscape was de beste browser, en lange tijd ook de enige. WordPerfect was weer veel beter dan MS Word. Visicalc was het beste sprijdblad, Excel was niet eens nodig. Ventura was écht vele malen beter dan Pagemaker. Modula2 was beter dan Pascal en Miranda was beter dan beide.
Hadden we het toen dan fout?
Kennen we al die tools nog? De meeste zijn allang weer verdwenen. Hadden we het toen fout? Niet helemaal. Sommige tools zijn nu eenmaal beter dan andere. Azure is gewoon beter dan Amazon. Het gaat pas fout als we niet inzien dat zo’n situatie nooit blijvend is. Tools worden opgevolgd door andere, nieuwere tools. Dat geldt ook voor de betere. Heel veel tools waar we ooit gek op waren zijn dan ook allang weer verdwenen; de meeste van die merknamen kennen we niet eens meer. Wie zegt dat dat niet gaat gelden in de toekomst voor <… vul maar een tool in …>?
Niet verliefd worden dus.
En het gaat steeds sneller. En het worden er steeds meer. Dat maakt het onverstandig om afhankelijk te zijn van een bepaalde tool (of bepaalde tools, want we hebben er hier wel een paar). Maak je onafhankelijk van de snelheid van ontwikkelingen, zeker omdat die steeds meer door de markt worden bepaald. En stel de vraag: hoeveel investeer je nog in een bepaalde technische oplossing als je weet dat de terugverdientijd kort is? Wees bereid om de scheiding in gang te zetten. En bereid je er alvast op voor.
En als het dan niet matcht?
Applicaties zijn ook tools, net als infra oplossingen; het verschil wordt wellicht steeds kleiner. Als dan blijkt dat je héél hard moet timmeren om dingen aan de praat te krijgen, om ze op elkaar te passen dus, dan zou de bovenstaande vraag moeten rijzen: hoeveel investeer je daarin? Gaan we timmeren? En gaan we dan het één aanpassen, of het ander? Of wordt het een exception (waarmee we de huidige wereld eigenlijk in stand houden)? Of nemen we tóch afscheid? En geldt dat dan voor de applicatie of voor de infra?
Oude wijn in nieuwe containers
Zorg ervoor dat het afscheid nemen van tools veel minder pijn doet. Maak dat techniek een non-discussie wordt. Hoe? Standaardiseer niet op de producten, maar standaardiseer op de interfaces, standaardiseer op de onderlinge interactie. Als we ons niet focussen op tools, maar op de onderliggende samenwerking ervan, dan doet afscheid nemen minder pijn. Het leidt tot loose-coupling. Dat klinkt als oude wijn in nieuwe containers en dat is het ook. Ik heb het dan trouwens niet over de containers die wij gebruiken om onze oude wijn in op te slaan. Want die oude wijn moeten we dus allang weggooien.
En wat is dan loose-coupling?
Loose-coupling. Weer zo’n kreet die we al vaker hebben gezien, maar die lastig lijkt te definieren. Maar ook zonder definitie, loose-coupling is best makkelijk meetbaar. Er is namelijk een relatie te leggen tussen loose-coupling en stabiliteit, waarbij stabiliteit kan worden gezien als “de mate van weerbaarheid tegen de versterking van changes”. En dan zijn we weer waar het hier om gaat: stabiliteit zegt namelijk iets over hoe groot de impact is van een wijziging in de omgeving. Is de impact klein, dan kost het dus weinig moeite om afscheid te nemen van (verouderde) tools.
Snelle ontwikkelingen worden dan juist een kans
Een stabiele omgeving betekent dat je snel kunt wijzigen, je kunt dan niet alleen snel tools en technieken introduceren, maar ze ook met kleine moeite snel weer weggooien. En als we al rekening houden met het zo klein mogelijk houden van de impact van het weggooien, nog vóórdat we gaan implementeren… wanneer we dát kunnen, dan kunnen al de snelle externe ontwikkelingen ons juist kansen bieden.
Richard Bliek
[1] Pfleeger,S. L., Bohner, S., et al. (1990). A framework for software maintenance metrics. In Software maintenance, 1990, proceedings., conference on (pp. 320-327).
Ik hoor een aloude discussie. De Commodore 64 was immers ook vele malen beter dan de ZX Spectrum. En OS/2 was beter dan Windos. En Tokenring was trouwens ook veel beter dan Ethernet, Appletalk was beter dan IP. Appletalk was beter dan alles. Netscape was de beste browser, en lange tijd ook de enige. WordPerfect was weer veel beter dan MS Word. Visicalc was het beste sprijdblad, Excel was niet eens nodig. Ventura was écht vele malen beter dan Pagemaker. Modula2 was beter dan Pascal en Miranda was beter dan beide.
Hadden we het toen dan fout?
Kennen we al die tools nog? De meeste zijn allang weer verdwenen. Hadden we het toen fout? Niet helemaal. Sommige tools zijn nu eenmaal beter dan andere. Azure is gewoon beter dan Amazon. Het gaat pas fout als we niet inzien dat zo’n situatie nooit blijvend is. Tools worden opgevolgd door andere, nieuwere tools. Dat geldt ook voor de betere. Heel veel tools waar we ooit gek op waren zijn dan ook allang weer verdwenen; de meeste van die merknamen kennen we niet eens meer. Wie zegt dat dat niet gaat gelden in de toekomst voor <… vul maar een tool in …>?
Niet verliefd worden dus.
En het gaat steeds sneller. En het worden er steeds meer. Dat maakt het onverstandig om afhankelijk te zijn van een bepaalde tool (of bepaalde tools, want we hebben er hier wel een paar). Maak je onafhankelijk van de snelheid van ontwikkelingen, zeker omdat die steeds meer door de markt worden bepaald. En stel de vraag: hoeveel investeer je nog in een bepaalde technische oplossing als je weet dat de terugverdientijd kort is? Wees bereid om de scheiding in gang te zetten. En bereid je er alvast op voor.
En als het dan niet matcht?
Applicaties zijn ook tools, net als infra oplossingen; het verschil wordt wellicht steeds kleiner. Als dan blijkt dat je héél hard moet timmeren om dingen aan de praat te krijgen, om ze op elkaar te passen dus, dan zou de bovenstaande vraag moeten rijzen: hoeveel investeer je daarin? Gaan we timmeren? En gaan we dan het één aanpassen, of het ander? Of wordt het een exception (waarmee we de huidige wereld eigenlijk in stand houden)? Of nemen we tóch afscheid? En geldt dat dan voor de applicatie of voor de infra?
Oude wijn in nieuwe containers
Zorg ervoor dat het afscheid nemen van tools veel minder pijn doet. Maak dat techniek een non-discussie wordt. Hoe? Standaardiseer niet op de producten, maar standaardiseer op de interfaces, standaardiseer op de onderlinge interactie. Als we ons niet focussen op tools, maar op de onderliggende samenwerking ervan, dan doet afscheid nemen minder pijn. Het leidt tot loose-coupling. Dat klinkt als oude wijn in nieuwe containers en dat is het ook. Ik heb het dan trouwens niet over de containers die wij gebruiken om onze oude wijn in op te slaan. Want die oude wijn moeten we dus allang weggooien.
En wat is dan loose-coupling?
Loose-coupling. Weer zo’n kreet die we al vaker hebben gezien, maar die lastig lijkt te definieren. Maar ook zonder definitie, loose-coupling is best makkelijk meetbaar. Er is namelijk een relatie te leggen tussen loose-coupling en stabiliteit, waarbij stabiliteit kan worden gezien als “de mate van weerbaarheid tegen de versterking van changes”. En dan zijn we weer waar het hier om gaat: stabiliteit zegt namelijk iets over hoe groot de impact is van een wijziging in de omgeving. Is de impact klein, dan kost het dus weinig moeite om afscheid te nemen van (verouderde) tools.
Snelle ontwikkelingen worden dan juist een kans
Een stabiele omgeving betekent dat je snel kunt wijzigen, je kunt dan niet alleen snel tools en technieken introduceren, maar ze ook met kleine moeite snel weer weggooien. En als we al rekening houden met het zo klein mogelijk houden van de impact van het weggooien, nog vóórdat we gaan implementeren… wanneer we dát kunnen, dan kunnen al de snelle externe ontwikkelingen ons juist kansen bieden.
Richard Bliek
[1] Pfleeger,S. L., Bohner, S., et al. (1990). A framework for software maintenance metrics. In Software maintenance, 1990, proceedings., conference on (pp. 320-327).