Java versus .NET
Java versus .NET
“Kiezen we voor Java of voor Microsoft .NET?” Deze vraag was jarenlang stof voor discussies waarin zowel praktische als haast religieuze argumenten heen en weer vlogen. De voorbije jaren wordt deze discussie minder fanatiek gevoerd. Enerzijds heeft .NET heel wat aan stabiliteit gewonnen, anderzijds beseffen aanhangers van beide ontwikkelomgevingen dat de andere omgeving nog vele jaren zal meegaan.
De vraag heeft dan ook plaats gemaakt voor een andere vraag: “Kiezen we ervoor om de twee platformen te ondersteunen, of opteren we toch voor een van beide omgevingen?” Smals, gespecialiseerd in ICT-diensten voor de publieke sector, heeft alvast voor de laatste optie gekozen: zij gebruiken zoveel mogelijk Java, al was het maar omdat ze intussen al zoveel extra’s voor die taal ontwikkeld hebben dat het zonde zou zijn om die niet zoveel mogelijk te gebruiken. Maar er zijn nog andere redenen om voor één omgeving te kiezen, vindt Guy Van Hooveld, bij Smals verantwoordelijk voor ontwikkeling en projectbeheer: “Bedrijven willen ook voor ICT zoveel mogelijk voorspelbaarheid en betrouwbaarheid. Door voor één platform te kiezen, kan dit veel beter gegarandeerd worden. En dan is er natuurlijk nog het aspect van de totaalkost: wij ontwikkelen niet alleen de toepassingen, maar zorgen achteraf meestal ook voor het beheer en het onderhoud. Ook daarom is één standaardomgeving te verkiezen boven twee te onderhouden platforms.”
Johan Lybaert, sector manager voor de sociale en publieke sector bij Cegeka, denkt hier anders over: “Ons team, met zowat 120 ontwikkelaars, is groot genoeg om de twee platformen te kunnen ondersteunen, en aangezien beide platformen evenwaardig zijn, laten we de keuze aan de klant. Als de klant niet kan kiezen, zullen wij uiteindelijk beslissen in functie van de beschikbare resources.”
‘Waterfall’ versus ‘agile’
Wat versus wat? De ‘waterfall’-ontwikkelmethode is de traditionele aanpak: eerst worden alle specificaties beschreven, en vervolgens wordt alles ontwikkeld en geïmplementeerd, getest en daarna opgeleverd, alles volgens de bij aanvang beschreven specificaties. ‘Agile’ ontwikkelen werkt met veel korte cycli, waarbij alles wat ontwikkeld werd meteen door de klant getest en geëvalueerd wordt. Hierdoor kan de klant veel korter op de bal spelen wanneer er iets fout gaat. “Maar ook wanneer er niets fout gaat, is dit een goede werkwijze”, oordeelt Johan Lybaert. “Vaak weet de klant nog niet waar hij met een project naartoe wil, en door die continue feedback wordt het steeds duidelijker wat ze wel willen en wat niet. Het principe van het voortschrijdend inzicht, zeg maar.”
Toch wordt agile ontwikkelen niet door iedereen onvoorwaardelijk omarmd. Bij Smals wordt bijvoorbeeld nog heel vaak de waterfall-aanpak gehanteerd. “We passen al geregeld enkele principes van agile ontwikkelen toe, zoals de stand-up meetings en tussentijdse releases,” nuanceert Guy Van Hooveld, “maar de klanten moeten ook meewillen, hé. Volgens de agile-principes moet de klant bij elke oplevering beschikbaar zijn, en dat blijkt vaak moeilijk te realiseren.” Volgens Lybaert zou dat engagement van de klant nochtans een evidentie moeten zijn: “Hoe kan je nu tekenen met bloed voor iets waarvan je het uiteindelijke resultaat niet kan voorspellen? Geen wonder dat zoveel software ongebruikt blijft liggen.” U merkt het: ook deze strijd is nog lang niet beslecht.
En verder …
Naast de twee splijtzwammen uit het artikel zijn er nog andere zaken die de wereld van ontwikkelaars beroeren.
Zo vroeg men zich geruime tijd af wat nu de standaard zou worden voor mobiele toepassingen: Flash of HTML 5? Intussen lijkt die strijd gestreden: bijna iedereen voorspelt HTML 5 het langste leven.
Ook ontwikkelen voor de cloud wordt de komende jaren een belangrijk thema. “Het is niet zozeer dat je een nieuwe businesslogica moet bedenken,” verklaart Adrian Coyler, CTO van VMware-dochter Springsource, “maar wel dat je rekening moet houden met de typische eigenschappen van een cloud-toepassing: ze moet een grote workload aankunnen, en ze moet uitbreidbaar zijn.”
Tot slot zijn er nog thema’s die nog wel een tijdje zullen meegaan: de kwaliteit van de software en van de documentatie bij de ontwikkeling ervan, de herbruikbaarheid van softwaremodules en ontwikkeltools, en de klassieker van de voorbije jaren: hoe voldoende nieuwe werkkracht vinden in een nog steeds groeiende markt.
Java versus .NET
“Kiezen we voor Java of voor Microsoft .NET?” Deze vraag was jarenlang stof voor discussies waarin zowel praktische als haast religieuze argumenten heen en weer vlogen. De voorbije jaren wordt deze discussie minder fanatiek gevoerd. Enerzijds heeft .NET heel wat aan stabiliteit gewonnen, anderzijds beseffen aanhangers van beide ontwikkelomgevingen dat de andere omgeving nog vele jaren zal meegaan.
De vraag heeft dan ook plaats gemaakt voor een andere vraag: “Kiezen we ervoor om de twee platformen te ondersteunen, of opteren we toch voor een van beide omgevingen?” Smals, gespecialiseerd in ICT-diensten voor de publieke sector, heeft alvast voor de laatste optie gekozen: zij gebruiken zoveel mogelijk Java, al was het maar omdat ze intussen al zoveel extra’s voor die taal ontwikkeld hebben dat het zonde zou zijn om die niet zoveel mogelijk te gebruiken. Maar er zijn nog andere redenen om voor één omgeving te kiezen, vindt Guy Van Hooveld, bij Smals verantwoordelijk voor ontwikkeling en projectbeheer: “Bedrijven willen ook voor ICT zoveel mogelijk voorspelbaarheid en betrouwbaarheid. Door voor één platform te kiezen, kan dit veel beter gegarandeerd worden. En dan is er natuurlijk nog het aspect van de totaalkost: wij ontwikkelen niet alleen de toepassingen, maar zorgen achteraf meestal ook voor het beheer en het onderhoud. Ook daarom is één standaardomgeving te verkiezen boven twee te onderhouden platforms.”
Johan Lybaert, sector manager voor de sociale en publieke sector bij Cegeka, denkt hier anders over: “Ons team, met zowat 120 ontwikkelaars, is groot genoeg om de twee platformen te kunnen ondersteunen, en aangezien beide platformen evenwaardig zijn, laten we de keuze aan de klant. Als de klant niet kan kiezen, zullen wij uiteindelijk beslissen in functie van de beschikbare resources.”
‘Waterfall’ versus ‘agile’
Wat versus wat? De ‘waterfall’-ontwikkelmethode is de traditionele aanpak: eerst worden alle specificaties beschreven, en vervolgens wordt alles ontwikkeld en geïmplementeerd, getest en daarna opgeleverd, alles volgens de bij aanvang beschreven specificaties. ‘Agile’ ontwikkelen werkt met veel korte cycli, waarbij alles wat ontwikkeld werd meteen door de klant getest en geëvalueerd wordt. Hierdoor kan de klant veel korter op de bal spelen wanneer er iets fout gaat. “Maar ook wanneer er niets fout gaat, is dit een goede werkwijze”, oordeelt Johan Lybaert. “Vaak weet de klant nog niet waar hij met een project naartoe wil, en door die continue feedback wordt het steeds duidelijker wat ze wel willen en wat niet. Het principe van het voortschrijdend inzicht, zeg maar.”
Toch wordt agile ontwikkelen niet door iedereen onvoorwaardelijk omarmd. Bij Smals wordt bijvoorbeeld nog heel vaak de waterfall-aanpak gehanteerd. “We passen al geregeld enkele principes van agile ontwikkelen toe, zoals de stand-up meetings en tussentijdse releases,” nuanceert Guy Van Hooveld, “maar de klanten moeten ook meewillen, hé. Volgens de agile-principes moet de klant bij elke oplevering beschikbaar zijn, en dat blijkt vaak moeilijk te realiseren.” Volgens Lybaert zou dat engagement van de klant nochtans een evidentie moeten zijn: “Hoe kan je nu tekenen met bloed voor iets waarvan je het uiteindelijke resultaat niet kan voorspellen? Geen wonder dat zoveel software ongebruikt blijft liggen.” U merkt het: ook deze strijd is nog lang niet beslecht.
En verder …
Naast de twee splijtzwammen uit het artikel zijn er nog andere zaken die de wereld van ontwikkelaars beroeren.
Zo vroeg men zich geruime tijd af wat nu de standaard zou worden voor mobiele toepassingen: Flash of HTML 5? Intussen lijkt die strijd gestreden: bijna iedereen voorspelt HTML 5 het langste leven.
Ook ontwikkelen voor de cloud wordt de komende jaren een belangrijk thema. “Het is niet zozeer dat je een nieuwe businesslogica moet bedenken,” verklaart Adrian Coyler, CTO van VMware-dochter Springsource, “maar wel dat je rekening moet houden met de typische eigenschappen van een cloud-toepassing: ze moet een grote workload aankunnen, en ze moet uitbreidbaar zijn.”
Tot slot zijn er nog thema’s die nog wel een tijdje zullen meegaan: de kwaliteit van de software en van de documentatie bij de ontwikkeling ervan, de herbruikbaarheid van softwaremodules en ontwikkeltools, en de klassieker van de voorbije jaren: hoe voldoende nieuwe werkkracht vinden in een nog steeds groeiende markt.
