Developer Summit, Arkitektur och affärsnytta
Jag var på Developer Summit förra veckan och gick mest på arkitekturspåret.
Ett genomgående tema var att vi (systemutvecklare och arkitekter) måste närma oss verksamheten. Ett annat tema var att man måste inse att det tas en hel del arkitekturbeslut på utvecklarnivå.
Det första temat av dessa är en sak som jag själv tagit för givet, men jag tror det beror på att jag jobbade flera år på en ekonomiavdelning innan jag blev systemutvecklare. De som blivit tekniskt skolade och egentligen aldrig sett system från ett process- och användarperspektiv måste förmodligen väckas, men om man anser att det är ett paradigmskifte att se systemutveckling som en möjliggörare av affärer så tycker jag att man nedvärderar en massa duktiga människor runt om i världen.
Det andra temat känns lite lösryckt utan en omfattande diskussion om vad arkitektur är. Vi använder i princip samma yrkestitel oavsett utövarens abstraktionsnivå. I ett sammanhang kallar man det arkitekturbeslut när man väljer mellan att använda statiska metoder eller en singleton och i ett annat sammanhang när man beslutar hur många geografiskt åtskillda datacenter man behöver.
Jag tycker, i princip, att man överlåter rätten att besluta saker nedanför sin egen abstraktionsnivå i samma stund som man lämnar över sin design till den som ska implementera. Jag skrev här att jag tycker en arkitekts roll är att samla ihop kunskap utanför sin organisation och sprida den inom sin organisation. Sett ur det här abstraktionsperpektivet gör det att nästan alla inom en systemutvecklarorganisation förväntas aggregera information och förmedla den till de som aggerar innom nästa abstraktionsnivå. I förlängningen betyder det även att man måste förmedla kunskap till den som står ovanför sig i abstraktionstrappan eftersom finkorniga implementationsdetaljer kan förhinda en optimal lösning.
Det handlar inte längre om att man kliver högre och högre ju duktigare man blir, det handlar om att hitta den abstraktionsnivå man trivs i och utveckla sig inom den.
Kontinuerlig integration i stället för möten.
Jag har ganska ofta hamnat i diskussioner om hur vi ska lösa ett spcifikt problem och vad användaren egentligen vill lösa med sin ändringsbegäran. Det är inte ovanligt att det hade gått fortare att implemenera alla möjliga lösningar och låta användaren välja vilken som är rätt än att diskutera kring det.
Om vi har en fungerande kontinuerlig integration som genererar något som går att leverera skulle vi i många av dessa fall kunna implementera flera olika lösningar och låta kunden avgöra vilken lösning som ska användas.
Jag har hör talas om organisationer som tagit kontinuerlig integration så långt att de skapar Virtual PC filer med systemet färdigistallerat som en del av det dagliga bygget. Det betyder att även om du har serverprogram som en del av produkten kan du göra snabba leveranser.
Kontinuerlig integration och försäljning
Jag har ofta hamnat i situationer där säljare lovat funktionalitet till existerande och presumtiva kunder. Funktionalitet som inte funnits och som ofta krävt omfattande övertidsarbete och fulhackande för att få klar. När utvecklare, mer eller mindre högljutt, protesterar mot detta förfarande brukar det antingen skrattas bort eller förklaras med vi inte förstår säljprocessen.
Väldigt ofta hinner man inte heller testa dessa framstressade funktioner vilket hur som helst leder till att mottagaren blir missnöjd med leveransen.
Förutsatt att man tagit fasta på mitt tidigare råd att ha installerbara dagliga byggen föreslår jag att man i stället levererar det som finns och uppdaterar med ny funktionalitet varefter den blir färdig. Med kortare leveransintervall får alla inblandade en större framgångskänsla. Detta fungerar förmodligen inte för alla typer av system, men väldigt många gånger är det inte kritiskt om man introducerar ett fel som en regressionstest skulle ha hittat. Risken är ganska stor att ett testförfarande som bara utförs ett par gånger om året i alla fall missar mer än ett som utförs varje dag. Dessutom ‘vet’ mottagaren att den typen av fel kan åtgärdas ganska snabbt eftersom man levererar ofta.
Jag tycker inte att man ska behöva vara rädd för att leverera ofta. Ett sätt att dämpa den rädslan är att ha en väl fungerande automattestnings- och byggmiljö.
