Sedan XML’s tillkomst i slutet av 90-talet och dess assimilering in i Java EE och Spring så har olika organisationer till synes oberoende av varandra nått samma slutsats:
“Vi borde skapa ett verktyg som låter icke-programmerare göra programmerares jobb med hjälp av XML!”
Exempel kan hittas i en mängd verktyg, bibliotek och ramverk som används i industrin, exempelvis Spring (eller Seam eller Struts) där stora delar av applikationer kunde flyttas ut i XML-konfigurationsfiler. Ett annat exempel är Cucumber, ett BDD-ramverk, som utvecklats i syfte att ge icke-utvecklare möjlighet att skriva tester med en syntax som är mycket snarlik skriven engelska.
Goda intentioner
Intentionerna bakom detta är, som alltid, goda. Kanske är det organisationer där komplexa verktyg kräver att programmerare manuellt gör ändringar i kodbasen för att personer i andra roller ska kunna göra sitt jobb. Man kan även föreställa sig att programmerarna gör detta utöver sina vanliga utvecklingsuppgifter och på så sätt blir en flaskhals, vilket orsakar problem på andra håll i företaget. En naturlig reaktion på detta är kanske att försöka befria programmerarna från dessa arbetsuppgifter genom att ge icke-programmerare möjlighet att göra samma uppgifter enbart genom att skriva XML (eller andra markup-språk som JSON, YAML, HAML eller till och med fullfjädrade programmeringsspråk som Python eller Ruby).
Ett annat skäl till att detta sker kan vara att man vill bygga bort de flaskhalsar vilka uppstår när man har sin organisation uppdelad efter kompetens, såsom team med testare och team med utvecklare och team med affärsanalytiker. Dessa uppdelningar skapar givetvis beroenden som kräver överlämningar vilka i sin tur tar tid. Antagandet är här att om man kan ge dessa möjligheten att arbeta oberoende av varandra, då har man omintetgjort denna tidskostnad.
Resultatet är oftast dåligt. Ett vanligt problem är att den logik som skrivs med markup-språk kan ge upphov till obskyra feltillstånd djupt inne i det verktyg eller ramverk som det interagerar med. Att debugga och åtgärda detta är ofta energikrävande och kostsamt.
Feltänkt från början
Istället för att spara tid för icke-utvecklarna leder det istället till att de tvingas söka hjälp av utvecklarna själva och vips så är man tillbaka på ruta ett. Organisatoriskt kan detta bli problematiskt, då ägandeskapet kan te sig oklart. Vems ansvar är det att åtgärda ett fel i ett system som utvecklare förvaltar, men där andra äger logiken som exekveras däri?
Vi vill dock hävda att detta är feltänkt från början. Istället för att sträva efter att med tekniska hjälpmedel dela upp bolaget i programmerare och icke-programmerare med vattentäta skott emellan sig så vill vi istället att man går den totalt motsatta vägen: samla programmerare och icke-programmerare i tvärfunktionella team!
Utöver att kommunikationsvägarna blir kortare så gynnar detta även kunskapsspridning mellan personer med olika kompetenser. Ju mer programmerarna lär sig om bolagets affärssida, desto lättare blir det för dem att bygga funktionalitet som löser de specifika problem som företaget står inför, istället för att gissa sig fram och bygga generella lösningar.
Därför vill vi uppmana de som försöker lösa sina organisatoriska problem med XML att istället skapa tvärfunktionella team och samtidigt förpassa logikhanterande XML dit det hör hemma: på historiens skräphög.