Kwaliteitsvelies
Aangezien er momenteel vooral op korte termijn wordt gekeken naar de beste oplossing voor het uitwerken van een project, en er geen tijd/ruimte is voor innovatie op workflow-gebied, komt dat ten koste van de project- en codekwaliteit.
Dit komt vooral naar voren aangezien de implementatie/uitwerking van projecten momenteel vooral in WordPress gebeurt. Daarbij kan er dan wel snel een project de lucht in worden gegooid, maar de basis is niet stabiel. Bij WordPress moet je namelijk vrijwel alle gewenste features bij elkaar sprokkelen door het installeren van plugins, waarover je amper tot geen controle hebt.
Dit houdt in dat je basis bestaat uit WordPress als CMS, en een hele lading aan eigenlijk onbekende code door andere developers. WordPress is dan wel veelgebruikt, maar staat ook bekend om diens security-issues, bugs en moeizaamheid.
Je kunt het vergelijken met het bouwen van een villa, waarbij het fundament 100 jaar geleden is gebouwd. Eerst is het prima, er wonen toch nog niet zo veel mensen in. Maar na een tijd komen er veel- en veel meer mensen te wonen. Dat ene muurtje dat niet zo stabiel was, wordt snel gerepareerd met nog een extra laag bakstenen. Er wordt nog een waterleiding omheen gelegd. En zo door.
Omdat er al zo veel mensen inmiddels wonen, kun je niet 'even' dat muurtje afbreken en opnieuw bouwen, dus zul je het moeten doen met meer hacky oplossingen.
Zo dus ook met WordPress: er zijn fundamentele dingen die technical debt bevatten en niet zomaar opgelost kunnen worden. En zo bouwt dat op over de jaren heen.
Fun fact: dit is ook benoemd door de co-founder van WordPress zelf:
Alternatief
Met de code-brij die under the hood gaande is bij WordPress, is het dan ook niet te doen om daarin gestructureerd te werk te gaan en kwalitatief goede code achter een project te leveren.
Om een gestructureerede workflow te volgen en kwalitatief goede code te leveren, is een minimaal niveau van controle over de front- en backend nodig van een website.
De onderbouwing hiervan en start van het opvolgende onderzoek vond zijn wortels in het houden van interviews met andere Digital Agencies>, waaruit bleek dat andere om dezelfde redenen zoals vermoed, al van WordPress zijn afgestapt.
Er is dus sprake van een direct verband tussen structuur, kwaliteit en mogelijkheid van implementatie hiervan.
Daarom is met Code Cookbook ook onderzocht wat voor alternatieven er mogelijk zijn ter vervanging van WordPress als CMS.
Overtuiging
Mate van gebruik van WordPress
Een ander probleem dat hierbij aanwezig was, was dat de developers bij het bedrijf er nog niet van overtuigd waren dat er inderdaad zo veel projecten van hen nu al op WordPress draaien.
Zij hadden het idee dat misschien 10% van hun sites op WordPress draaide, en de rest op een custom codebase.
Dit is onderzocht, en bewezen dat de realiteit heel anders ligt. Vervolgens is dit aan hen gepresenteerd in de vorm van datavisualisaties om deze realiteit te verduidelijken.
Deze visualisaties zijn te vinden onderaan deze pagina.
Tijd besteed aan bugfixes
Ook was er niet het besef dat er, door de hoeveelheid >bugs en technical debt, ook nog eens vrij veel tijd verloren gaat aan bugfixing bij een project
Dit kan gezien worden als 'verloren tijd'; bestede tijd aan het oplossen van bugs, wat niet nodig had hoeven zijn indien de basis waarin het project ontwwikkeld is, stabieler was geweest.
Om dit in kaart te brengen,is de volledige dataset van de urenregistratie onderzocht, 'gecleaned', gefilterd en ge-output naar nog een datavisualisatie waaruit af te lezen valt dat er over tijd nog best wat tijd wordt besteed aan bugfixes. Meer dan gedacht.
Concluderend
Met behulp van het onderzoek en de (data)visualisaties, zijn de designers/developers dan ook geconfronteerd en vooral overtuigd van de huidige situatie/stand van zaken.
Doordat dit inzicht gecreeërd is en er benchmark-onderzoek is uitgevoerd, is hiermee de willingness van het bedrijf verhoogd tot het overgaan op een nieuwe workflow en het opvolgen van bijbehorende adviezen. Precies waarvoor Code Cookbook ontwikkeld is!
