Inspect-and-adapt

For at få størst udbytte af sit webdesign i forhold branding, klarhed, usability, budskaber etc. er det vigtigt at være stærkt iterativt orienteret. Overordnet UI design er på mange områder et levende eksempel, hvor effektiv inspect-and-adapt praksissen omkring softwareudvikling virkelig kan være. Jeg læste en artikel på Joel on Software, som havde en meget interessant case på området.Sat på spidsen kunne parolen for artiklen være noget i retning af:

"Det er ikke negativt, når kunden kommer og vil have lavet noget om! Det er
værdiskabende, og går man mod det, leverer man en dårligere vare."

Inspect-and-adapt gælder hele vejen igennem et projekt og på alle niveauer:

1. Software deles ind i værdiskabende releases defineret af forretningen (product owner). For hver release vurderes feedback fra kunder og brugen af systemet (inspect) i forhold til den overordnede releaseplan med henblik på at definere nye releases endnu skarpere i forhold til forretningsværdi (adapt)

2. Resultatet af en sprint demonstreres (inspect), så kunder eller forretningen kan give nødvendigt feedback, som teamet kan reagere på (adapt)

3. Efter hvert sprint holdes et retrospective, som sikrer at sidste sprint vurderes grundigt af teamet i forhold til ting, der går godt og ting, der kan forbedres (inspect), og at der bliver sat handleplaner op for de væsentligste ting (adapt)

4. Hver dag holdes der team-standups, hvor arbejdet vurderes (inspect) op i mod den plan som teamet har lagt (adapt)

Produktudvikling: Amazon teknologi

Når man arbejder med web som primær platform for ens applikationer, så vil man også uundgåeligt komme til at beskæftige sig med performance og scalability problemer knyttet til den trafik, som et pågældende site måtte have.

Amazon som jo har enorm trafik på sitet. Eksempelvis har Amazon 3 millioner checkouts dagligt. For at kunne håndtere den slags trafik må man være mere kreativ end de fleste, hvad angår teknologi som henter data fra data stores. Dynamo er en blandt mange teknologier udviklet af Amazon til at håndtere disse krav:

Dynamo is designed to ensure that, typically, "99.9% of the read and write requests execute within 300ms"

Uanset det load, der måtte være på sitet så vil Dynamo sikre at read/write forespørgsler sker inden for 300 milisekunder for 99,9% af tilfældene. Ret vildt. Men hvad endnu vildere er, så er teknologien designet til at betragte hardware fejl som en naturlig del af dens eksistens:

Amazon’s software systems need to be constructed in a manner that treats failure handling as the normal case without impacting availability or performance.

Den slags problemer påvirker altså ikke ovennævnte performance. Imponerende ikke?

Hvis du vil læse mere om, hvordan Dynamo virker, så prøv at læs Dynamo: Amazon’s Highly Available Key-value Store

Innovation og Scrum/Agile

I mine øjne er der en fare for at kvæle innovation til fordel for kortsigtede leverancer med procesmetoder som Scrum. Hvis man tvinger udviklere til at have fokus på at levere hver måned eller oftere, så vil der ikke være meget overskud til at tænke innovativt... altså innovativt på den måde man ser i virkelig skelsættende produkter. Et godt eksempel er Apples produkter, som er gennemsyret af god innovation på produktudviklingsfronten både hvad angår materialer, hardware, software og samspillet imellem disse. Hvad er jeres holdning til dette? Har i nogle gode konkrete eksempler jeg kan poste her?