Revenge of the nerds (Getting Real)

När jag läste den här boken för ett år sedan så valde jag att inte kommentera den men eftersom den blivit en guide för så många nya utvecklare så vill jag ändå skriva några rader.

"Getting Real" en bok av 37Signals vinklar ett utvecklarperspektiv och ser det inte alls från en beställares. Den andas "Revenge of the nerds" och hyllar Agile Software Development, vilket är en metodik som är en reaktion mot UML-diagram, funktionsspecar, RUP, möten med chefer och kunder. Det går ut på att aldrig skriva ett dokument som beskriver hur en leverans ska se ut, utan istället hålla frågan öppen och se vart åt det barkar. Passar säkert jättebra när man utvecklar första versionen av en produkt där det än så länge inte finns en beställare. Men om det finns en beställare, en budget och beroenden från andra grupper så är Agile helt förkastligt. Det finns inga garantier att man ska få det man önskar utan är bara en utvecklares önskan att få sitta ostörd och jobba utan krav.

Boken har många absoluta påstående och är ibland skrivna som religiösa sanningar:

• "If you can't fit everything in within the time and budget allotted then don't expand the time and budget. Instead, pull back the scope. There's always time to add stuff later — later is eternal, now is fleeting."
• "Don't follow the leader"
• "You don't need to nail that perfect shade of green in week two. You don't need to move that "submit" button three pixels to the right in week three. Just get the stuff on the page for now. Then use it. Make sure it works. Later on you can adjust and perfect it."
• "Don't be a yes-man", "Make each feature work hard to be implemented.", "Every new feature request that comes to us — or from us — meets a no. We listen but don't act. The initial response is 'not now.'"
• "Don't expect to get it right the first time. Let the app grow and speak to you. Let it morph and evolve. With web-based software there's no need to ship perfection."
• "There are too many meetings. Push back on meetings that do not make sense or are unproductive."
• "So don't hire. Really. Don't hire people. Look for another way."
• "When it comes time to hire, don't think you need a guru or a tech-celebrity. Often, they're just primadonnas anyway. A happy yet average employee is better than a disgruntled expert."
• "Don't be afraid to say no to feature requests that are hard to do. Unless they're absolutely essential, save time/effort/confusion by leaving them out."
• "Don't just pick tools and practices based on industry standards or performance metrics. Look at the intangibles: Is there passion, pride, and craftmanship here?"
• "Don't worry about design, if you listen to your code a good design will appear...Listen to the technical people."
• "Don't write a functional specifications document"
• "Don't Do Dead Documents"
• "Avoiding functional specs is a good start but don't stop there; Prevent excess paperwork everywhere."
• "Build, don't write. If you need to explain something, try mocking it up and prototyping it rather than writing a longwinded document."
• "Don't waste your time typing up that long visionary tome; no one's going to read it."

Det finns även rätt självklara saker som man kan skriva under på:

• "Don't use acronyms or words that most people don't understand. Don't use internal lingo. Don't sound like an engineer talking to another engineer. Keep it short and sweet. Say what you need to and no more."
• "You don't need to be a swiss-army knife. You can just be a screwdriver. You don't need to build a diving watch that's safe at 5,000 meters if your customers are land-lovers who just want to know what the time is."
• "Be as open, honest, and transparent as possible. Don't keep secrets or hide behind spin. An informed customer is your best customer."
• "Also, don't create a culture of fear surrounding bugs. Bugs happen. Don't constantly seek someone to blame."

AOP & EAI - två av samma sort

AOP är för objekt som EAI är för applikationer. Både AOP och EAI är att fokusera på symptomen i stället för på orsaken.

SOA ur olika perspektiv

SOA är en motreaktion till monolitiskt applikations-orienterade IT-landskap. När man frågar folk om en definition av SOA så finns det en grund i problemen med de klassiska applikationerna. Alla ser SOA olika men samtidigt har de problem som exempelvis redundant funktionalitet och information, svårigheten att integrera funktion/data och omöjligheten att förändra applikationerna med tiden i banktanke.

VD:n
"SOA ger IT den rörlighet som krävs för att kunna driva ett företag/koncern där verksamheten förändrar sig i snabb takt med avseende på out-sourcing, omorganisationer, sammanslagningar, konsolideringar, m m."

IT-chefen
"SOA suddar ut applikationsgränser som ersätts av mindre sammankopplade tjänster som kan återanvändas, kopplas in/ur baserat på i tiden alltid föränderliga policies."

Processansvarige
"SOA underlättar automatiseringen av processer (BPM) som går på tvären genom affärsområdena i en organisation."

Affärsområdesansvarige
"SOA ger möjligheten att snabbt förändra verksamheten inom en funktion istället för att vara slav under LOB-applikationerna."

Applikationsansvarige
"SOA river ned applikations-silos och ersätter dom med virtuella applikationsgränser som kontrolleras m h a policies."

Affärsutvecklare
"SOA är den arkitektur mot var man kan mappa verksamhetens tjänster direkt mot ett IT-stöd."

Driftteknikern
"SOA skapar en transparans av alla rörliga delar i IT-landskapet som man centralt kan kontrollera och administrera (ESB), precis som Microsofts Virtual Machine Manager (reklam) kontrollerar hela IT-infrastrukturen."

Integratören
"SOA medför att jag kan lägga EAI åt sidan och ägna mej åt viktigare saker."

Systemarkitekten
"SOA resulterar i att när nya krav ska realiseras så finns redan ett repository där säkert 90% av alla tjänster redan är implementerade vilket medför att min instats kan halveras i tid och pengar."

Systemutvecklaren
"SOA medför att jag måste lära mej XML."

Krönikörer och IT-sommelierer
"Bäst att hoppa på SOA-spåret även om jag är några år sen och skriva om hur man kan koppla ihop SOA med roller, metodik, taxonomi och metaforer och hur väl det sammanfaller med saker som jag sagt tidigare även det förvirrar mej själv mest av alla."

Bloggaren
"SOA har förvirrat en hel industri vilket jag kan dra fördela av genom att skriva den här typen av inlägg."

Utbildaren
"Undrar hur länge jag kan lura mina elever att SOA är EAI + Web Service innan jag måste skriva om min gamla integrationskurs från 90-talet."

Analytikern
"SOA har varit en riktig mjölkko när det kommer till buzz-words! Vad kommer härnäst?"

Applikationsutvecklaren
"Jag bygger några Web Services on-top av min applikation och vips så har jag en SOA, eller?"

BPM i vården

Tittade som vanligt på Uppdrag granskning som den här veckan handlade om hur mammografitester hamnade i arkiven utan att läkare hade granskat dom. I det här fallet hade den drabbade en cancertumör som aldrig upptäcktes på grund av att rutinerna inte fungerade.

Vanligtvis handlar det inte om liv eller död när rutiner brister, men det gör det i vården. Vad är det då för rutiner som brister och vad är rutiner över huvud taget? Rutiner innebär arbetssätt som tagits fram baserat på erfarenhet från tidigare fall och kunskap om dem. Att brista i sina rutiner innebär att man frångår arbetssättet och gör på något annat sätt.

Business Process Management (BPM) handlar om att skapa rutiner, automatisera rutiner, analysera erfarenheterna av rutinerna och förbättra rutinerna. Hade Sahlgrenska universitetssjukhuset automatiserat sina rutiner hade systemet upptäckt det här cancerfallet. Rutiner kommer alltid att brista p g a den mänskliga faktorn, även om SU verkar ha rena management problem dessutom.

BPM kommer spela en stor roll för att kvalitetssäkra rutinerna framöver, men i vården borde det implementeras omgående.