Du vet hur det är, speciellt om du är utvecklare. Vid varje givet tillfälle finns det ett gäng modeord som lägger beslag på mycket mental energi för många personer. Just nu befinner sig till exempel ”AI” väldigt högt upp på hajpkurvan.

Men de flesta modeord dalar i popularitet efter ett tag. Det kan ta ett år eller flera, men till slut börjar de att föra en tynande tillvaro.

Här är 9 exempel på modeord inom systemutveckling som har bleknat vad gäller lyster, med kommentarer av Jimmy Nilsson, vd på konsultföretaget Factor10.

Web services

I dag kan begreppet web services syfta på en mängd olika saker, allt från sajter till flera olika tekniska lösningar för kommunikation mellan mjukvaror på webben. Men några år från ungefär 2003 och framåt så betydde web services en kombination av språket XML för data, protokollet SOAP för kommunikation, språket WSDL för att beskriva tjänster och UDDI som var en lösning för kataloger över web services.

Web services sågs som en universell, standardiserad lösning för kommunikation mellan mjukvaror på webben. I dag fnyser många utvecklare med självaktning åt den här tekniken, som ofta beskrivs som tungrodd och komplex.

– Jag hörde faktiskt web services nämnas på ett möte i dag. Det användes som ett skällsord, säger Jimmy Nilsson.

Soa

Här snackar vi hajp så det räcker. Soa (service-oriented architecture) hade sin storhetstid ungefär samtidigt som web services, med vilket det var intimt förknippat. Det är en arkitekturmodell för mjukvara som går ut på att mjukvarukomponenter (services) kommunicerar med varandra.

Tanken var att det skulle ge bättre struktur och återanvändbarhet. I dag ses Soa ofta som en ganska klumpig modell. Men många av grundtankarna har levt vidare i form av mikrotjänster (micro services). Mikrotjänster kanske kan beskrivas ”lättvikts-Soa”.

Läs också: Soa har avlidit

XML

Syftet med språket XML är att ge ett standardiserat format för data som ska vara läsbart för både människor och maskiner. XML används fortfarande en hel del, men i många fall har det ersatts av Javascriptbaserade JSON.

UML

UML (Unified Modeling Language) är ett modelleringsspråk för mjukvara som skapades av amerikanska Rational på 90-talet. Bland skaparna märks svenske Ivar Jacobson. UML standardiserades första gången 1997 av OMG (Object Management Group).

I början av seklet sågs UML som ett modernt sätt att designa mjukvara, men liksom många andra tekniker från den tiden har det kommit att betraktas som komplext och tungrott.

– Det var ett tag sedan jag hörde UML nämnas. Problemet med UML var nog att det blev överutnyttjat, säger Jimmy Nilsson.

Rup

Rational Software som förvärvades av IBM 2003 låg inte bara bakom UML och flera olika typer av verktyg för systemutveckling. Företaget var också hemvisten för utvecklingsmetoden Rup (Rational Unified Process).

Redan i början av 2000-talet när Rup stod på höjden av sin popularitet fick det mycket kritik för att vara för omfattande och för komplext att arbeta med. I dag ser man sällan jobbannonser i vilka kunskap om Rup nämns som ett krav, men det händer ibland.

Rup beskrivs ofta som en ”vattenfallsmetod”, vilket inte är helt rättvist. Även om metoden (processen eller ramverket som den också kallas) bygger på distinkta faser nämns begrepp som iterationer, som i dag ses som ett agilt värdeord.

XP

Det är inte bara mer gammalmodiga utvecklingsmetoder som har hamnat i skymundan. Även den agila metoden XP (extreme programmering) verkar ha tappat i popularitet. Det var kanske den av de agila metoderna som fick mest uppmärksamhet i början av seklet.

XP innehåller många olika delar, varav parprogrammering kanske är den mest omtalade. Många företag som har börjat använda XP har nöjt sig med att anamma några av delarna. I dag har andra agila metoder, framför allt Scrum, ökat mer i popularitet än XP.

– Det är förfärligt att Scrum vann, om man kan säga så. Det finns mycket bra i XP, tycker Jimmy Nilsson.

Läs också: Google vill lära dig programmera med ny gratis-app

4G

Säg 4G och säkert 97 av 100 personer tänker på hyfsat snabb mobiltelefoni. Men på nittiotalet åsyftades språk och utvecklingsverktyg som var mindre fokuserade på detaljer än till exempel C/C++, Java och C#. Tanken var att utvecklare skulle bli mer produktiva och att det skulle krävas mindre utbildning och erfarenhet för att bli utvecklare.

I Sverige var det pc-baserade verktyget och språket Dataflex populärt. Med lite god vilja kan man kanske klassa databashanterare med utvecklingsmiljöer, som Microsofts Access och Borlands Paradox, som 4G-verktyg.

4G-trenden, vad gäller verktyg och språk, dog ut mot slutet av det förra seklet, i samband med webbens segertåg. Dels blev det problem med prestanda, dels med att bygga stora applikationer. Ibland var det också en del problem med samarbete i stora team och med att skräddarsy applikationer.

I dag kan man se moderna så kallade low-code-verktyg som efterföljare till de äldre 4G-verktygen. Grundtanken är den samma, att minimera arbete med detaljer under systemutveckling.

– Jag tycker att en del 4G-verktyg funkade bra till 80 procent. Det var de sista 20 procenten som var plågsamma, säger Jimmy Nilsson.

Client–server

Client–server är en arkitekturmodell som, liksom namnet anger, bygger på att körning av mjukvara fördelas mellan klientenheter och servrar. Den var mycket populär på nittiotalet och lever till viss del fortfarande kvar.

Vid en snabb titt påminner det här om arkitektur för webbapplikationer. Men det finns flera avgörande skillnader. För det första görs mycket mer bearbetning, och mer mjukvara är installerad, på klienterna i de flesta client–server-lösningar. Jämför med många webblösningar som bara kräver en webbläsare på klienterna. För det andra låg väldigt mycket fokus på relationsdatabaser i de flesta client–server-lösningar.

Ett omdöme om client–server-arkitekturer som man kan höra i dag är att de ofta bjuder på nedlastade klienter, vilket gör dem sårbara och svåra att hantera och uppgradera.

Läs ocksåNytt forskningsprojekt låter AI bygga banor till datorspelet Doom

Referensintegritet

På tal om databaser, här är ett begrepp som inte hörs särskilt ofta i dag, men som diskuterades mycket på nittiotalet. Referensintegritet (referential integrity) är enkelt uttryckt regler för hur data ska fördelas på flera tabeller i relationsdatabaser på ett säkert sätt.

Det kan till exempel innebära att man inte kan radera ett företag i en företagstabell, om det finns anställda på företaget kvar i en persontabell.

Lite äldre utvecklare med databaskunskaper har säkert koll på det här. Frågan är hur det ligger till med en del webbutvecklare, varav en del inte ens jobbar med relationsdatabaser längre.