Development

Software-ontwikkeling
boos

5 grootste irritaties van ontwikkelaars

Waarbij trekken Github-ontwikkelaars hun haar uit (hun baard).

© CC0,  Pixabay
6 februari 2017

Waarbij trekken Github-ontwikkelaars hun haar uit (hun baard).

Europese wetenschappers hebben onderzocht wat ontwikkelaars ongelukkig maakt en daarmee de voortgang van projecten frustreert.

Volgens de onderzoekers is het de eerste studie naar de belangrijkste frustraties van ontwikkelaars. Het beperken van de ongelukkigheid van ontwikkelaars kan volgens eerder onderzoek een belangrijke impuls geven aan de productiviteit.

Iedereen die wel eens programmeert, weet dat het veel voldoening kan opleveren. Maar het beroep van programmeur kan ook veel stress opleveren, zeker als er ook nog strakke deadlines in het spel zijn. De onderzoekers vroegen 180 ontwikkelaars met een reeks van onderzoeksmethodieken naar wat hen ongelukkig maakt.

Ze hebben hun bevindingen opgesplitst in interne en externe factoren. De top 5 frustraties door externe factoren zijn:

1. Slechte code en codeerpraktijken
De grootste frustratie is het aan de slag moeten met bestaande code die slecht in elkaar zit en/of niet of onduidelijk gedocumenteerd. Daarbij maakt het niet uit of de code door henzelf is geschreven of door anderen. Vooral wanneer het tegen komen van gebroken code zonder uitleg daarbij, leidt tot frustratie.

2. Bugs opsporen
In het verlengde daarvan ligt het opsporen van de coderegels die zorgen dat een bug optreedt. Vooral de steeds weer terugkerende bugs die steeds optreden wanneer je ze het minst verwacht en die veel tijd kosten om op te lossen.

3. Teleurstellende technische infrastructuur
Wanneer de infrastructuur niet werkt zoals je wil, gaat er veel tijd onnodig verloren. Het gaat bijvoorbeeld om verouderde infrastructuur of infrastructuur die niet goed gedocumenteerd is. Daarbij levert zowel te uitgebreid gedetailleerde als te weinig gedetailleerde documentatie teveel gedoe op.

4. Onduidelijke requirements
Ontwikkelaars willen graag weten waar ze aan moeten beginnen. Wanneer er te vage omschrijvingen van de gewenste functionaliteiteit zijn of onrealistische verwachtingen in de omschrijvingen staan, kunnen zij er niet mee uit de voeten. Voortdurende wijzigingen in de requirements is eveneens een bron van ergernis.

5. Onderhoud oude code
Nieuwe code schrijven volgens je eigen principes, normen en waarden is prettig. In praktijk komt het vaak voor dat onderhoud nodig is aan code waaraan lang niet gewerkt. Dan is het soms lastig te begrijpen hoe de code in elkaar steekt, waar het onderhoud op moet aangrijpen en hoe er eventueel nieuwe functionaliteit aan kan worden toegevoegd. De problematiek neemt toe wanneer de mensen die de code hebben geschreven niet meer bij het project betrokken zijn of zelfs de organisatie hebben verlaten.

Ook intrinsieke frustraties

Daarnaast hebben de onderzoekers een opsomming gemaakt van interne factoren, ofwel meer persoonlijke belemmeringen. Het gaat dan onder meer om frustratie over het feit dat de ontwikkelaars merken dat ze niet zo scherp zijn als ze zouden willen  en daardoor niet optimaal presteren. Maar ook gevoelens van burnout en angst of minderwaardigheid worden genoemd als frustrerende omstandigheden.

De ondervraagde ontwikkelaars waren er duidelijk in dat hun motivatie om code te schrijven daalt wanneer zij zich om een of andere reden niet gelukkig voelen.

Lees meer over Development OP AG Intelligence
5
Reacties
Anoniem 11 februari 2017 19:25

Atilla, Ben het met je eens, Punt 3 is toegelicht. Het is een terugkerend iets en van alle tijden.
"De technische infrastructuur is het grote andere speelveld binnen de ICT en daar is de laatste jaren gigantisch veel veranderd: virtualisatie, cloud, big data, etc.... Het adagium van de IT-Infrastructuur specialist is "pielen". En dan werkelijk tot zijn een ons wegen. IT-Infrastructuur wordt afgedaan als banaal en eenvoudig. Behalve.....als het dat niet is."
Punt 4 "de onduidelijke requirements" plaats ik bij het onvermogen van de opdachtgever om alles tot in detail uit te werken. Hij weet niet wat hij niet weet. Het is een taak in het project dat op te lossen. Is van alle tijden, maakte al onderdeel uit van SDM (pandata) de nadelen van die methode zijn ook bekend
Punt 1,2,5 Je bent developer of niet. Als je die zaken niet aankan kruisje aanvinken bij [niet].

Anoniem 10 februari 2017 15:10

Opvallend, de meeste items... daar ligt het probleem toch echt bij de ontwikkelaars zelf. Afgeven op de "andere" ontwikkelaar of zelfs op wat je zelf een tijd terug hebt gedaan.

De enige exerne factor is de IT infrastructuur. Tja voor veel bedrijven wordt dat slechts als kostenpost gezien en te weinig als belangrijke factor in wat het dan ook is waar het bedrijf geld mee denkt te verdienen. Worden de ramen niet gewassen, loopt de toilet juffrouw de kantjes er af, is de airco stuk, dan is dat vervelend, maar als je infrastructuur het laat afweten houdt voor veel bedrijven het allemaal op. Bizar dat dit essentiele stukje kapot bezuinigd wordt, geoutsourced naar de goedkoopste aanbieder en geoffshored als een vorm van ontwikkelingshulp naar het meest achtergelegen gebied.

De ontwikkelaar die wat dichter bij de IT infra staat raakt dat wat dieper in zijn ziel dan de overage personeelsleden.

Anoniem 09 februari 2017 14:23

"... De onderzoekers vroegen 180 ontwikkelaars ..."
180?!? Is het representatief?

Anoniem 07 februari 2017 14:34

De topics 1,2 en 5 zijn gewoon onderdeel van het werkveld. Dit goed kunnen beheersen is een pre.
Het is als Nederlander juist prettig om fijn af te kunnen geven op de arbeid van een ander, dus helemaal geen frustratie.

Anoniem 07 februari 2017 13:12

Het lijken net mensen die ontwikkelaars :-). Maar even serieus, twee van de irritaties zijn terug te ontvoeren naar een heel specifiek kenmerk dat alle ontwikkelaars (in essentie) bindt: "not invented here" (irritatie 1 en 5). Sinds mensenheugenis blijven alle ontwikkelaars bakken met code schrijven, die vermoedelijk al een keer is geschreven. De vele pogingen van re-useable code, object oriented programming, etc... ten spijt. Het lijkt wel de muziekbranche, alle melodietjes zijn al een keer gecomponeerd en gespeeld om meerdere instrumenten (analogie: programmeertalen). Dat van de bugs (irritatie) is een verlengde hiervan.

De technische infrastructuur is het grote andere speelveld binnen de ICT en daar is de laatste jaren gigantisch veel veranderd: virtualisatie, cloud, big data, etc.... Het adagium van de IT-Infrastructuur specialist is "pielen". En dan werkelijk tot zijn een ons wegen. IT-Infrastructuur wordt afgedaan als banaal en eenvoudig. Behalve.....als het dat niet is. Er is een eerste poging gewaagd om beide werelden (software ontwikkeling en IT-Infrastructuur) bij elkaar te krijgen (DevOps), maar dat is weer een tooling feestje geworden. Er zijn gigantisch veel aspecten die beiden werelden raken en niet afzonderlijk ieder in hun eigen wereld maar opgelost moeten worden: beiden werelden zijn veel meer verstrengeld dan menigeen wil accepteren.

Onduidelijke requirements doet me denken aan die reclame die je nu ziet van een drankje, waarbij iemand in het filmpje telkens te brede specs aangeeft voor wat hij wil " doe maar een pakje, doe maar een kapseltje, doe maar een reisje, doe maar een autotje". Natuurlijk heel erg overdreven, but you get the picture. Maar hier geldt: beiden kanten , de vraag (gebruiker) en aanbodkant (software ontwikkelaar) moeten echt met elkaar leren praten. Dus de gebruiker moet niet roepen en de software ontwikkelaar moet niet accepteren: "Doe maar een app-je"

Reactie toevoegen
De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.