Software is voor vele opdrachtgevers een black box. Je hebt als opdrachtgever namelijk geen flauw idee wat er allemaal gebeurt achter de schermen en welke keuzes er gemaakt worden. Zou de app-ontwikkelaar bijvoorbeeld dezelfde keuzes maken als u, als u de materie zou begrijpen en de technische kennis ervoor zou hebben? Weet de freelance app developer wat u wilt en kan deze dat ook toepassen?

In dit bericht wil ik wat dieper ingaan op wat nou een goede freelance app-ontwikkelaar maakt in de zin van wéten wat de klant wil en dát toepassen. Ik benoem daarin eigenschappen waarmee ik mijzelf ook meet en waarmee ik voor u kwaliteit probeer te bieden. Voor meer informatie kunt u daarom altijd contact met me opnemen.

Autogarage

Of de app-ontwikkelaar aan uw portemonnee denkt in plaats van enkel aan hoe netjes de code is, is voor u als opdrachtgever vaak niet duidelijk. De app developer geeft een schatting? Het zal wel. De developer zegt ‘het kost heel veel tijd’? Als hij het zegt. De app developer zegt ‘dit was de enige manier’? Oké, I guess?

Als je met de auto naar de garage gaat, heb je vaak ook geen idee of de kosten die deze maakt, verantwoord zijn. Vaak is je tevredenheid over de rekening een combinatie van eigen inzicht, gevoel bij de garage, reviews van anderen en de toereikendheid van je budget.

Wat je wílt is een goed werkende auto voor een zo klein mogelijk deel van je portemonnee. Maar ‘goed werkend’, ‘klein’ en ‘portemonnee’ zijn subjectieve zaken, en welk gewicht er aan welk aspect hangt, hangt van allerlei factoren af. Het is zaak voor de automonteur om snel te snappen met wat voor klant hij te maken heeft. Met kennis over deze voorkeuren kan hij namelijk tijdens de werkzaamheden bepalen bij welke kosten overlegd moet worden, en met welk kwaliteitsniveau onderdelen (gebruikt, standaard of premium) er gewerkt kan worden.

Zo was er een moment dat de lekke brandstofpomp van mijn auto zowel dichtgelijmd als vervangen kon worden. De voor- en nadelen tussen beide opties wilde ik graag weten. Maar als de brandstofpomp sowieso vervangen moet worden, en er de keuze is tussen een origineel onderdeel en een niet-origineel onderdeel van vergelijkbare kwaliteit, verwacht ik dat dat niet eens overlegd wordt, maar deze laatste zonder overleg wordt ingezet. Voor een andere klant is deze verhouding wellicht anders en daarom is het van belang dat een monteur zijn best doet de individuele klant te snappen.

App-ontwikkelaar

Dit geldt ook voor een iPhone app-ontwikkelaar. Een goede ontwikkelaar denkt aan de wensen en belangen van de klant, en probeert als een soort verlengstuk van de klant te werken. Op die manier kan je zorgen dat je de keuzes zou maken die de klant zou maken als deze de technische kennis zou hebben.

Want een ontwikkelaar moet vele malen per dag een keuze maken. Tussen bestaande code aanpassen, of opnieuw beginnen. Tussen open-source code inzetten of zelf schrijven. Tussen code schrijven die nu weinig tijd kost maar over enkele jaren herschreven moet worden, of meer tijd kwijt zijn aan een duurzame oplossing.

Praktijk

Hoe verhoudt dit zich tot de praktijk? Om een voorbeeld te noemen: Ik zal zelf regelmatig code schrijven waar een willekeurige andere ontwikkelaar zijn neus voor op zal halen. Waarom? Omdat het wellicht niet alle best practices van de industrie volgt, niet DRY genoeg is, of dat het code is die ‘te goed’ bij de klantspecifieke situatie past. Ja dat laatste kan. Een door vele programmeurs onderschreven ‘best practise’ is namelijk dat als je code schrijft, je het zodanig moet schrijven dat het grotendeels herbruikbaar is in andere situaties. Dat de kans dat deze code ooit daadwerkelijk elders ingezet gaat worden, nihil is, maakt voor zo een purist niet uit.

Voor mij maakt dit wel degelijk uit, en ik heb er dan ook geen enkele moeite mee code te schrijven die enkel één specifiek probleem bij één specifieke klant oplost. Het abstraheren (herbruikbaar / multi-inzetbaar maken) van code kost namelijk tijd. En bij geringe kans op hergebruik moet je voorkomen dat je de klant zijn gebrek aan overzicht (over wat je als developer aan het doen bent) gebruikt om weliswaar ‘perfecte’, maar te dure oplossingen te maken.

Zou de klant deze keuze namelijk ook maken als deze de programmeur en de investeerder inéén zou zijn? Of zou deze misschien een hele andere keuze maken?

Illustratie

Hierboven zie je een voorbeeld van zo’n overdreven abstractie. Zout is een smaakmaker. Een ‘purist’ zal daarom proberen vooral te coderen in termen van ‘smaakmaker’ en alleen daar waar strikt noodzakelijk, de term ‘zout’ te gebruiken. Allemaal om te faciliteren dat mocht ‘suiker’ ooit nodig zijn, dat makkelijk kan worden toegevoegd. Maar wat als je al weet dat de kans dat de opdrachtgever een extra smaakmaker toevoegt, lager dan 10 procent is? Moet je die abstractie dan nog steeds toepassen? In veel gevallen niet. De keuze die de developer hierin maakt, is echter voor de klant volstrekt onduidelijk.

Terug naar het onderwerp wat je nou kan verzekeren dat je met een app-ontwikkelaar te maken hebt die jou begrijpt en vanuit jouw zakelijke doelen keuzes leert maken. Aan het begin van deze post gaf ik aan dat het vaak een black box is. Je hebt geen flauw idee welke keuzes de ontwikkelaar maakt. Maar dat hoeft het niet te zijn. Ik beschrijf hieronder twee momenten waarop u deze check kunt doen.

Vooraf

Vraag bijvoorbeeld een keer door bij een schatting. Waarom verwacht je deze hoeveelheid uren voor dit onderdeel? Het kan zomaar zijn dat de programmeur de meeste tijd zal kwijt zijn met een onderdeel wat u niet zo interesseert. Als de programmeur de schatting overigens in het geheel niet kan onderbouwen, is dat geen reden om hem minder te vertrouwen. Als iets namelijk nog onbekend is voor een ontwikkelaar, moet hij gaan gissen. Dan is het heel normaal om aan de bovenkant van het verwachte urenbereik te gaan zitten zonder precies te weten waarom, om u niet met onverwachte meerwerkkosten op te zadelen.

Achteraf

Vraag de app developer eens om wat zaken die in de afgelopen periode veel tijd gekost hebben, te beschrijven en welke keuzes hij hierin gemaakt heeft. Vaak is de 20-80 regel van toepassing en is 80 procent van de gevraagde functionaliteit, in 20 procent van de tijd al klaar, maar kost de verfijning en het ‘it just works’ effect ,de overige 80 procent van de tijd. Verwacht je echter dat de gevraagde functionaliteit slechts beperkt waarde / omzet toevoegt, dan kan het zijn dat het slim is dat de programmeur de volgende keer op dat onderdeel iets meer de kantjes er van afloopt om meer belangrijke onderdelen meer prioriteit te geven.

Dit alles niet met het doel om met de app developer over zijn rug te blijven kijken of deze het gevoel te geven gemicromanaged te worden, maar juist het tegenovergestelde. Hoe meer en hoe gemakkelijker de app developer een verlengstuk wordt van de opdrachtgever, des te meer je er op kunt vertrouwen dat deze bij een willekeurige nieuwe opdracht keuzes maakt die u als opdrachtgever ook zou maken.

Conclusie

Samenvattend kunnen we stellen dat

• Er in de black box genaamd app-ontwikkeling prioriteiten gegeven kunnen worden die u zelf niet zou geven
• Dit komt omdat een app-ontwikkelaar graag goede kwaliteit code oplevert, die robuust en toekomstbestendig is, maar
• Deze toekomstbestendigheid niet altijd nodig is
• U daarom gemaakte keuzes met de app-ontwikkelaar kunt bespreken, vooraf of achteraf, met als doel de onderlinge samenwerking te versterken
• U daarmee de ontwikkelaar meer een verlengstuk van de opdracht gevende organisatie kunt maken

Wilt u meer weten over mogelijkheden voor iOS en Android apps bij uw organisatie? Kwaliteit hoeft niet ver weg te zijn. Neem direct contact op.

Uitgelichte afbeelding van: pressfoto – www.freepik.com