I 25 år har jeg bygget hjemmesider, webshops og systemer. Til andre.
Kunden kommer med et behov, jeg oversætter det til kildekode, vi tester, vi lancerer, jeg sender en faktura. Det er en model jeg kender ud og ind, og den har fodret mig i et kvart århundrede.
For nylig gjorde jeg noget andet. Jeg satte Startstedet i luften - et klubsystem til danske svæveflyveklubber. Ikke til en kunde. Til mig selv. Og til de klubber, jeg selv har stået på flyvepladsen med, siden jeg begyndte at flyve svævefly i 2000.
Det viste sig at være en helt anden disciplin, end jeg havde regnet med.
Ikke fordi kildekoden var sværere. Men fordi der pludselig ikke var nogen at spørge.
Der er ingen kunde, der kan sige "sådan gør vi altid". Ingen kravspecifikation. Ingen at give skylden, når man har brugt tre uger på en feature, ingen efterspørger. Man er selv både bestiller og leverandør og det er langt mere ubehageligt, end det lyder.
Her er, hvad jeg lærte undervejs. Det meste af det kan bruges, uanset om du bygger til en svæveflyveklub eller til en maskinfabrik i Randers.
Problemet jeg selv stod midt i
Lad mig male et billede for dig.
Det er en lørdag morgen i maj. 22 piloter skal koordineres på en flyveplads. Der skal være en instruktør, en spilfører, wirehenter mv. Fly skal fordeles. Eleverne skal vide, hvornår de er på. Nogen har meldt afbud på Facebook i går aftes klokken 22, i en tråd som halvdelen af de fremmødte ikke har set.
Og hvordan holder man styr på det?
I mange klubber: med et regneark. En Facebookgruppe. En kalender på en hjemmeside, der blev bygget i 2014. Og en enkelt ildsjæl, der har det hele i hovedet, og som ingen tør spørge for meget, fordi han også har et arbejde.
Jeg har været den ildsjæl. Jeg har siddet i bestyrelsen, jeg har haft vagterne, jeg har lappet på det intra-system, klubben brugte. Og jeg har set det klassiske mønster: et system, der engang var en god idé, og som med tiden bliver til teknisk gæld, ingen tør røre ved af frygt for, at det hele falder fra hinanden.
Alternativet var at presse svæveflyvningen ned i et generisk sportsklubsystem, som Holdsport, GoMember og deres slægtninge. Fine systemer ... til fodbold. De er bygget til kampprogrammer og træningstider. De ved ikke, hvad en flyvedag er. De ved ikke, at en vagt kræver en kvalifikation, eller at et fly ikke bare er "en bookbar ressource", men noget der skal til eftersyn, kan meldes ud af drift og har en kutyme knyttet til sig om, hvem der må flyve det osv.
Og det er dér, den generelle pointe ligger, som er værd at tage med, uanset branche:
De bedste produkter bliver bygget af folk, der selv er brugere. Ikke fordi de er dygtigere udviklere, men fordi de kender de mange små detaljer, som ingen kravspecifikation nogensinde fanger.
Hvorfor jeg ikke byggede det i Joomla
Nu skal jeg passe på her, for jeg har brugt et kvart århundrede på at forsvare Joomla, og jeg gør det stadig gerne.
Men Startstedet er bygget i Laravel. Ikke i Joomla.
Og nej, det er ikke fordi jeg er faldet fra troen.
Det handler om noget så kedeligt som at vælge det rigtige værktøj til den rigtige opgave. Joomla er et content management system. Det er født til at håndtere indhold, redaktører, menustrukturer, flersprogethed og rollebaseret adgang til sider. Det gør det virkelig godt, og det gør det bedre end de fleste tror.
Startstedet er ikke indhold. Det er en applikation.
Kernen i systemet er ikke artikler og menupunkter. Det er en domænemodel. En vagt, der kræver bestemte kvalifikationer. En byttebørs, hvor to instruktører kan bytte vagter uden at vagtplanlæggeren skal godkende noget, og hvor systemet selv kontrollerer, at byttet er lovligt. Og bookingregler, der er forskellig fra klub til klub, fordi kutymen er forskellig. En algoritme, der fordeler en hel sæsons vagter, så ingen bliver overset eller overbelastet.
Kunne det bygges i Joomla? Ja. Jeg har bygget større systemer på Joomla som framework før, og MVC-arkitekturen dér er langt bedre, end folk giver den kredit for.
Men "kunne" og "burde" er ikke det samme.
Tænk på det sådan her: Du kan sagtens køre en flyttebil på en racerbane. Den kører. Den kommer rundt. Men du har valgt et køretøj, der er optimeret til noget andet, og du kommer til at bruge din energi på at kompensere for det.
Da jeg var færdig med at tegne domænemodellen, var svaret nærmest givet: over 80 % af det, jeg skulle bygge, ville ligge uden for det, CMS'et bidrog med. Så ville jeg reelt bruge Joomla som en indpakning omkring min egen applikation. Og så kan man lige så godt bygge applikationen direkte.
Så her er min holdning, og den gælder også, hvis du sidder med et projekt lige nu:
- Skal brugerne primært læse indhold, som andre redigerer? Så er Joomla oftest det rigtige valg. Færre bevægelige dele, hurtigere i luften, billigere at vedligeholde.
- Skal brugerne primært udføre noget som booke, godkende, planlægge, beregne, bytte? Så er du i gang med applikationsudvikling, og så skal du vælge derefter.
Værktøjet skal følge opgaven. Ikke omvendt. Alt andet er, når man er ærlig, bare vanetænkning forklædt som ekspertise.
Fire arkitekturvalg jeg ville træffe igen i morgen
Her bliver det lidt teknisk. Spring til næste afsnit, hvis kildekoder ikke er din ting. Men jeg tror, du kan bruge princippet bag hvert punkt, selvom du aldrig har skrevet en linje PHP.
1. Egen installation og database til hver klub
Startstedet er det, man kalder single-tenant. Hver klub får sin egen installation, sin egen database og sit eget domæne.
Det er den dyre løsning i drift. Det er også den, der betyder, at en klubs data aldrig kan lække over i en andens, at en klub kan tage sine data med sig, hvis de vil noget andet, og at jeg kan sove om natten, når vi taler GDPR.
Bekvemmelighed må aldrig trumfe ansvar for andres data.
2. Én delt kerne, mange installationer
Bagsiden af single-tenant er indlysende: skal jeg vedligeholde tyve kodebaser?
Nej. Kernen ligger som én delt Composer-pakke. Klubbernes installationer trækker den samme kerne, og opdateringer rulles ud centralt. Én rettelse, alle klubber. Det er den samme tankegang, som når man opdaterer sine udvidelser ét sted i stedet for at rette i core-filer. En synd jeg har brugt alt for mange timer af mit liv på at rydde op efter hos andre.
3. Klubbens sprog, helt ind i kildekoden
Det her er nok mit vigtigste råd til enhver, der bygger domænespecifik software.
I databasen hedder det ikke resource og event. Det hedder flyvedag, spilvagt, instruktør, materielansvarlig.
Hvorfor betyder det noget? Fordi den dag, en klub ringer og siger "vores instruktørvagt skal kunne dække to fly samtidig", så skal jeg ikke først oversætte deres virkelighed til min abstraktion, finde ud af hvor instruktørvagten gemmer sig i en generisk bookings-tabel og bagefter oversætte tilbage. Kildekoden og virkeligheden taler samme sprog.
Generiske abstraktioner ser elegante ud på et whiteboard. De koster dyrt hver eneste gang virkeligheden ringer.
4. Mobilen først og jeg mener det bogstaveligt
Brugeren står på en flyveplads. Det blæser. Solen står ind i skærmen, og der er 4G på en god dag.
Alt, hvad der kræver mere end tre tryk, bliver ikke brugt. Så simpelt er det. Der findes ikke et desktop-flow, som "også lige skal virke på mobil". Der findes et mobilflow, som også fungerer fint på en stor skærm.
Det svære var ikke kildekoden
Nu til den del, ingen fortæller dig om.
Kildekoden tog tid, men koden var det trygge sted. Jeg har skrevet PHP siden før nogle af mine kunder blev født. Det svære var alt det, en kunde plejer at tage sig af.
Prissætning. Jeg har skrevet et helt indlæg om, hvorfor jeg ikke bare trækker en pris ud af ærmet på kundeprojekter. Så skal man prissætte sit eget produkt, og opdager, at det er sværere. For lav pris signalerer hobbyprojekt og gør produktet umuligt at drive forsvarligt. For høj pris, og en frivillig forening med et beskedent kontingent siger pænt nej tak. Jeg landede på ét beløb for alle klubber, uanset størrelse, fordi jeg ikke gad have en samtale om medlemstal hver eneste gang. Gennemsigtighed er også en feature.
At sige nej. Hver eneste klub, jeg har vist systemet, har haft mindst én god idé. De var faktisk gode, de fleste af dem. Men et produkt, der siger ja til alt, bliver til tyve klubbers særløsninger i én kodebase, og så er jeg tilbage ved det, jeg startede med at ville løse. Der findes et roadmap. Det er offentligt. Det er min måde at sige "ikke nu" uden at sige "aldrig".
Ildsjælefælden - igen. Her er den ubehagelige erkendelse: Hvis jeg byggede Startstedet forkert, ville jeg bare selv blive den nye ildsjæl, som klubberne var afhængige af. Det er derfor, hver klub har sin egen database, kan eksportere alt, får daglig backup og ejer sit eget domæne. Et produkt, der kun overlever så længe én bestemt person gider, er ikke et produkt. Det er en risiko med en hjemmeside foran.
Og så er der den sidste, som ingen advarede mig om: Man er sin egen værste kunde. Man ombestemmer sig, man forgylder detaljer, ingen lægger mærke til, og man har ingen deadline, fordi der ikke er nogen at skuffe. Jeg endte med at give mig selv en lanceringsdato og behandle mig selv præcis så hårdt, som jeg ville behandle et kundeprojekt.
Det virkede. Det var ikke rart.
Hvad Startstedet kan i dag
Kort og faktuelt, for det er ikke her, salgstalen hører hjemme.
Startstedet er et klubsystem bygget specifikt til danske svæveflyveklubber. Det består p.t. af 14 kernemoduler: flybooking, vagtplanlægning med roller, kvalifikationstjek og byttebørs, flypark med eftersyn og vedligehold, kalender med tilmeldinger, vejrstation med METAR og TAF, beskeder og kanaler, medlemsadministration, dokumentmanager, formularer, KlubNyt og et dashboard, der samler flyvedagen ét sted.
Hver klub får egen installation, egen database, eget domæne, SSL, daglig backup, GDPR-compliance og løbende opdateringer. Det koster 399 kr. om måneden ekskl. moms - uanset om klubben har 30 eller 300 medlemmer.
Det er ikke gratis. Det er heller ikke meningen. Gratis systemer bliver vedligeholdt, indtil ildsjælen brænder ud, og så står klubben det samme sted igen.
Kunne det samme gøres for din branche?
Her er grunden til, at jeg overhovedet skriver det her på en Joomla-blog:
Svæveflyvning er ikke særlig unik. Det er bare mit eksempel.
Kajakklubben, køreskolen, maskinstationen, dyreklinikken, entreprenøren med tyve mand i marken. Alle sammen sidder de med et generisk system, der er tvunget til at passe, og en Excel-fil ved siden af, som indeholder den halvdel af virkeligheden, systemet ikke kan rumme.
Den Excel-fil er hele forretningscasen. Den er facit på, hvad softwaren burde have kunnet.
Jeg bygger stadig hjemmesider og webshops i Joomla, og det bliver jeg ved med. Men jeg bygger også systemer og efter Startstedet ved jeg præcis, hvad det kræver at gøre det ordentligt, fra domænemodel til drift til den dag, nogen ringer og har fundet en fejl.
Har du en Excel-fil ved siden af dit system, så lad os tage en snak om den.
Til sidst, tilbage til lørdag morgen i maj.
22 piloter på en flyveplads. Men denne gang har de set vagtplanen på telefonen i bilen på vej derud. Instruktøren ved, hvilke elever han/hun skal flyve med. Eleven ved, hvem der er dagens instruktør. Ham, der meldte afbud i går klokken 22, gjorde det i systemet, og hans vagt blev taget af en anden 40 minutter senere, uden at nogen skulle ringes op.
Det er ikke raketvidenskab. Det er bare software, der er bygget af én, der selv har stået i klubhuset.
Og det, tror jeg, er den eneste rigtige grund til at bygge noget som helst.
