Eye opener: ontwikkelaars besteden meer dan de helft van hun tijd aan het oplossen van performance problemen, in plaats van aan innovatie

Je kunt minstens 2 keer zo snel innoveren

Hé IT manager, hoeveel tijd zijn jouw ontwikkelaars bezig met brandjes blussen? Een recent onderzoek door Cisco toont aan dat ontwikkelaars 57% van hun tijd besteden aan brand bestrijding en in war rooms getrokken worden in plaats van het maken van nieuwe software die de kassa laat rinkelen. Met andere woorden, ze zouden 133% productiever kunnen zijn met innovatie als ze niet zo druk waren met het oplossen van problemen. Je vraagt je af: hoe snel kun je groeien als je innovatie snelheid verdubbelt?

Ontwikkelaars zijn opgeleid om problemen te verhelpen, niet om ze te vinden

Het blijkt dat ontwikkelaars moeite hebben om de root cause te vinden van performance problemen. Waarom? Het antwoord is simpel: daar zijn ze nooit voor opgeleid. Als je scheuren in je muren krijgt dan vraag je eerst een technisch bouwinspecteur om het probleem te vinden. Dan, na de diagnose, huur je een aannemer in om het te verhelpen. In de IT verwachten we dat de aannemer het vinden en het verhelpen beide doet. En dat is het probleem dat we meestal missen: het is het vinden van de oorzaken waar programmeurs veel van hun tijd verspillen.

Vinden van de root cause

Dus ... Je denkt dat je de root cause hebt? Toch? Of is het probleem toch veel groter? Huur eens een specialist in en ... Zit je goed? De root cause kan een een gebrek aan capaciteit zijn, maar net zo vaak is het dat niet. Veel vaker zit het in:

Slecht gebruik van netwerken
Slecht gebruik van databases
Latency problemen
Slechte configuraties
Veel mensen die ineens thuiswerken
Beschikbare capaciteit niet benutten
...

We hebben ze allemaal gezien en nog wel een paar.

Kortom: Je kunt het probleem alleen echt oplossen als je de root cause kent. Dus wil je dat die root cause snel gevonden wordt. Veel root causes zijn niet eens zichtbaar voor ontwikkelaars, maar er wordt wel van ze verwacht dat ze ze vinden en oplossen.

Zelfs als er een schijnbaar tekort is aan capaciteit helpt het bijplaatsen van CPU , geheugen of of disk maar tot een bepaald punt. Hardware en cloud capaciteit worden progressief duurder met toenemende snelheid. En er komt een punt dat je een duurder type database licentie nodig hebt ...

Verbeteren van de efficiëntie en schaalbaarheid (zie hieronder) van de software betaalt zich snel terug vanaf een bepaald punt.

Als software niet groeit, sterft het!

Waarom hebben ontwikkelaars geen schuld? Om een boel redenen! Je vraagt jezelf misschien af ... Maar de software is toch niet veranderd? Nee, maar de omgeving waarin het draait wel. Of een nieuwe Windows versie, Of een nieuwe database versie, netwerk aanpassingen, andere storage, andere hardware, ... Al die dingen gebeuren doorlopend en meestal buiten het zicht van de ontwikkelaars. Sommige van die veranderingen hebben grote gevolgen.

We zien onze IT collega's graag als tovenaar (en meestal niet onterecht), ze hebben geen laser ogen die elke verandering in hun omgeving zien. We moeten ze helpen het te begrijpen.

Een voorbeeld is de upgrade van SQL Server 2012 naar SQL Server 2014. Veel applicaties hadden een grote daling in performance na de upgrade vaak op onvoorspelbare momenten. De oorzaak was een grote aanpassing in de optimizer en de manier waarop database statistieken gegenereerd worden. De daling in performance had voorkomen kunnen worden de wijziging in 2014 is aangekondigd ruim voordat de release vrijgegeven werd voor productie omgevingen. Maar ontwikkelaars lezen meestal niet de release notes van een nieuwe database versie en zelfs als ze het wel doen begrijpen ze meestal de gevolgen niet.

Dit is maar ÉÉN voorbeeld van de vele verhalen die ik kan delen over deze problemen. Dergelijke problemen gebeuren vaak en worden veroorzaakt door aanpassingen in de omgeving waar een applicatie in draait.

Als jouw software niet aangepast wordt aan de wereld die steeds verandert zal deze langzaamaan steeds verder afbrokkelen. Je wilt zeker zijn dat je groeit en niet afsterft.

Optimaliseren voor de juiste schaal is essentieel

Er zijn honderden boeken geschreven over het schalen van een ontwikkel organisatie en je hebt er waarschijnlijk heel wat van gelezen. Maar wist je dat het schalen van de software minstens zo belangrijk is? Eerlijk gezegd, waarschijnlijk belangrijker.

Weet je wat er nodig is om de software die je levert te laten schalen? Niet goed schalen heeft veel oorzaken, ik noem er een paar: Veel performance problemen ontstaan als software moet schalen naar een grotere organisatie. Of het gaat om groei van een bestaande klant of om een nieuwe klant die veel groter is dan je bestaande klanten maakt niet uit. Of als je software gemigreerd wordt van een boel kleine on prem installaties naar één grote SAAS omgeving. Elke belangrijke schaal aanpassing vraagt een aanpassing van de software.

Neem een voorbeeld uit de fysieke wereld. Je kunt niet 200 eengezinswoningen aan elkaar knutselen om een wolkenkrabber te maken. Je kunt een wolken krabber niet van hout maken, zoals ze eengezinswoningen in Noord Amerika bouwen. Met software is het niet anders. Als het om schalen gaat moet je op een andere schaal denken en ontwerpen en een andere aanpak kiezen.

Je hebt inzicht nodig geen "observability"

Schoonheid is voorbehouden aan wie het wil zien. Zo is het ook met veel andere dingen. In dit blog (link) leg ik uit waarom APM tooling en observability je geen inzicht brengen. Inzicht dat je nodig hebt om snel te weten wat JIJ moet oplossen en hoe. Zodat je ontwikkelaars oplossingen goed gepland, gestructureerd en snel kunnen implementeren en zodat ze weer snel bezig kunnen met de innovatie die jouw en je klanten waarde levert.

Overzicht is cruciaal

De meeste It mensen zijn tegenwoordig specialisten. Ze weten alles van van een klein kennisgebied. Dat heb je nodig, maar met de complexiteit van de huidige applicatie landschappen ontbreken de mensen die overal iets van weten. De mensen die de verbanden zien. Als elke specialist naar zijn/haar eigen specialisme kijkt worden er dingen gemist. Je hebt een helikopter view nodig in je organisatie.

Bij een klant van ons werd het storage netwerk door de storage specialisten gezien als netwerk en door de netwerk specialisten als storage. Je mag 1 keer raden waar het probleem zat ;-)

Je hebt preventie maatregelen, toch?

Proactief is een buzzword in APM en observability. En we hebben proactiviteit hard nodig. Proactiviteit heeft meer nodig dan alleen maar een tool installeren en grenswaarden instellen, die een alarm af laten gaan. Proactief zijn met performance betekent dat je regelmatig kijkt, uitschieters en trends beoordeelt en actie onderneemt naar aanleiding van de uitkomsten zodat problemen niet problematisch worden. En nieuwe versies van de applicatie en zijn omgeving test voordat ze naar productie gaan. Wachten tot er alarmbellen gaan rinkelen en dan de brandslang uitrollen is reactief, zelfs als er een tool 'actief' voor je aan het meten is.

Stop met brand blussen, begin met innoveren!

Hulp van buiten vragen is essentieel als je wil dat je programmeurs voldoende tijd hebben voor verse innovatie die jou onderscheidt van de concurrentie. Dat stimuleert je groei.

Als we met onze klante werken dan vinden we hun problemen snel. We hebben een 100% score. Ons record is 15 minuten nadat we begonnen te meten . We leveren bruikbare inzichten die onze klanten in staat stellen om snel oplossingen te implementeren en weer door te gaan met innovatie. Dit is wat een klant van ons zei: “Met name in drukke periodes liepen de diverse applicaties regelmatig vast, tot grote frustratie van de medewerkers natuurlijk. Net als de financiële rapportages moesten worden gedaan waren de servers niet vooruit te branden! Onze systeembeheerders waren zich hiervan bewust, en deden wat ze konden. Ze breidden het geheugen elke keer maar weer wat uit, maar de problemen bleven terugkomen. Zij wisten het op een gegeven moment ook niet meer. Ik kwam toen in contact met Sciante en maakte een afspraak”.

Maak nu een afspraak van 15 minuten en ontdek hoe je je ontwikkelaars omtovert van brandweermensen in innovators. Klik hier om de afspraak te maken.