Gør det tidligt, gør det tit
Vandfaldsmodellen er død! Udviklingsprojekter er ikke delt op i pænt adskilte faser hvor man designer, implementerer, tester og til sidst binder man en pæn rød sløjfe om produktet og leverer det til kunden. I dag er det god skik at lave alle fire ting fra dag 1 til projektets afslutning. Ok, jeg går ud fra at det er kendt stof for alle. Der er bare en enkelt talemåde jeg stadigvæk synes hænger godt fast: "Make it work, then make it correct, and THEN make it fast".
Det første problem er at vi jo alle er klar over at man ikke kommer tilbage, hverken for at gøre det rigtigt og da slet ikke for at gøre det hurtigt. Ting som bliver udsat, bliver ikke gjort.
Det andet problem er langt mere alvorligt: Performance er ikke noget man bare lige patcher på bagefter. Det skal tænkes ind fra starten, god performance handler ofte om at vælge den rigtige datamodel og den er svær lige at skifte ud 90% igennem den afsatte tid. Og performance skal måles hele vejen igennem projektet, så man let kan se om ting bare bliver jævnt langsommere eller om det netop er implementeringen af en enkelt feature der pludselig koster 50% ekstra på stopuret.
Premature optimizations og micro-optimizations er selvfølgelig stadigvæk forbudt. Men det er netop pointen, hvis man måler performance kontinuert falder man ikke i fælden og optimerer på noget der ikke har betydning.
Test driven development er ikke godt nok mere. Jeg vil have Performance driven development.
Om Peter MakholmKommentarer (10)
Er det ikke "bare" at tilføje performance tests?
Altså, hvis du allerede kører test driven, development, er det vel ikke så kompliceret at tilføje en række performance test også?
Når det så er sagt vil det da glæde mig med mere optimeret kode - det jeg lavede i WordPerfect 5.0 på min Amiga adskiller sig jo ikke væsentligt fra det jeg laver med MS Word idag - og selvom jeg er klar over at clipart og andet "funstuff" fylder noget, så må man nok konstatere at MS Word nok aldrig kommer til at køre på en 8MHz maskine uden FPU, med 1MB ram og hvor programmet fylder ca. ½MB.
Det har i virkeligheden været min oplevelse at det er på konsolspil vi ser mest performance optimering og at det har været sådan længe (det vil så nok overgå til at være mobilerne inden så længe, men selv her har vi jo maskiner der kører med dual core 1GHz cpu'er og med 256MB ram og nogle GB storage).
-
0 -
0
Jeg er ret enig med dig.
God performance er godt. Men mindst lige så vigtigt er skalerbarhed. Kan man skalere op og/eller ud. Det er tit sværere at løse end at fikse rå perfromance. (host billetlugen host cpr-registeret)
Skalerbarhed er også sværere at teste, det kræver flere servere og/eller cpu'er. Cloud-hosting er noget man bør undersøge om man kan bruge til sin skaleringstest, da man kan få 10-20 servere i et par dage til testen til en billig penge. Men det kræver at man har en applikation der kan køre på en cloud løsning.
-
0
-
0
Det forekommer mig at der er et stort set parallelt problem med sikkerhed, har man først lavet en applikation hvor der ikke er taget hensyn til sikkerheden så bliver det noget af et pillearbejde at patche på bagefter, og der er en stor risiko for at glemmer eller overser noget.
Performance er nok generelt lidt sværere at efterimplementere, til gengæld er mindre end optimal performance typisk ikke helt så slemt som et sikkerhedshul.
Sikkerheden er selvfølgelig mest et problem for programmer som kommunikerer over internettet, eller håndterer fremmede filer. Men det er vist efterhånden undtagelsen frem for reglen at man kan skrive et program som er sig selv nok.
-
0
-
0
Sikkerhed er absolut ikke noget man bare klasker på bagefter. Ligesom interoperabilitet heller ikke er det.
Prøv f.eks. at rydde cpr-numemrer ud af alle applikatoner i den offentlige sektor - ingen tvivl om at det er det som vi skal, men ingen agil model kan levere varen.
Eller prøv at gøre EPJ-ssytemer interoperable med den samme model.
Agil udvikling forudsætter en meget klar arkitektur og principforståelse - hvis du ikke ved hvor du skal hen, så ender du hvor du et sted, du ikke har lyst til at være.
-
0
-
0
Et problem ved blot at lægge performancetest ind i testsuiten med alt det andet er at man ikke nødvendigvis har en ordentlig reference.
På Eclipse gør vi det, men byggeserverne, som afvikler testsne, er så ujævnt belastet at der af og til kommer falske negativer ind i rapporterne.
Og det er jo fredag, så:
http://www.dilbert.com/strips/comic/2010-08-11/
I modsætning til sikkerhed og interoperabilitet så er performance og skalérbarhed heldigvis noget man kan skrive enkle regressionstests til, så man ikke dummer sig ved uopmærksomhed.
-
0
-
0
Er det ikke "bare" at tilføje performance tests?
Det er ikke rocket-science, så i en vis grad er det "bare" at tilføje performance-tests og afvikle dem automatisk i et passende miljø.
Men det kræver også at man "bare" lige får indarbejdet det i sine rutiner at tjekke performance-rapporten på lige vis som man tjekker udviklingen i korrekte test-cases.
Det er svært nok at lave veldefinerede performance-tests, men det svære er at få folk til at skifte arbejdsstil.
... i det mindste leger vi ikke med flydende ilt der får det hele til at fryse.
-
0
-
0
Ud over at begge dele skal tænkes ind i designet, så tror jeg ikke at performance og sikkerhed har meget med hinanden at gøre i forhold til hvordan vi skal arbejde med det.
Sikkerhed handler meget om at vi enten har en kendt angrebsmulighed, eller også har vi ikke en kendt angrebsmulighed. Vi kan ikke på samme måde måle at sikkerheden skrider mere og mere i et system.
På den anden side kan performance til et vist punkt løses ved bare at tilføje mere jern. Jo, der findes aplpication-firewalls og andre ting der skjuler sikkerhedshuller, men min erfaring er at de ofte en en pine at arbejde med, jeg stoler ikke på dem og oftest primært beskytter mod på forhånd kendte problemer.
Så jo sikekrhed er vigtigt, men jeg tror ikke vi lærer meget af at håndtere sikkerhed og performance på samme måde.
-
0
-
0
Peter
Sikkerhed og performance hænger langt mere sammen og både kan og skal håndteres mede lignende mekanismer
Performance kan måles og det samme kan produktion af risiko. Men vi har mange forskellig emål for begge dele - taler vi start-stop performance eller evnen til omlægning? Og hvilken sikkerhedsparameter fokuserer man på - availability, integritet, fortrolighed etc.
Sikkerhed og performance hænger også sammen. F.eks. er det desideret dumt at vi starter med at identificere personer og devices, hvorefter vi er nødt itl at tilføre et enormt ineffektiviserende overhead og tykke perimeterwalls i forgæves forsøg på at beskytte de risici, vi selve skabte i første omgang.
Du KAN ikke beskytte en online geo-navigationstjenesetjenese a la Google Latitude/Maps, men tilsvarende BEHØVER du ikke bruge en krone eller overhead på at beskytte den samme funktion leveret af en Tom-Tom eller Garmin.
Problemet er at teknikkere fokuserr meget på performance og availability som man umiddelbart kan se - men de tunge sikkerhedsproblemer skaber man grundet manglende opmærksomhed i designprocessen. Og så spilder man enorme ressource på forgæves at lægge lov på de selvskabte problemer bagefter.
Ingen nok så agil process kan kompensere for arkitekturfejl - tværtimod, desto mere "agilt", desto værre lappeløsninger. Men agil udvikling kan med rettigdig omhu og grundlighed måske afsløre arkitekturproblemer tidligere.
-
0
-
0
Den lektion som man efter min mening burde drage er at vi taler 2 meget forskellige planer.
Måldannelsen og de tunge arkitektur og principafklaringer skal gennemarbejdes meget grundigt. Man kan bruge timeboxes i praksis, men det ændrer ikke på at det er spørgsmål som man ikke let kan ændre senere, så det er en art vandfaldsmodel uanset hvad man gør.
Selve implementeringen kan derefter STYRET af klare principper, arkitekturmodeller og strukturer, bedst gennemføres som agil udvikling hele tiden holdt op imod den overordnede model.
Hovedproblemet i den offentlige sektors it-projekter er ikke implementeringsprocessen, men grove fejl i måldannelsen. Offentlig systemudvikling har ikke rykket sig meget siden 60ernes planøkonomiske taylorisme.
-
0
-
0
>"Make it work, then make it correct, and THEN make it fast".
Man kan ikke sætte 110 legoklodser sammen til en figur der ligner den på vejledningen, før man kender alle klodser, deres form og farve, og hvor de skal sidde.
De bedste programmer jeg har set, igennem alle tider, er dem som er lavet af blot 1-2-3 kodere, som også har designet alt, og er gode til at lave brugervenlige programmer.
Teams med opdeling, og 117 folk i 8 forskellige afdelinger, det virker ikke, så enkelt er det.
Et fejlfrit spil (dem er der færre og færre af), har 1 lead programmer, og 1 assistant programmer.
Alle de spil som har 23 patches og aldrig virker, har et programmer team på 50 mand.
Lær af fejlene, og kom videre :)
-
0
-
0
