Eerlijk? Software (laten) maken is ook moeilijk!

Je bent verantwoordelijk voor een afdeling, misschien zelfs een heel bedrijf. Je moet een moeilijke beslissing nemen. Maar als het zwaard van Damocles bungelt die boven je hoofd. Een beslissing die alles een stuk makkelijker gaat maken. Of die je van een hoge klif laat storten! Wat is de juiste keuze? Moeilijk, moeilijk, moeilijk! Want de keuze moet nu genomen worden. En dan word je, badend in het zweet, wakker.

Bevrijd uit de nachtmerrie dringt het besef door. Het besef dat het niet de beste beslissing is om in één keer het diepe in te springen. Dat het kleiner aanpakken beter werkt. Stap voor stap de trap af het diepe water in. En ineens is die grote sprong een stuk makkelijker, veiliger en veel minder eng. Voor het ontwikkelen (zelfs het goed gebruiken) van software geldt precies hetzelfde. Door kleine stapjes te nemen, wordt het eindresultaat niet minder moeilijk. Wat het wel doet, is dat de software(ontwikkeling) behapbaar, overzichtelijk en uiteindelijk beheersbaar maakt!

Eerlijk? Software is ook moeilijk!

Veel mensen die computerprogramma's gebruiken zullen het bevestigen: software is soms best moeilijk. Van de mensen die eigen applicaties (laten) maken zullen nog meer mensen zeggen: software is moeilijk! Softwareontwikkeling kan zelfs als het zwaard van Damocles zijn. Enerzijds biedt software mogelijkheden die gemak, waarde of plezier opleveren. De keerzijde is dat software een dure aangelegenheid kan zijn en uiteindelijk niet oplevert wat ervan verwacht wordt.

Dat brengt ons bij het stuk waar wij softwareontwikkelaars eerlijk moeten zijn. De meeste softwareontwikkelaars en -verkopers willen graag zeggen dat het niet zo is, maar we kunnen niet om de hete brei heen draaien: Software is ook moeilijk. Gelukkig kunnen we softwareontwikkeling wel (beter) beheersbaar maken. Om dat te bereiken is niets belangrijker dan samenwerking. Of in de woorden van onze nationale wijze Loesje: “waarom moeilijk doen als het samen kan?”

Software maken is samenwerken

Voor echt goede software is samenwerking tussen softwaremaker en software gebruiker essentieel. Als je goede software wilt hebben, kan je (helaas) niet zomaar een ‘setje wensen’ bij een softwaremaker over de schutting gooien. Doe je dat wel, dan loop je een groot risico dat je niet krijgt wat je nodig hebt. Vergelijk het met James Bond die een mooi pak koopt bij de kleermaker. Als hij niet met de kleermaker zou overleggen, zou James nooit het op hem afgestemde, ideale ‘spionnenpak’ krijgen. Het pak is net te klein of te groot, krijgt hij alleen een jasje maar ontbreekt het gilet, of is de stof niet kogelwerend en is er geen ruimte voor zijn pistool. Kortom, net niet wat nodig was.

In tegenstelling tot wat veel mensen denken, is software maken een ambacht. Onder de hightech uitstraling zitten vele uren handwerk.

Hetzelfde geldt voor het maken van software. Want in tegenstelling tot wat veel mensen denken, is software maken een ambacht. Onder de hightech uitstraling zitten vele uren handwerk. Arbeid van knappe koppen die, samen met jou, ervoor zorgen dat jij een fijn programma krijgt. Het liefst een programma waar je blij van wordt. Of op zijn minst een programma dat jouw werk makkelijker, prettiger en veiliger maakt. Maar hoe moet je dat aanpakken?

Een moeilijk proces

Het is niet eens zo lang geleden dat ‘lineaire softwareontwikkeling’ de standaard in de IT  was. Zie het als een soort ganzenbord waarbij je iedere beurt een paar stappen verder mag, maar nooit een stap terug mag doen. In de IT noemen we dit ‘waterval-ontwikkeling’, omdat het proces net als water in een waterval is: de enige richting de volgende trede in de waterval:

1. Je begint met een idee of probleem;
2. Uit het idee of probleem volgt een lijst met eisen;
3. Er wordt een gedetailleerde bouwtekening (ontwerp) gemaakt waarin alles staat;
4. Je geeft de bouwtekening aan een softwaremaker die gaat bouwen en….
5. Na verloop van tijd krijg je software terug.

Helaas is het niet (meer) zo simpel…

Als je puur naar het 'papieren proces’ kijkt, dan kan je denken dat de waterval het perfecte ontwikkelproces is. Het is een heel logisch proces met duidelijke fasen, taken en rollen. De volgorde is vanaf het begin duidelijk: je gaat pas naar de volgende stap als alle eerdere stappen klaar zijn. Dat overzicht geeft het gevoel van houvast, maar verbergt de grote zwakte van de waterval: onvoorspelbaarheid.

Het eerlijke antwoord is dat wij als software-industrie geleerd hebben dat: software veel te complex is geworden om vooraf helemaal uit te schrijven. Dat wensen en eisen tijdens het maken van software veranderen. Kortom, dat aan het einde ‘iets anders nodig bleek’ dan er aan het begin bedacht was. Kortom, onvoorspelbaarheid die je in de watervalmethode niet kan opvangen. Vooraf is alles al uitgedacht waardoor er geen flexibiliteit is om veranderingen op te vangen en samen aan de beste oplossing te werken.

Dagdromen van eenvoud

In tegenstelling tot de 'blauwe brievendienst' moeten softwaremensen durven te zeggen: “leuker kunnen we het maken, ook makkelijker”. Want te vaak zien we dat software (laten) maken tot frustraties leidt. Maar wat moet daarvoor gebeuren?

1. Samenwerken: Softwaremakers snappen niet al jouw wensen en eisen als ‘totaalpakket’. Wat ze wel snappen zijn de losse wensen, die kunnen ze heel goed bouwen. Anderzijds kunnen wij softwaremakers dingen soms ‘te moeilijk’ uitleggen. Vul elkaars ‘kennis en ervaring’ aan en zorg dat je elkaar begrijpt! Elkaar aanvullen is veel leuker dan elkaar dingen verwijten.
2. Kleine stapjes: Het totaalpakket hierboven is vaak moeilijk te overzien. Niet alleen voor ontwikkelaars, soms kan een project zo groot zijn dat je het zelf niet meer overziet. Door het totaalpakket op te knippen, en als losse ‘mini projectjes’ te zien wordt het ineens overzichtelijker. Kleine stukjes zijn ook makkelijker te bouwen. En omdat je steeds kleine stukjes software in gebruik kan nemen, zie je constant vooruitgang: veel leuker dan maanden of jaren zitten wachten!
3. Kritische betrokkenheid: Om tot een mooi resultaat te komen, is betrokkenheid van alle partijen (van bouwers, via opdrachtgever tot gebruikers) essentieel. Kijk kritisch naar wat er gebouwd is, wat er gebouwd wordt en nog gaat komen. Sta open voor opmerkingen vanaf de werkvloer, en denk met elkaar mee! Want als je steeds een klein stapje zet, kan je na iedere stap kritisch kijken wat echt nodig is, wat echt belangrijk is en zelfs of iets niet (meer) nodig is!
4. Gebruik je software: Het klinkt als een inkoppertje, maar wees niet bang om jouw software al tijdens de bouw te gebruiken. Misschien zijn nog niet al jouw gedroomde functies gebouwd. Maar vaak is jouw programma al heel goed bruikbaar. Zie het als een nieuwe woonwijk waar de eerste huizen al bewoond zijn. Gelijktijdig zijn niet alle straten ‘bestraat’. De supermarkt zit nog niet in de wijk en de school zit in tijdelijke lokalen. Maar de mensen die er wonen, wonen er meestal gelukkig. Uiteindelijk worden ook die ‘features’ gerealiseerd en is de wijk (of in ons geval software product) klaar. En in de tussentijd kan je geleerde lessen toepassen zodat het eindresultaat nog beter is!

De bovenstaande vier punten zijn de basis van “Agile” ontwikkelen. Goede kans dat je al van Agile gehoord hebt: de meeste softwaremakers werken op een Agile manier. Als jij een goede softwarepartner hebt, helpt hij je om de vier punten in de gaten te houden. Hij zal je aanmoedigen om kritisch te zijn. Met zijn kennis en ervaring helpen met de planning van de (kleine) stapjes. En hij zal je af en toe lastig vallen om te begrijpen waarom jij bepaalde vragen hebt, of wat het doel van de feature is. Want uiteindelijk moet software (laten) maken, overzichtelijk, makkelijk(er) en zelfs leuk zijn. Zodat software (laten) maken niet als 'een sprong in het diepe' voelt, maar dat je rust hebt terwijl jouw programma stap voor stap en beetje bij beetje beter wordt.