Johan babblar på.

Jag försöker oftast inte vara språkpolis, mest för att jag inte är tillräckligt säker på min egen förmåga, men särskrivningar kan få mig att gå i taket.

I många fall kan man förstå vad skribenten egentligen ville säga, men ibland blir det helgalna syftningsfel. (Jag tänker inte komma med en massa exempel, det finns gott om sådana på skrivihop.nu)

Här, här och här finns fler artiklar i ämnet som jag hittade när jag började googla lite. Verka som om jag är några veckor efter som vanligt.

Det är lite kul att rättstavningsfunktionen i Firefox tycker att man ska skriva sär skrivningar.

Rädslan för att dyka upp i mobbningstatistiken gör att en skola i min närhet hellre arbetar för att flytta på de drabbade än att ta tag i problemen.

Trots att föräldrar i flera år, oberoende av varandra, har påpekat en speciell elevs olämpliga beteende så tar skolan inte tag i problemet. Däremot sätts stora insatser in för att dämpa de elever som blir stökiga pga den kränkande behandlingen. Insatser från skolan som i sig själva i en del fall varit direkt kränkande mot de redan utsatta eleverna.

Men är det inte bättre att synas i statistiken? Då syns det ju att skolan tar tag i problemet. Jag bli klart misstänksam på skolor som ligger långt under snittet för rapporterad mobbning. Det är ju fortfarande en princip slumpmässigt utvalda barn de jobbar med. Stora statistiska skillnader brukar i de fallen snarare bero på hur man redovisar fakta än hur det ser ut i verkligheten.

I det här fallet verkar skolan tycka/tro att det ser bättre ut att man tar krafttag mot stökiga elever, än att man erkänner att mobbning är ett problem på skolan. Det skickar dessutom signaler till alla andra elever att det är dumt att protestera mot kränkande behandling.

Jag har ändrat uppfattning, men orkar inte skriva om det på svenska.

Microsoft försöker få Jamie Cansdale att ta bort funktionalitet från TestDriven.NET.

Jag tycker Microsoft gör riktigt fel. Kommer någon verkligen köpa Visual Studio för att de vill få TestDriven att fungera? De företag som är så snåla att de använder gratisversionerna i verksamheten kommer inte betala ändå. Det är fortfarande möjligt att köra sina unit-tester utan för Visual Studio så TestDriven.NET motiverar inte den kostnaden.

Om Microsoft är rädda för att det ska komma en massa andra tillägg till Express-versionerna borde de göra licensen tydligare. Det är inte så svårt att tala om att all utökning av produkten är otillåten. Om det dessutom är sant att de har samma licens för betal-versionerna så borde de stoppa alla tillägg som inte kommer via VSIP-programmet.

Det här sättet att behandla utvecklarsamhället får mig att använda SharpDevelop och MonoDevelop för all utveckling som jag inte gör under arbetstid.

Om alla studenter som funderar på .NET gör likadant så försvinner incitamenten att köpa Visual Studio när de börjar programmera som yrke. de kanske till och med hoppar av .NET-tåget för en annan utvecklings- och driftmiljö.

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.

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