Den tekniska förändringstakten är högre än någonsin. Det händer mycket just nu. Bla, bla, bla.

Det är mycket snack om att det är så mycket nytt inom it hela tiden, men om man tänker efter är det samma gamla grejer som tuggas om igen: molnet, nosql, mikrotjänster, containrar, maskininlärning, serverlösa applikationer, Javascriptramverk, och så vidare. Till och med agilitet.

Grejen är att olika företag tar sig an ”nya” företeelser vid olika tidpunkter. Så det är alltid någon som gör något ”nytt”.

Men behövs det inte något verkligt omvälvande igen snart? Och vad skulle det i så fall vara?

Läs också: 9 myter som står i vägen för lyckad dataanalys

Här har vi ett problem. För att något ska bli omvälvande krävs det ju att man inte känner till det i förväg, innan det händer.

Någon måste ta tag i och spekulera om vad som skulle kunna bli nytt och omvälvande. Jag anmäler mig som frivillig. Här är tre förslag:

Imperativ revansch
Den imperativa paradigmen för programmering är nog det mossigaste man kan tänka sig inom systemutveckling just nu. Den går ut på att skriva kommandon rätt upp och ner i den ordning de ska utföras och att förändra tillstånd på vägen. Med andra ord att i detalj berätta för en dator vad man vill att den ska göra.

Det här sättet att jobba, som var normen för några årtionden sedan, anses i princip vara roten till allt ont inom mjukvaruutveckling just nu.

Men tänk dig att en dag om några år, eller månader, så är det någon smart programmerare som får nog. Personen tröttnar på att trassla in sig i lambdafunktioner. Han, eller hon, tål inte ens att hålla reda på klasshierarkier: ”Vad håller jag på med, varför skriver jag inte bara vad jag vill att programmet ska göra?”

Det här blir snabbt en rörelse, med akronymen PJDI (Please Just Do It). Snart kommer det språk med alla objektkonstruktioner och funktionell funktionalitet bortrensad. Och vittnesmålen strömmar in, man blir klar med projekt i tid, inom budget, med mycket färre personer än tidigare. Ståupp-scrum-möten behövs inte alls i samma utsträckning längre, eftersom man inte behöver förklara för varandra hur närmast esoteriska konstruktioner fungerar.

Serverlöst på riktigt
Om serverlösa applikationer, som egentligen inte är serverlösa, är så himla bra för att man inte behöver bry sig lika mycket om servrar som tidigare, vore det inte då vettigt att strunta i servrarna helt och hållet?

Hur skulle det se ut?

Elementärt, mina kära läsare. Applikationer körs helt på klienterna. Servrars enda uppgift blir tillhandahålla ny, och uppdaterad, mjukvara till klienter och att lagra data.

Men prestanda då? Tja, lite lastbalansering för att tillhandahålla nedladdning av mjukvara och åtkomst till data kan behövas. Men det är i princip inget som utvecklare behöver bry sig om.

Tänk på fördelarna för utvecklare. De behöver inte bry sig om kniviga prestanda- och låsningsproblem på servrar. De låsningar som kan uppstå, vad gäller data, hanteras av specialiserade dataservrar.

Läs också: Topplista: här är de 10 största riskerna på webben

Även här behövs en ny akronym. Kanske COC (Client Obsessed Computing)?

Slutar bygga mjukvara
En vacker dag börjar en ung, smart vd som saknar teknikbakgrund fundera på det rimliga i att mjukvaruutveckling är den enskilt största kostnadsposten på företaget som personen basar för. Vore det inte smartare att sluta utveckla egen mjukvara och bara använda färdiga tjänster? Då slipper man ju kostnaderna, fastän intäkterna fortsätter komma in.

Strategin visar sig fungera hur bra som helst. Anställda som klagar på att de saknar viss funktionalitet ombeds byta jobb. De som är kvar kör entusiastiskt vidare med de tjänster som finns tillgängliga. De som är lite äldre funderar på varför de har ägnat hundratals, kanske till och med tusentals, timmar åt att sitta på möten för att fastställa kravspecifikationer för ny mjukvara. Till ingen nytta.

Det här sättet att jobba blir populärt över hela världen. Akronymen som beskriver det är OVNSD (Only Value No Software Development).