Domain-Driven Design – en ögonöppnare?

Enligt undersökningar gjorda av The Standish Group så anses cirka hälften av alla mjukvaruprojekt som misslyckanden. Med tanke på att de utfört dessa studier regelbundet sedan 90-talet så utgår vi ifrån att rapporterna är högst tillförlitliga och kan tas på allvar.

Domain-Driven Design – en ögonöppnare?

Domain-Driven Design – en ögonöppnare? 2560 1709 C.A.G

Notera att vi för enkelhetens skull enbart pratar om agila projekt vilka är 2x mer sannolika att avslutas med framgång jämfört med traditionella (läs vattenfall) projekt. Även om dessa misslyckanden kan vara av olika grad och betydelse för slutprodukten så är det ett tecken på att mjukvaruindustrin inte rört sig särskilt mycket åt rätt håll (eller rör sig väldigt långsamt i alla fall).

Lägg då till de tekniska kliven industrin har gjort det senaste decenniet, möjligheter med molnet och floran av innovationer. Nya tekniker som borde göra det lättare för oss att göra mer nytta för verksamheterna och ändå står siffrorna ovan nästan still. Att det finns en mängd anledningar till den här oförmågan att lyckas såsom byråkrati, oklara direktiv/specifikationer, otillräckliga resurser och storleken på projektet är väl känt. Men även när det inte är någon av dessa anledningar som är skurken så verkar vi ofta misslyckas.

 

Mjukvaruentropi

Vid uppstart av projekt ser vi vanligtvis optimistiskt på de högt uppsatta målen vi satt. Vi vill skapa ett bra effektivt team där alla trivs och bidrar. Någonstans är det uttalat att utvecklarna ska ha som mål att skriva ”clean code”, skriva tester, följa ”best practices” och beprövade mönster som finns. Koden ska vara lika logisk och lättförståelig om en vecka, månad eller ett år efter att den satts i produktion.

Sedan går det några år eller månader i vissa fall och vi (eller någon annan) behöver göra ändringar i det som vi skrivit relativt nyligen. Till vår stora förvåning märker vi att produkten (eller version 1 utav den) redan har divergerat från verksamhetens verklighet. Koden upplevs redan svårförståelig och svår att underhålla samt ändra i.

Faktum är att i de allra flesta fall, även när första version av produkten är klar eller när projektet är klart, så innebär det inte att koden är färdigskriven. För all framtid därefter så kommer vi att behöva ta hänsyn till nya features/funktioner, buggfixar etc.

Saker runt oss förändras så även om vi inte bygger nya funktioner blir vi tvungna att ta hänsyn till en föränderlig värld. I sådan värld måste infrastrukturen kontinuerligt uppdateras och underhållas vilket har effekt på vår produkt vare sig vi vill det eller inte.

Ett exempel: Nyligen fick jag i uppdrag att ”återuppliva” en gammal wpf applikation som inte hade kompilerats på några år. För att till slut lyckas få igång denna i produktion så behövdes nya versioner av Crystal Reports installeras på de windows servrarna där den var produktionssatt. Den här uppdateringen ledde till ett antal störningar på andra system installerade på samma servrar. Detta trots att inga nya funktioner tillkom.

Desto längre vi är på samma ställe förändras vår förståelse av verksamheten. Ny förståelse gör att vi ibland inser felaktiga antaganden vi haft tidigare. Dessa har vi i sin tur baserat och skrivit kod på. Även om första release redan är ute och körs i produktion och till synes fungerar innebär de omogna antaganden en teknisk skuld att ta hänsyn till i framtida releaser.

 

Vad kan vi göra bättre?

Finns det något vi redan känner till som vi gör fel i projekten? Varför skriver vi inte kod vi ämnar att skriva, som är förståelig nog och går att bygga på för nästa person ett år senare? Som inte innebär att vi redan efter första leveransen får en teknisk skuld som tynger oss hädanefter. I kommande inlägg på vår webb så tänker jag högt om ämnet Domain-Driven Design eller snarare om avsaknaden av den.

 

Vid pennan/ Adis Mesevic, senior systemutvecklare C.A.G Arete

Kontaktperson

Annika Rogneby

+46 70 687 33 08

annika.rogneby@cag.se

X
X