De afgelopen weken heb ik op Linkedin veelgestelde vragen beantwoord over software ontwikkeling. In dit artikel hebben we de vragen en antwoorden onder elkaar gezet. Zijn er dingen waar jij tegenaan loopt bij het slimmer (digitaal) maken van jouw organisatie? Laat het ons graag weten.
Schaalbaarheid van software: Is er over nagedacht?
Schaalbaarheid van een app, hier kreeg ik laatst weer een vraag over. Vaak gaat het alleen niet verder dan “is er over nagedacht?”. Logische vraag, want als groeiende organisatie wil je dat jouw software meegroeit om jouw business optimaal van dienst te zijn.
Ja, in de meeste (lees: bijna alle) gevallen wordt hier rekening mee gehouden.
Maar hoe dan? Daar knoopte ik even een gesprek voor aan met de specialist.
Voor de programmeur kan het antwoord zo simpel zijn als “je houdt gewoon er rekening mee in jouw code”, terwijl een dergelijk antwoord voor de klant veel vraagtekens oproept. De programmeur bedoelt dat je code-technisch er bijvoorbeeld rekening mee kunt houden dat er niet te vaak om data wordt gevraagd aan een database (het minimaliseren van database calls). Dat alleen kan er al voor zorgen dat je niet om de maand een extra server moet bijklikken en dat je applicatie meer gebruikers aankan. Een ander voorbeeld van schaalbaarheid is het modulair opbouwen van de code. Dit is voor de gebruiker niet direct zichtbaar, maar maakt voor de developer de code een stuk leesbaarder en dus beter te onderhouden- en uit te breiden.
Software updates: “Hoe zit het daarmee?”
Dit is wel een leuke vraag. Het lijkt namelijk simpel, omdat iedereen gewend is om zijn/haar App Store te openen en simpelweg op ‘update all’ te drukken. Was het maar zo’n feest.
Nee, bij maatwerk software gaat er meer werk in zitten. Met een update kan enerzijds een nieuwe functionaliteit (of bugfix) worden bedoeld en anderzijds een update aan de tech stack. Het eerste is afhankelijk van de veranderende behoefte van (eind)gebruikers en de go vanuit een opdrachtgever om door te ontwikkelen.
Het tweede heeft te maken met bijv. een nieuwe versie van het Laravel framework (de basis waarop jouw applicatie wordt ontwikkeld). Aan dit framework wordt continu doorontwikkeld en iedere maand wordt er wel een nieuwe versie gereleased. Een nieuwe versie zorgt vaak voor security en/of performance patches.
Het uitvoeren van updates aan jouw applicatie wordt niet altijd standaard gedaan, dus het is een slimme vraag om te stellen voordat je een (web)app laat maken.
Software doorontwikkelen: “Kan dat als je al een bestaande applicatie hebt?”
Ja, dat kan, al is er één grote maar.
Het kan slechts wanneer de reeds bestaande software ontwikkeld is in dezelfde framework(s) als waar jouw nieuwe partner mee werkt, de code leesbaar is geschreven en jouw nieuwe partner er mee kan dealen om andermans werk en de daarbij horende stress over te nemen.
Is dat niet het geval, dan gaat de code deels herschreven moeten worden of compleet opnieuw worden ontwikkeld. Wel kan je dan de learnings uit de eerder gemaakte applicatie meenemen. Dat kan een enorm verschil maken in de doorlooptijd.
Bij het ontwikkelen van een feature: “Dat is toch vrij simpel om te maken?”
Dat denk je. Vaak komt er toch meer bij kijken. Net zoals een kozijn schilderen niet zomaar een likje verf aanbrengen is, maar volgens de Gamma een 13 stappen proces betreft waarbij de voorbereiding meer werk is dan het schilderen zelf, is dat bij software ontwikkelen ook het geval.
Volgens mij komt daar het spreekwoord ‘de beste stuurlui staan aan wal’ vandaan.
In software ben je minder aan het schuren, maar ben je meer bezig met dingen als voorbereidend uitzoekwerk voor een nieuwe feature, het schaalbaar opzetten van de nieuwe code zodat hierop voortgeborduurd kan worden en natuurlijk het gevecht aangaan met smerige bugs die je niet had kunnen voorzien (die in veel gevallen applicatiespecifiek zijn, dus dan sta je er alleen voor!).
Indicatie maken van een software project: “Hoeveel tijd gaat dat kosten?”
Dit blijft altijd een lastige. De ontwikkelaar die de indicatie maakt moet namelijk met heel veel zaken rekening houden.
Wat moet er precies ontwikkeld worden en hoe complex is dat? Voorzie ik problemen bij de implementatie die extra uitzoekwerk gaan kosten? Zijn er zaken die nog onduidelijk of onbekend zijn en mogelijk na oplevering nog extra tijd gaan kosten?
Om een concrete indicatie te kunnen geven voor een applicatie of feature moet over al deze punten goed worden nagedacht. Je kunt vrijwel nooit alle punten vooraf afvangen. Soms ziet de applicatie er op tientallen devices goed uit, maar net op één specifiek iPhone model niet. Andere keren ben je een API koppeling aan het ontwikkelen en blijkt er bij de derde partij een onverwachte bug te zitten, wat vervolgens uitzoekwerk kost om het alsnog werkbaar te maken. Hierom geloven wij niet in een fixed price indicatie voor features. Hoe kun je nu weten dat een feature precies 38 uur gaat kosten om te ontwikkelen? Hier zouden wij 34 tot 42 uur van maken.
Modulair ontwikkelen: “Kunnen we iets aan de prijs doen?”
Aber natürlich! We kunnen functionaliteiten schrappen of de kwaliteit teniet doen, dat is kort door de bocht de keuze die we hebben. Functionaliteiten schrappen is wat ons betreft dan de beste optie.
Vaak kan je namelijk met weinig, heel ver komen. Zeker als je een nieuw digitaal concept op de markt wilt zetten, kun je met een minimale versie van de applicatie het concept al valideren bij potentiële gebruikers. Weet je wat gebruikers willen en waar zij bereid voor zijn te betalen? Dan is de kans groot dat je in een later stadium minder bij hoeft te schakelen.
De afgelopen weken heb ik veelgestelde vragen beantwoord over software ontwikkeling. Vandaag behandel ik de laatste. Heb jij nog vragen? Zijn er dingen waar jij tegenaan loopt bij het slimmer (digitaal) maken van jouw organisatie? Let me know, ik denk met je mee!
Samenstelling van het ontwikkelteam: “Wordt er van mij iets verwacht tijdens het ontwikkelen?”
Goed dat je het vraagt. Naast dat er dingen van de ontwikkelaar wordt verwacht, worden er ook zaken van de opdrachtgever verwacht. Er dient namelijk iemand aangewezen te worden voor de rol als Product Owner en vaak is dat de opdrachtgever. De Product Owner is een essentieel onderdeel van het ontwikkelteam en voedt de ontwikkelaars met belangrijke (branche-specifieke) informatie zodat de programmeurs effectief kunnen blijven coderen.
Zie het als rallysport, waarbij wij de coureur zijn en jij de bijrijder. Jij navigeert het circuit en vertelt hoe wij rekening moeten houden met onderstuur om op de apex van bocht 3 uit te komen. Tja, zulke vaktermen krijgen we regelmatig mee te maken, jij bent namelijk degene met verstand van jouw organisatie en jouw branche dus jij weet wat de software moet kunnen, wij hebben verstand van het bouwen. Met deze combinatie maken we er samen iets succesvols van.
