Recent werd ik gevraagd een onderzoeksrapport te reviewen. Het rapport beschreef de knelputen van de BI aanpak van een grote organisatie. Ik ken de klant goed, en had de indruk dat het rapport goed beschreef wat er allemaal beter kon. Een aspect viel me echter op. Men had gekozen voor een waterval-achtige ontwikkelmethode. Specs moeten volledig afgetimmerd zijn, alvorens men gaat bouwen. In sommige situaties kan dit een uitstekende methode zijn. In mijn ogen is deze echter voor BI ongeschikt. Mijn ervaring is dat de in kaart gebrachte informatiebehoefte nog behoorlijk kan schuiven na het beschikbaar komen van echte informatie. In je projectopzet moet je hier dan ook altijd rekening mee houden. Ik gebruik daar altijd prototyping voor op basis van echte data. Keer op keer zie ik weer gebeuren dat in workshops met deze prototypes gebruikers steeds iets anders blijken te willen dat eerst het geval is. Zonder dit middel zouden projecten gierend uit de hand lopen, of zouden de gebruikers iets krijgen waar ze niet zoveel aan hebben.

Mijn eerste computer was een Apple IIe. Al snel had ik in het Basic-dialect wat daarop draaide een rudimentair opslag-systeem gebouwd om gegevens over mijn singletjes-collectie op te slaan. Ik kon mijn eigen Top 10 uitdraaien, bijhouden hoeveel nummers ik van bepaalde artiesten had, en nog veel meer. Na verloop van tijd werd de Apple vervangen door een MSX2 computer, en ik zat met de vraag hoe ik kon voorkomen dat ik al mijn bloedig ingevoerde singletjes opnieuw moest invoeren. De Apple had 5,25 inch diskdrives, terwijl de MSX er eentje van 3,5 inch had.
Uiteindelijk slaagden we er in om de singeltjes als Basiccode (zoek die maar op) op een cassettebandje te zetten (de Apple had een audio-uitgang). Op de MSX konden we met hulp van enige blokken machinetaal de informatie op het cassettebandje weer omzetten naar een tekstfile om vervolgens weer te gebruiken.