Det STORA missförståndet
•Download as KEY, PDF•
0 likes•371 views
En beskrivning av konsekvenserna av att se programmering som tillverkning i stället för som en legitim form av design. Ett upprop till förändring. Talare är Joakim Holm från Adaptiv Sthlm AB
Recommended
Recommended
More Related Content
Viewers also liked
Similar to Det STORA missförståndet
Similar to Det STORA missförståndet (20)
More from Agila Sverige
More from Agila Sverige (20)
Det STORA missförståndet
- 1. Det STORA missförståndet Joakim Holm Adaptiv STHLM
- 2. ?
- 3. © 2001-2003, New Line Cinema
- 4. Det STORA missförståndet: Programmering = Tillverkning
- 5. Inom tillverkning... talar kunderna med arkitekterna, mest i designfasen är målet att få designen rätt från början konverteras ritningar till material som fogas samman till hus arbetar manuell arbetskraft (lägre utbildad, prispressad, utbytbar, opålitlig) utförs ett smutsigt detaljarbete som kunderna bör slippa
- 6. Inom systemutveckling... talar kunderna med arkitekterna, mest i designfasen är målet att få designen rätt från början konverteras ritningar till text som körs av en dator arbetar manuell arbetskraft (lägre utbildad, prispressad, utbytbar, opålitlig) utförs ett smutsigt detaljarbete som kunderna bör slippa
- 7. Mitt Budskap För att förändra synen på systemutvecklare från att vara orcher till något bättre måste vi själva förstå mjukvarans natur och i alla sammanhang utstråla detta.
- 8. Ritningar?
- 9. Ritningar?
- 11. "Det är svinkallt och allt vi ser är snö"
- 12. "Det är svinkallt och "Ooh, vi har ett varmt allt vi ser är snö" hu... ehh... ett hus!"
- 13. Design "Det är svinkallt och "Ooh, vi har ett varmt allt vi ser är snö" hu... ehh... ett hus!"
- 15. tid Den här delen Den här delen är design är tillverkning
- 16. recept för att tillverka program
- 17. Slutsatser
- 18. Slutsatser Systemutveckling är främst att designa program.
- 19. Slutsatser Systemutveckling är främst att designa program. Slutresultatet av designen är källkod.
- 20. Slutsatser Systemutveckling är främst att designa program. Slutresultatet av designen är källkod. En programmerare är främst en designer.
- 21. "... a source code listing (in any programming language) is really a software design." "... everything is part of the design process. Coding is design, testing and debugging are part of design, and what we typically call software design is still part of design. Software may be cheap to build, but it is incredibly expensive to design." (Jack Reeves, C++ Journal, 1992)
- 22. Om alla förstod detta... Kontinuerlig dialog med kunder och användare. Design hela vägen. Skisser är ett verktyg. Trial-and-error är en del av processen. Utbildning främst genom att gå bredvid. Proffs med yrkesstolthet och ansvarskänsla.
- 23. Språk är makt Spansk skogssnigel?
- 24. Ta makten över språket Säg aldrig... Säg i stället... "bygga [system]" "utveckla", "designa" "producera [kod]" "skriva", "författa" "design" "modellering" "arkitektur" "högnivådesign" "kodfabrik" "teamrum"
- 26. Hur länge ska vi tolerera att nyttan med våra liv reduceras?
- 27. joakim holm AGILE SOFTWARE DEVELOPER & COACH +46 70 773 76 29 joakim.holm@adaptiv.se blog: jockeholm.wordpress.com twitter: jockeholm
Editor's Notes
- God morgon! För att få höra det här blixttalet måste ni lösa en gåta.
- "Jag utför ett manuellt arbete. Jag är inte betrodd med att förstå helheten. Jag anses nödvändig idag men bör på sikt ersättas av maskiner. Jag är helt utbytbar. Jag anses oansvarig och måste kontrolleras. Jag har en kund som inte gärna smutsar ner händerna. - Vem är jag?" Hörde jag någon som sa "en utvecklare"? Helt rätt, det är alltså... [växla]
- ..."en orch"! Det kanske känns lite skruvat att jämföra programmerare med orcher, men samtidigt är likheterna i hur vi behandlas rätt slående. Och jag vill mena att det knappast är en slump. Faktum är att det är fullt logiskt... förutsatt att du skriver under på följande enkla och på ytan oskyldiga antagande...
- ...programmering innebär att bygga saker. Och det vill jag kalla för det STORA missförståndet. Här är varför...
- Om vi tänker på hur ett bygge fungerar känns säkert punkterna på bilden helt normala. [tala om bild] Så hur skulle det här tänkande fungera om vi trodde att systemutveckling var ungefär likadant?
- ... Märkte ni att jag faktiskt växlade faktiskt bild där. Låt mig göra det igen. [växla fram/tillbaka]. För att få det här att kännas som vår bransch behöver vi i stort sätt bara ändra mediet som vi arbetar med. Men är det verkligen så här illa? Tänk efter själv: - Ärligt talat, har vi inte chefer/kunder som egentligen tycker att de är lite bättre än vi? - Ogillar inte dina kunder att behöva involveras i tid och otid i projekten? - Har vi inte arkitekter och "kravare" som ska tänka åt programmerarna och testare för att kontrollera arbetet? - Utkontrakterar de inte jobbet till någon som tar mycket mindre betalt så fort de får chansen? Konsekvenserna av denna villfarelse är alltså fruktansvärda för oss, orcherna. Men även för kunderna, eftersom verkligheten slår undan benen för dem hela tiden. Men de ser inte att det ligger i systemet självt. De tror att det helt enkelt beror på att de jobbar med folk som inte är riktigt kompetenta - vilket bara stärker deras uppfattningar om manuell arbetskraft!
- Jag har tröttnat på detta. Jag vill inte ha det så här längre. Därför är budskapet med detta tal det här: För att förändra synen på systemutvecklare från orcher till något bättre måste vi börja med att själva förstå mjukvarans natur och i alla sammanhang utstråla och uttrycka detta. Om systemutveckling inte är tillverkning, vad är det då? Vad är dess "sanna natur"?
- Låt oss återgå till tillverkning för ett ögonblick. Resultatet av en byggnadsarkitekts design är inte huset utan ritningar. Dessa ritningar är relativt kompletta och entydiga. De kan ges till godtycklig byggfirma och de utför jobbet. Visst, det finns utrymme för diskussioner men i stort sätt är byggfirmans jobb att följa ritningarna så snabbt, billigt och korrekt som möjligt. Vad skulle vara motsvarigheten till ritningarna inom systemutveckling? Det intuitiva svaret är förstås våra UML-diagram. De känns ju lite ingenjörsmässiga sådär. Men ge samma diagram till tio programmerare och du får tio olika program. UML-diagram är alltså allt annat än kompletta och entydiga. Låt oss fundera lite mer... Vad är egentligen design?
- Det är en stor fråga. Men kortfattat kan man säga att det är en komplicerat process av att förstå problem och hitta lösningar till dem. För varje behov finns en oändlig mängd möjliga lösningar. Design är den mörka avgrunden mellan ett behov och en tillfredsställande lösning.
- Det är en stor fråga. Men kortfattat kan man säga att det är en komplicerat process av att förstå problem och hitta lösningar till dem. För varje behov finns en oändlig mängd möjliga lösningar. Design är den mörka avgrunden mellan ett behov och en tillfredsställande lösning.
- Det är en stor fråga. Men kortfattat kan man säga att det är en komplicerat process av att förstå problem och hitta lösningar till dem. För varje behov finns en oändlig mängd möjliga lösningar. Design är den mörka avgrunden mellan ett behov och en tillfredsställande lösning.
- En form av design handlar om att skapa enstaka, unika föremål, som igloon i förra bilden. Men de flesta designarbeten i modern tid syftar i stället till att skapa en entydig form lämplig för någon slags efterföljande produktionsprocess, som här, ett originalmanus och en litografi.
- Så... allt som vi gör från att vi tror att vi förstått behovet/problemet fram tills att vi har en entydig och komplett ritning av lösningen är design. Allt arbete efter den tidpunkten är tillverkning, att följa receptet för att producera något så korrekt, billigt och snabbt som möjligt. Men om nu UML-diagrammen inte är entydiga så betyder det.. att det finns en massa design kvar att göra när vi programmerar! Och det här stämmer med vår erfarenhet, eller hur? Programmering handlar inte om att textsätta diagram. Oavsett hur mycket vi tänker efter före, när vi kommer till koden blir det alltid ändringar, ofta stora förändringar. Diagrammen duger inte, men vi har dock en sak som faktiskt uppfyller kraven: Vi kallar det för...
- ...källkod. Faktum är att den är så superentydig att vi kan ge den till ett antal maskiner och de kommer alltid att producera samma resultat, givet samma recept. Det måste alltså vara det som är att bygga program. För tusan, det heter ju t o m "byggservrar". Vår entydiga förlaga, vårt recept, vår ritning är alltså... källkod.
- Det här resonemanget har lett oss till följande slutsatser: 1. Systemutveckling är främst att designa program. 2. Slutresultatet av designen, vårt recept, är källkod. 3. Följaktligen, vad en programmerare mest sysslar med är design. Men hur kan det vara design, kanske ni tänker? Det finns ju inget visuellt, det är ju bara text? - Självklart! Fråga vilken ung och arg poet som helst.
- Det här resonemanget har lett oss till följande slutsatser: 1. Systemutveckling är främst att designa program. 2. Slutresultatet av designen, vårt recept, är källkod. 3. Följaktligen, vad en programmerare mest sysslar med är design. Men hur kan det vara design, kanske ni tänker? Det finns ju inget visuellt, det är ju bara text? - Självklart! Fråga vilken ung och arg poet som helst.
- Det här resonemanget har lett oss till följande slutsatser: 1. Systemutveckling är främst att designa program. 2. Slutresultatet av designen, vårt recept, är källkod. 3. Följaktligen, vad en programmerare mest sysslar med är design. Men hur kan det vara design, kanske ni tänker? Det finns ju inget visuellt, det är ju bara text? - Självklart! Fråga vilken ung och arg poet som helst.
- Jag var absolut inte först om dessa tankar. Jack Reeves, som redan hösten 1992 i C++ Journal skrev att källkoden är det enda som uppfyller kraven på en ingenjörsmässig ritning. Han insåg att nästan allt vi gör är design: testning, debugging, kodning t o m det som vi brukar kalla för design är design. Enda skälet till att vi missar det är att själva tillverkningen går så fort och är i stort sett gratis. Hur skulle världen se ut om människor visste att programmering var design?
- Då skulle vi veta att... [tala om bild] Jag tror att de flesta av er här håller med om dessa saker. Det är här vi egentligen skulle vilja befinna oss, men det är så tragiskt sällan vår verklighet.
- Vad kan vi göra? Wittgenstein sa: "The limits of my language means the limits of my world." Han insåg att vi människor inte kan tänka något som vi inte har ett språk för. Språk är alltså essentiellt. Vill vi förändra något är språk ett utmärkt redskap. Exempel: Låt oss kalla den helt oskyldiga spanska skogssnigeln för "mördarsnigel". Det blir liksom lite lättare att utrota den då...
- Alltså: Språk är makt... men vi behöver ta makten över språket. Nästan varje dag hör jag utvecklare säga att de ska "bygga en funktion" eller "producera kod". Ni märker att tillverkningsmetaforen mår finfint även hos oss. Om inte ens vi sjäva kan säga rätt, hur kan vi då förvänta oss att någon annan göra det? Här är några exempel: - Säg aldrig att du ska bygga en funktion/program/system - säg att du ska utveckla/designa den. - Uttryck aldrig att du ska "producera kod" - säg "skriva" eller "författa" - Prata inte som skisser på tavlan som "design", säg i stället att du "modellerar problemet" osv
- Jag har pratat mycket om synen på programmerare, men egentligen är det mycket viktigare än så. Det handlar ju om att så länge det här STORA missförståndet regerar så kommer vi att vara fast i en tillverkningsliknande utvecklingsprocess som är allt annat än optimal - för någon. Det betyder tyvärr i förlängningen att vår egen förmåga att skapa nytta och mening med våra liv kraftigt har reducerats. Vill vi ha det så? Vill ni inte i stället känna att ni skapar nytta med era liv? Hur länge kan vi då tolerera detta tillstånd? Låt oss förändra det här. Men vi måste börja med att förändra oss själva, hur vi tänker på det här och hur vi pratar om det. Låt oss!