>_ Software

Eerst begrijpen. Dan bouwen.

Ik vind software interessant.

Niet omdat ik graag de rest van mijn leven applicaties wil bouwen, hosten en onderhouden. En ook niet omdat elk probleem volgens mij opgelost moet worden met nóg een systeem.

Wat ik vooral interessant vind is deze vraag:

Wat zou er mogelijk zijn als we dit nou eens goed maken?

En dan begint mijn softwareverhaal eigenlijk niet bij software.

Het begint bij data.

Wat bedoelen we eigenlijk?

Voordat je nadenkt over schermen, knoppen, databases of welk pakket je moet kiezen, wil ik eerst begrijpen hoe de wereld achter de vraag eruitziet.

Wat is bijvoorbeeld een klant? Een product? Een bestelling? Een project? Welke dingen horen bij elkaar? Welke begrippen gebruiken mensen door elkaar terwijl ze eigenlijk iets anders bedoelen?

Dat klinkt misschien theoretisch.

Maar als je die vragen aan het begin overslaat, bouw je die onduidelijkheid uiteindelijk gewoon in je software.

Daarom begin ik graag conceptueel en semantisch.

Eerst samen begrijpen wat we bedoelen.

Daarna wordt software ineens een stuk eenvoudiger.

Van model naar prototype.

Ik heb zelf genoeg aan software zitten vrutten om niet bang te worden van de techniek. Scripts, databases, API's, integraties en kleine applicaties: ik vind het leuk om te ontdekken hoe de onderdelen in elkaar grijpen.

En de komst van AI maakt dat experimenteren alleen maar interessanter.

Een idee hoeft niet meer wekenlang op papier te blijven staan voordat je kunt ontdekken of het werkt. Soms kun je al vrij snel een prototype bouwen.

Niet meteen dé applicatie.

Wel iets waar je op kunt klikken.

Iets waarmee je kunt ontdekken of het proces logisch is. Of het datamodel klopt. Of gebruikers begrijpen wat je bedacht hebt. En vooral: of we eigenlijk wel het juiste probleem aan het oplossen zijn.

Een prototype maakt een gesprek concreet.

Niet alles hoeft een IT-project te worden.

Dat vind ik vooral interessant voor organisaties die niet beschikken over een enorm IT-landschap of een eigen ontwikkelafdeling.

Soms heb je een probleem dat te specifiek is voor een standaardpakket, maar te klein om er onmiddellijk een groot softwareproject van te maken.

Dan wil ik eerst onderzoeken:

Kunnen we het slimmer oplossen?

Kunnen bestaande onderdelen met elkaar praten?

Kunnen we iets kleins maken dat het idee bewijst?

Of ontdekken we tijdens het prototypen juist dat we helemaal geen nieuwe software nodig hebben?

Dat laatste vind ik ook een prima uitkomst.

Software als gereedschap.

Misschien is dat uiteindelijk hoe ik ernaar kijk.

Software is geen doel.

Het is gereedschap waarmee je een goed begrepen probleem kunt vertalen naar iets dat werkt.

Dus niet beginnen met:

Welke software zullen we bouwen?

Maar met:

Wat proberen we eigenlijk mogelijk te maken?

Als we dát goed begrijpen, kunnen we daarna altijd nog besluiten waarmee we het maken.

Ik vind deze pagina belangrijk voor je positionering, juist omdat hij voorkomt dat "ik kan programmeren" de boodschap wordt.

De boodschap is eerder:

Theo kan voldoende de techniek in om een idee tastbaar te maken, maar houdt voldoende afstand om zich eerst af te vragen of we wel het juiste bouwen.

Dat sluit ook erg mooi aan op Consultancy. Daar vertaal je tussen business en IT. Hier laat je zien dat je desnoods ook een werkend prototype kunt gebruiken als vertaling.

En ik zou je huidige tegeltekst "Met de data als start, handige software" aanscherpen naar bijvoorbeeld:

>_ Software

Eerst begrijpen. Dan bouwen.

of, iets speelser:

>_ Software

Eerst snappen wat het moet doen.

Die tweede vind ik eigenlijk het meest Maak 't nou!.