Nieuwe applicaties worden vaak naïef ontwikkeld. De ontwikkelaars willen de gewenste functionaliteit zo graag leveren dat een paar elementen die ook belangrijk zijn worden vergeten. Achteraf moeten die dan met pijn en moeite worden rechtgezet.
Meestal lukt het nog wel om het importeren van data in de applicatie goed te regelen. Iedereen wil immers snel zijn mooie nieuwe applicatie in gebruik nemen. Maar is de export ook geregeld zodat er ooit een upgrade gedaan kan worden van een live-systeem? Kan je bijvoorbeeld van een content management systeem alle artikelen exporteren, ook degene die pas volgende week gepubliceerd mogen worden? En kan de applicatie ook gemakkelijk business informatie opleveren zoals het aantal van dat soort artikelen?
In de security-specificatie staat wat de applicatie vooral moet weigeren te bieden als functie. Deze eisen zijn verschillend voor internet- en intranet-omgevingen. En wie vergeet om te beschrijven waar de gebruikersgegevens vandaan gehaald moeten worden kan ‘single-sign' on wel vergeten.
Applicaties moeten ook passen in de beheerprocessen van de productieomgeving. Het is wel zo handig dat de rapportages en statusinformatie van de applicatie te zien zijn via de tools die de beheerorganisatie al heeft. Zo kan men businessvolumes koppelen aan capaciteit en beschikbaarheid.
Verder vergeten we nog wel eens de bouwers uit te leggen hoeveel gebruikers de applicatie gaat krijgen. Als je daar van te voren niet over nadenkt, krijg je een systeem dat op een ongelukkige dag door zijn grenzen groeit, of zelfs vanaf dag 1 al niet presteert. Ook al werkt het prima in het 'lan' van de ontwikkelaars, eenmaal op het landelijke netwerk van de gebruikers blijkt het niet vooruit te branden. En als die prestaties afhankelijk zijn van achterliggende bronnen is het misschien wel zo handig om daar vanuit de applicatie over te rapporteren, direct aan de beheertools.
De meeste van deze problemen zijn te voorkomen, als je er maar op tijd aan denkt, en van meet af aan meenemt in het programma van eisen.
Helemaal waar, maar als ontwikkelaar van een applicatie kijk ik er anders tegenaan:
1) als ik geen gebruikers krijg, waarom dan nu al al die moeite?
2) veel dingen beginnen klein – in mijn geval doe ik alles alleen. Ik WEET gewoon niet wat ik allemaal nog tegen zal komen. Tijd en geld om anderen te raadplegen heb ik ook niet.
Kortom, ik blijf voorlopig sleutelen. En dat sommige dingen achteraf lastig in te passen zijn, dat zij dan maar zo.
Zoals John Gall het zo treffend omschrijft:
“A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.”
Als je alles van te voren uitkauwt is het vaak te complex om het in 1 keer te maken. Hoeveel gebruikers een systeem heeft kan wel worden geschat, maar moet blijken uit de praktijk, iets wat gebeurt als bijv. twee banken ineens gaan fuseren.
Een beetje ontwikkelaar (architect of niet) weet de algemene zaken die voor alle applicaties gelden generiek en schaalbaar te maken.
Maar ook het voorbeeld Export is prima iets wat je aan de start nog niet wilt ontwikkelen, ook omdat je vaak niet eens weet wat de behoefte is (vaak weet de klant het zelfs niet!). Teveel denken en schrijven aan het begin kan de nekslag zijn om iets van de grond te krijgen. Je moet ineens consensus krijgen en als iets de vaart eruit haalt.
Om nog even door te zagen: Evolutie is een belangrijk aspect. Soms wordt iets gemaakt met het inzicht van dat moment, maar groeit het in de praktijk naar iets anders toe.
Als het om bedrijfsapplicaties gaat dan is het belangrijk om te kijken naar hoe de processen (in de praktijk!) werken en dat als leidraad te houden. Software maken om een bedrijfsverandering door te voeren is in mijn inzicht geen goed plan.
Zo, dat zijn mijn centen 🙂
Het komt er kort op neer dat ik het niet echt met je eens ben. Het programma van eisen is wel belangrijk zolang je er maar niet teveel in vastlegt. We zijn immers mensen en als het te veel wordt dan treed bureaucratie op. Hoe groter en duurder het project, hoe groter de kans dat het een fiasco wordt.
Naieve applicaties of navieve kijk?
Er wordt een interessante stelling geponeerd in het artikeltje van van Eijk: schijnbaar worden er tijdens het ontwikkelen van applicaties nogal wat requirements vergeten te implementeren. Dat is natuurlijk een niet onbekend verschijnsel. Maar het moet gezegd worden: meestal is het een kwestie van tijd en budget, en wordt ervoor gekozen niet alle MOGELIJKE requirements te implementeren. Dat heeft mijns inziens weinig met naiviteit te maken, maar met prioriteit.
Daarnaast wordt er door van Eijk gewezen naar de ontwikkelaars die de “de gewenste functionaliteit zo graag willen leveren dat een paar elementen die ook belangrijk zijn worden vergeten.” Interessant. Het gaat dus schijnbaar niet over naieve applicaties, maar om naieve ontwikkelaars. En in dat kader ben ik heel benieuwd naar de generalisatie “ontwikkelaars” die hier wordt gebruikt. Bedoelt de auteur hier de arme zielen die de daadwerkelijke code schrijven, of naar de hele organisatie die het project uitvoert; projectmanager, analisten, architecturen, ontwerpers, programmeurs, testers? En niet te vergeten: klant en gebruikers?
Wie is er nu eigenlijk naief?