Binnen de testwereld van Nederland is TMap een veelgebruikte methodiek om te testen. TMap heeft als doel om het testen gestructureerder te laten plaatsvinden. Hiervoor biedt het middelen om het testen een plaats te geven in het software ontwikkel proces en daarnaast middelen om het testen op zich te verbeteren. Maar wat heb je nou aan TMap als je niet test? En kan TMap ook problemen geven? Om deze vragen te beantwoorden, zal ik twee basisprincipes van TMap bespreken, waar ik ook het effect voor developers zal noemen.
Lees verder »

Of drie principes voor betere gebruiksvriendelijkheid

Ik heb een magnetron thuis. Werkelijk een prachtig ding. Ik gebruik hem om mijn kip te ontdooien/per ongeluk te koken. Soms warm ik er een kliekje in op. En heel af en toe maak ik er diepvriesspinazie in warm. Om dat allemaal mogelijk te maken heeft mijn magnetron 21 knoppen! En een tweeëntwintigste om het deurtje te openen. Ik gebruik er zeven. Het lijkt wel of ik de ‘maximale potentie van mijn magnetron’ niet benut.
Lees verder »

Ze bestaan al een paar jaar, en je ziet ze steeds vaker terugkomen. Fluent interfaces, ook wel interne DSL genoemd. Toch zie ik de techniek in de praktijk eigenlijk alleen worden gebruikt in frameworks. Jammer, want deze techniek kan eenvoudig worden toegepast om goed leesbare en op het domein toegespitste code te schrijven.
Lees verder »

Small steps by mankind

Rond de kerst mocht ik weer genieten van de The Royal Institution of Great Britain Christmas Lectures. Dit keer niet de meest recente versie maar de naar grote waarschijnlijkheid zeker niet minder interessante ‘Growing Up in the Universe’ lectures door Richard Dawkins, zoals uitgezonden door de BBC in 1991. Voor dit verhaal verder niet zo bijster relevant, behalve dan dat verschillende aspecten van evolutie worden behandeld. Daarnaast bevatte de aftiteling van de lectures een verwijzing naar wat eigenlijk wel een kleine revolutie mag worden genoemd. Of beter; juist de afwezigheid ervan; in 1991, een goede 15 jaar geleden, had de BBC nog geen website.

Als het gaat om evolutie of revolutie vinden veranderingen in ons vakgebied meestal op een evolutionele manier plaats. Hoewel vaak met de mond beleden is er niet vaak sprake van een echte revolutie.

Lees verder »

Grote uitdagingen binnen software ontwikkeltrajecten zijn het binnen het budget blijven en het opleveren van een product dat voldoet aan de wens van de klant.
Softwareprojecten worden vaak aangeboden volgens het fixed price/fixed date principe. Als projectaanpak wordt vaak gekozen voor de watervalmethode [Waterfall]. Deze methode is vergelijkbaar met het bouwen van huizen. Eerst maak je een volledig afgebakend plan, vervolgens bouw je exact volgens de specificatie. Echter, in de jaren ‘80 werd al gezegd dat de vaak gemaakte vergelijking tussen het bouwen van huizen en het bouwen van software niet opgaat. Toch houden wij, de IT-leveranciers, samen met onze klanten deze illusie in stand door projecten aan te bieden volgens een watervalmodel met een vaste projectprijs en vast oplevermoment.
Omdat het model niet goed matcht met de software ontwikkeling leidt dit tot irritaties bij zowel de klant als de leverancier.

In dit artikel ga ik in op andere manieren om software ontwikkeling aan te pakken.

Lees verder »

Migratie van oorspronkelijke data naar een nieuw CMS zou vroeg in het bouwproces moeten worden uitgevoerd om risico’s te verminderen. Tijdens elke herhaling van het project zou de migratie tool moeten worden verbeterd om de laatste kennis van zowel de oorspronkelijke omgeving als het nieuwe CMS te weerspiegelen.