Johan babblar på.

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.

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ö.

Jag gjorde nyligen ett gästspel hos en gammal klient och fick en handfull kritiska fel i knät. Det visade sig sedan att de berodde på att ingen läst det sista jag skrev när jag var där för ett år sedan.

Som jag skrev här:

It is not enough to use the wiki to cross reference all the information about the current state, we also need to write down the discussions and misshaps that lead here. That way we can turn these vast amounts of information into knowledge that is transferable.

Det finns även terabytes med välskrivna fristående dokument där ute, men det är för svårt att hitta dem.

Det borde finnas ett centralt dokumentarkiv som är lätt att söka i, i alla organisationer. Jag tycker fortfarande att en wiki är en bra sak att ha, men en del dokument gör sig bättre som fristående enheter. Dessa dokument måste vara lätta att hitta. De måste lagras på en plats som är naturlig för folk att leta efter information på, annars är det bortkastad tid att skriva dem från början.

Personligen tar det alltid emot att skriva dokumentation för att jag vet att ingen kommer att läsa den. Jag har haft fler än en kollega som fylls ut dokument med dynga bara för att dokumenten ska bli långa och skrämma bort eventuella läsare.

Eftersom SharePoint Services är en del av operativsystemet nu så är det ganska lätt att skapa en central plats för dokumentation och kunskapsöverföring.

Så det här är ett utrop till alla projektledare och team-ledare: Snälla, ordna ett ställe där personalen kan hitta och skapa levande dokumentation. Alla kommer att tjäna på det i längden.

Jag är absolut ingen säkerhetsguru, men jag börjar nästan gråta varje gång jag klickar på ‘glömt lösenordet’ på en websida och får ett epost med mitt gamla lösenord som svar.

Hash-koda användarens lösenord tillsammans med ett slumpmässigt värde, som kallas salt. Spara hash-koden och saltet i databasen. När sedan användaren försöker logga in hash-kodar du det inskickade lösenordet tillsammans med saltet och jämför med den sparade hash-koden.

På så sätt behöver du inte oroa dig för att alla lösenord kommer på vift om din websida blir hackad.

Skaffa 2GB säker datalagring online!



När man gör dagliga byggen, vilket jag tycker är ett av baskraven för kvalitativ systemutveckling, bör man se till att bygget är så komplett och lätthittat att test och sälj själva kan installera den version de vill ha för stunden.

Det är en vedertagen sanning att det blir dyrare och dyrare att rätta fel ju längre man väntar. Om test kan verifiera en felrättning dagen efter den checkats in i källkodshanteraren i stället för att vänta till nästa sanktionerade release minskas både ledtider och kostnader.

För att detta ska fungera krävs att hela organisationen jobbar för att det dagliga bygget ska vara fullständigt. Det håller inte om någon sitter i hemlighet och checkar in obrukbar kod. Om man utvecklar för en specifik kund, som förväntar sig att se ständiga uppdateringar, blir det extra illa om någon i det dolda checkar in dålig kod. Det är ett problem som man inte kommer runt med enhetstester eftersom deras resultat går att manipulera.

Det krävs att alla jobbar för att det dagliga bygget alltid ska vara färdigt för release.