Je baas wilde het gisteren al hebben, maar het moet wel voldoen aan de eisen van morgen. Je klanten willen elke feature die ze maar kunnen bedenken, maar je wilt ze niet in de knoei brengen door alle knoppen te maken die ze kunnen bedenken. En collega-programmeurs willen documentatie van je werk, maar reageren met 'tl;dr' op al je berichten.

De dilemma's die ontwikkelaars tegenkomen, evolueren naarmate technologie vooruit gaat. Elke keuze roept lastige vragen op - van platform tot dataopslag tot hoeveel controle je uit handen geeft aan gebruikers. Dankzij de cloud en de opkomst van mobiele technologie lijkt het of programmeurs steeds meer keuzes - en dilemma's - voorgeschoteld krijgen.

Problemen samenvatten en benoemen leidt tot oplossingen - wordt wel eens gezegd. Daarom hier een lijst van de meest voorkomende dilemma's die ontwikkelaars vandaag de dag tegenkomen. Deze lijst is verre van volledig - maar welk project dat met applicatieontwikkeling te maken heeft is dat wel?

Dilemma 1: Wanneer zeg je 'nee' tegen vragen om features?

Als we een euro kregen voor elke vraag om een feature die klanten nodig hadden, waren we nog steeds blut omdat we een heel nieuw boekhoudingssysteem moesten bouwen om de gewenste features aan euro's te koppelen. En de data zou met elkaar vergeleken en geprioriteerd moeten worden, omdat de klanten ook een uitgebreid managementsysteem aan hun euro's zouden willen koppelen. Uiteraard moet dit systeem naar de cloud gekopieerd en vertaald worden in elke denkbare taal.

Dit is nou precies het dilemma: iedereen wil uitgebreide features, maar niemand wil betalen voor het beheer ervan. Maar iedereen die wel eens iets simpels als een afstandsbediening met vier knoppen heeft gebouwd, weet hoeveel triljard ontwerpjaren eraan vooraf zijn gegaan om zoiets eenvoudigs in elkaar te zetten. Het maken van iets elegants vereist liters bloed, zweet en tranen.

Van wie de aanvraag ook komt, van de klant, de marketingafdeling of de verkopers, je zou hem wel eens een slechte dienst kunnen bewijzen als je de gevraagde knop ook echt gaat maken. Want opeens zijn er dan te veel knoppen, of er ontstaat verwarring over wat elke knop doet. In de ideale situatie is iets snel intuïtief in elkaar gezet, maar jammer genoeg is het vrijwel onmogelijk iets intuïtiefs te bouwen voor mensen die te veel van hun software vragen.

Men zegt wel eens dat het minstens 10.000 uur kost om écht goed te worden in wat je doet. Dat heb je aan je baas proberen uit te leggen, maar dat wordt weggelachen, want een klant van de app-winkel of collega bij de administratie heeft het te druk met het geven van een slechte beoordeling om ook nog eens te kunnen begrijpen welke features je precies hebt gebouwd - ook al zijn dit de features die mensen zeggen te willen.

Triest genoeg is het vaak het beste om de klant ervan te overtuigen dat ze de feature niet moeten willen. Kijk maar eens naar Twitter. Dat is een vrij featureloos systeem met een bovengrens van 140 tekens - bijna belachelijk in dit tijdperk van terabytes. Desondanks floreert het netwerk, en dat maar weer eens duidelijk zien dat je vooral niet alles tegelijk moet willen.

Was er maar een afdoende manier om een halt toe te roepen aan die eeuwige vraag om nieuwe features.

Dilemma 2: Hoeveel documentatie is genoeg?

Ik zat eens in een vergadering samen met een onbezonnen projectleider, die stevig van leer trok tegen een concurrerende manager. Hij beloofde dat de programmatuur van zijn team "documentatie" zou bevatten. Na een korte pauze zei hij, als een James Bond die zich voorstelt: "uitgebreide documentatie".

Maar er is maar één ding erger dan geen documentatie en dat is een plank vol met mappen met daarin uitgebreide documentatie. Sommige managers wegen de voortgang van een project af per kilo: meer woorden zijn betere woorden. Iedereen die wel eens een boek van Harry Mulisch heeft doorgewerkt op de middelbare school, kent dit gevoel.

We willen van alles van de programmatuur weten en hoewel iedereen op Facebook de afkorting 'tmi' kent, is er geen populaire afkorting voor 'Too Little Information'.

De vraag om documentatie heeft geen eenvoudig antwoord voor de ontwikkelaar. In de ideale situatie is de software zelf eenvoudig en al gedocumenteerd genoeg, zodat er geen lange alinea's nodig zijn voor de uitleg wat de code precies doet. Die informatie raakt tenminste niet verouderd na een update, zoals teksten die natuurlijk niet worden bijgewerkt.

We hopen dat een nog slimmer groepje debuggers en compilers onze code beter begrijpt. De nieuwste virtuele systemen houden namelijk uitgebreide bestanden bij over welke routines worden aangesproken. Daarbij ligt de nadruk op prestatieverhogingen, maar dit soort metadata komt vaak beter van pas dan echte documentatie op het moment dat programma's gewijzigd worden.

Het zal nog jaren duren voordat kunstmatige intelligentie onze programma's kan begrijpen. Maar daar hebben we nu niets aan. Nu zitten we nog steeds met het dilemma van hoeveel documentatie genoeg is om iedereen tevreden te stellen zonder de featureset geweld aan te doen.

Dilemma 3: Naar de cloud of op de grond?

Het is veel makkelijker en sneller om een nieuwe server op te zetten in de cloud dan een aanvraag indienen voor een nieuwe en wachten tot de serverbeheerder er eentje bijkoopt. Je drukt op een knop en je hebt er een server bij.

Dat lijkt goedkoop, maar eigenlijk is deze aanpak prijzig. De server kost misschien maar een paar dubbeltjes per uur, maar dat tikt nogal aan als iedereen een cluster wil voor z'n eigen project. Voor je het weet heb je honderden servers in de cloud, waarvan er een heleboel zijn gemaakt door mensen die niet eens meer bij het bedrijf werken. En dan is het soms goedkoper om de rekening te betalen dan om uit te vogelen welke server waarvoor dient.

Nog erger: de servers zijn niet van jou. En sommige aanbieders hebben ingewikkelde voorwaarden die erg eenzijdig zijn. Soms kunnen ze de server zelfs neerhalen zonder gegronde reden. Dit lijkt nu te veranderen omdat aanbieders begrijpen dat zie hiermee goedbetalende klanten wegjagen. Maar het is niet duidelijk wat er nu precies gebeurt bij problemen in de cloud. Soms helpt het als je de financiële administratie beheert van degene die de server in de lucht houdt.

Hoe meer je uitbesteedt, hoe meer je de controle verliest en hoe harder je moet werken om die terug te krijgen. Hoe minder je uitbesteedt, hoe harder je moet werken om zelf alles in de lucht te houden. Je bent dus hoe dan ook de sjaak.

Dilemma 4: Vasthouden aan de oude code of nieuwe schrijven?

Een van de grootste uitdaging als je zakelijke software draait, is de vraag wanneer je beter kan vasthouden aan de bestaande programmatuur en wanneer je moet overstappen op nieuwe code. Iedere regel van de software wordt elk uur ouder en hoewel je dat niet zou verwachten, bederft software beetje bij beetje.

Het oude programma houdt er op een gegeven moment mee op. Aanbieders van de software hebben diensten die op punten verschillen of ze kappen helemaal met het ondersteunen van features. Zo sloot Twitter ontwikkelaars buiten die de oude api bleven gebruiken terwijl het bedrijf wilde dat men OAuth ging gebruiken. Dit soort verhalen komt vaker voor.

Het probleem is dat vervanging duur kan zijn. Programmeurs worden meestal gedwongen om compatibiliteit met de vorige software te behouden. Hierdoor moeten ontwikkelaars vaak twee programma's bouwen: één vol met oude bugs en één met allerlei nieuwe die nog niet zijn ontdekt.

Wat de zaak alleen maar erger maakt, is dat het nieuwe programma aan een hogere standaard moet voldoen. Ik heb een aantal ajax-meesterwerken langs zien komen die veel trager draaiden dan de ouderwetse greenscreen code, omdat ze allemaal mooie knoppen en bergen afbeeldingen gebruikten die de videokaart belastten. Het ziet er gelikter uit, maar het werkt veel trager.

Dit dilemma heeft geen eenvoudige oplossing. De oude software werkt nog steeds. We zijn er dol op. Maar het is niet compatibel met het nieuwe besturingssysteem of met die nieuwe multikernprocessor. Nieuwe software kost geld. We kunnen oude problemen oplossen, maar wie weet wat voor nieuwe problemen ervoor in de plaats opduiken?

Dilemma 5: SQL of NoSQL?

Een uitdaging voor databaseprogrammeurs: blijven we bij het oude, vertrouwde SQL of stappen we over naar het trendy NoSQL, waar alles groter is en klaarstaat voor eindeloze stromen data?

Die nieuwe NoSQL-databases klinken aanlokkelijk. Ze kunnen veel sneller zijn dan oude databases en ze dwingen gebruikers om problemen te vermijden die in het verleden zo vaak ellende veroorzaakten. Joins, bijvoorbeeld, vertragen de database als ze te complex worden. NoSQL gebruikt dit systeem niet meer, net als veel andere onderdelen van SQL. Je kunt iedere datasleutel die je maar wilt gebruiken en de NoSQL-database vindt het wel.

Maar als je beter kijkt, zie je dat het leven niet altijd even mooi is met NoSQL. Zo biedt deze database geen garanties dat data ook echt wordt opgeslagen. Meestal gaat dat goed, maar niet als er iets gebeurt met een harde schijf of computer in het cluster. Enkele nieuwe NoSQL-programma's, zoals dat van Oracle, vragen om transactiebevestiging. Maar in dat geval kan de software dus duimen draaien en wachten op de code, net zoals bij een SQL-database.

Er zijn dieperliggende problemen. Veel snelheidsproblemen bestonden omdat programmeurs niet nadachten over de subtiele effecten van SQL. De structuur die je aanbrengt in tabellen en queries maakt een groot verschil in de prestaties van de database. Meerdere tabellen verbinden en de database dwingen joins uit te voeren, vertraagt de boel.

Maar als je dit wilt bereiken met een NoSQL-database, schrijf je vaak data weg naar meerdere plekken en moet je maar hopen dat het intact blijft. Het is hetzelfde werk als het joinen van niet overeenkomende delen van de database en dat betekent waarschijnlijk dat je dit terugziet in de snelheid. Als je je hiervan bewust bent en rekening houdt met dit effect op het moment van het opzetten van de database, komt het ongetwijfeld in orde. Maar doe je dit niet, dan kan de software trager en foutgevoeliger worden. De database zal de transacties weigeren uit te voeren en vervolgens moet je ze alsnog zelf uitvoeren.

Dit dilemma heeft een eenvoudige oplossing. Applicaties die meer consistentie vereisen, moeten vertrouwen op de garantie dat transacties worden voltooid - zoals oudere SQL-machines doen. Applicaties die snelheid vereisen en om kunnen gaan met een paar warrige records, kiezen de nieuwere NoSQL-databases. Maar als je én snelheid én consistentie van de data wilt, kun je net zo goed meteen beginnen met het uittrekken van je haar.

Dilemma 6: Native of mikken op het mobiele web?

In den beginne was Apple niet van plan ontwikkelaars apps te laten maken voor de iPhone. Als je iets met de iPhone wilde doen, moest je het in HTML5 voor Safari schrijven. Dit was een elegante oplossing met een duidelijke sandbox waar ontwikkelaars mee konden werken.

Maar niet iedereen was even blij met het gesloten platform. Mensen wilden native software schrijven, want dat is essentieel voor snelle games en voor apps waarmee je informatie wilt opzoeken. Apple gaf toe aan de wensen van ontwikkelaars en nu hebben we de App Store.

Het probleem is dat voor de iPhone geschreven apps niet werken op andere smartphones en andersom. Een bedrijf dat meerdere doelgroepen wil aanspreken, moet de app herschrijven - een traag proces dat gevoelig is voor compatibiliteitsissues. Bovendien is het (drie)dubbel zo veel werk.

HTML5 is een redelijke optie. Als je een app kunt schrijven als webpagina, is er een grote kans dat gebruikers hem kunnen gebruiken in de browser van een smartphone. Er is al een aantal platforms dat dit proces versoepelt.

Maar de smartphonefabrikant heeft er niet altijd baat bij om dit soort interoperabiliteit te ondersteunen. Als toestellen willen opvallen, moeten ze iets speciaals bieden en dat komt meestal neer op iets anders. Dat gebeurt niet als iedereen dezelfde HTML5-apps gebruikt.

Daarnaast zijn er voldoende geruchten dat de prestaties van HTML5 op smartphones te wensen over laten. Sommige benchmarktests wekken de indruk dat HTML5-engines trager zijn. Er is geen eenvoudige manier om dit te testen of zelfs om te begrijpen wat de oorzaak is van trage code. In de meeste gevallen is HTML5 langzamer omdat de taal geïnterpreteerd wordt in plaats van rechtstreeks gecompileerd.

De oplossing voor dit dilemma moet dan ook gezocht worden in de vraag hoe belangrijk prestaties zijn voor je mobiele app. Als het essentieel is, dan is een native app-ontwerp het antwoord. Zo niet, dan heb je ruimte om de mogelijkheden van HTML5 te bekijken.

Dilemma 7: Gebruikers veel of weinig vrijheid geven?

Gebruikers zijn net kinderen: ze willen zoveel mogelijk vrijheid, maar ondertussen verwachten ze wel dat jij - de goede ouder - ze beschermt. Ze willen de veiligheid van een muur om de tuin, maar willen wel door de achterpoort naar buiten kunnen glippen als ze dat willen.

Hoeveel van het programma gebruikers zelf moeten kunnen beheersen, is een moeilijke vraag. De filosofie van open source dringt diep in onze cultuur door, waarin iedereen de software opnieuw moet kunnen opbouwen en vervolgens naar wens aan moet kunnen passen. Helaas kan de gemiddelde gebruiker deze mogelijkheid niet eens gebruiken, hoe graag ze het ook willen. Zelfs programmeurs zijn uren bezig om de juiste versies van alle libraries te vinden en de recentste compiler op te diepen. Zelf beheersen is zinloos als je geen tijd hebt om de optie te gebruiken.

Sommige bedrijven zetten in op het ideaal van open databases. We moeten allemaal de informatie die we willen hebben ook daadwerkelijk kunnen downloaden. Maar de meesten van ons kunnen niets met deze informatie doen en de enige die de tijd en het geld hebben om hier daadwerkelijk gebruik van te maken, zijn andere bedrijven.

Dit is een dilemma zonder oplossing. Geef gebruikers zelf de controle in handen en ze klagen over de UI en de features die ze missen. Doe het niet en ze zullen erom blijven zeuren.

Dilemma 8: Wel of niet teruggeven aan open source?

Open source is in principe gratis: je betaalt er niets voor en dat zorgt ervoor dat veel ontwikkelaars met dezelfde basis kunnen werken. Maar niet iedereen denkt na over de ethische kwestie die bij dat gebruik komt kijken. Veel open source-producten hebben een licentieregeling en daar moet je je wel aan houden.

Sommige licenties verplichten niet veel. Licenties als Apache en MIT eisen dat ernaar wordt verwezen, maar dat is het zo ongeveer. Andere licenties, zoals de GNU-licentie vereisen dat je elke verbetering die je deelt ook weer open source beschikbaar stelt.

Het gebruik van een open source-licentie levert uitdagingen op. Een manager van een groot bedrijf vertelde me ooit: "We distribueren MySQL niet verder, dus we zijn niemand iets schuldig." Hij verwees daarmee naar een clausule in de licentie, decennia geleden geschreven, die de licentie verbond aan het distribueren van de software. Het bedrijf gebruikte MySQL voor diens web-apps en de chef vond dat dit gebruikt kon worden zonder terug te geven aan de open source-community.

Het is moeilijk om ethische verplichtingen te meten en menig programmeur heeft er een heleboel toetsaanslagen aan besteed om te bediscussiëren wat ze inhouden. Open source-ontwikkeling komt echter helemaal stil te staan als niemand meer iets bijdraagt aan het project. Het goede nieuws is dat het in iedereens voordeel is om bij te dragen, omdat dat de manier is om je software compatible te houden.

Dilemma 9: Veel of weinig data verzamelen?

Als je data verzamelt, kun je erop rekenen dat je op een gegeven moment moet kiezen tussen het dienen van de klanten en het dienen van de overheid. Het wordt steeds normaler dat politie en justitie aan komen kloppen bij organisaties voor gegevens - zelfs nu de bewaarplicht is vervallen - waardoor je moet nadenken over in hoeverre je op zulke vragen kunt of wilt ingaan.

Het is vrijwel onmogelijk om nee te verkopen als er met een gerechtelijk bevel wordt gewapperd en je ziet dat sommige bedrijven daarom van tevoren kiezen voor dataminimalisatie: hoe minder je opslaat, hoe minder je kunt overhandigen. Dat is niet altijd mogelijk en de oplossing is daarom ook niet altijd eenvoudig. Een bedrijf als Lavabit zag zich genoodzaakt de deuren te sluiten, in plaats van de privacy van klanten op te geven.

Dilemma 10: Logbestanden: wat sla je op en hoe ga je ermee om?

Dit is eigenlijk een verlengde van het vorige dilemma. Zelfs als je zo min mogelijk gebruikersdata verzamelt, is het wel van belang dat je (belangrijke) processen logt.

Programmeurs lijden aan verzamelzucht. Elke actie wordt gedocumenteerd, omdat het vaak de enige manier is om een systeem te debuggen. Maar logbestanden houden ook bij wat gebruikers allemaal doen en bevatten daarom ook regelmatig informatie die gebruikers liever voor zichzelf zouden willen houden.

Veel bedrijfsvoering is afhankelijk van het goed bewaren van logbestanden. Sommige back-updiensten beloven zelfs om extra kopieën op verschillende fysieke locaties op te slaan. Maar niet elk bedrijf heeft de aspiratie om alles te bewaren. Neem Snapchat dat juist groot is geworden met het concept dat gegevens nergens worden bewaard. Gebruikers houden juist van het idee dat ze een systeem gebruiken waarbij ze worden vergeten.

Het bestaan van logfiles werpt ethische vraagstukken op. Worden de bestanden goed bewaard? Wie heeft er allemaal toegang? Als we deze bestanden verwijderen, zijn ze dan ook daadwerkelijk verwijderd?

De crux is bepalen welke informatie moet worden behouden gezien de risico's ervan - ethisch of anderszins. Het lastige is dat het vrijwel niet te voorspellen is wat er gaat veranderen. In de jaren 60 was roken doodnormaal en zou niemand erover hebben nagedacht om bij te houden wie wanneer rookt. Vandaag de dag is dit bijvoorbeeld waardevolle informatie voor verzekeraars.

Gezien de mogelijke bedrijfsovereenkomsten, manieren waarop overheidsregels zich ontwikkelen of andere wendingen in de bedrijfsvoering, is het vrijwel onmogelijk om in te schatten hoe nu onschuldig ogende logbestanden in de toekomst problematisch kunnen zijn. Daarom is het van essentieel belang om van tevoren goed na te denken over de (mogelijke) ethische impact van zulke bestanden.

Dilemma 11: Gebruikers veranderen in producten of niet?

Dit is een modern adagium geworden: "als je niet betaalt voor een product, dan bén je het product". Op het internet is een heleboel 'gratis'. De vraag waar het geld dan vandaan komt, wordt vaak niet beantwoord en daar zouden we naar moeten kijken. We worden afgeleid door het bouwen van mooie features, het kijken naar downloadcijfers en gaan ervan uit dat iemand anders het licht in de serverruimte wel aanhoudt. In het ergste geval, kunnen we altijd nog terugvallen op het toevoegen van advertenties.

Ontwikkelaars moeten open zijn over wie hun werk ondersteunt en waar dat geld vandaan komt. Wijzigingen in de opzet moeten tijdig en helder aan gebruikers worden gecommuniceerd om te voorkomen dat gebruikers in (al dan niet terechte) paniek raken. De ethische gevolgen van het veranderen van gebruikers in producten moet je niet te lichtvaardig behandelen. Schimmige advertentiedeals en louche bannernetwerken zijn er genoeg - daarom moeten we voorzichtig omspringen met het vertrouwen dat gebruikers in ons tonen.