Princip #5: Keep it simple

“Simplicity is the ultimate sophistication”

Möjligt citat av Leonardo da Vinci, men alldeles för bra för att bry sig om källkritik.

Keep It Simple, Stupid (KISS) är en princip som associeras med flygingenjören Kelly Johnson på amerikanska flottan under 60-talet. Termen dök upp under utvecklingen av flygplan från Lockheed med målet att ju enklare man skapar planen, desto enklare blir de att reparera.

Principen passar utmärkt in i IT-branschen och ligger som botten till principer som YAGNI (you aren’t gonna need it), DRY (don’t repeat yourself) och Rule of least power (välj minst komplicerade lösningen för att nå målet).

Många IT-projekt är allt annat än KISS, DRY och YAGNI oavsett om det beror på en ansvarig IT-arkitekt som vill använda samma arkitektur i alla projekt hen jobbar i, teknikintresserade utvecklare som smyger in en teknik som hen vill lära sig utan att tänka på kostnad eller komplexitet, kunder som fokuserar på knappfärg mer än funktionalitet eller religiösa TDD, normaliserings eller DDD-insatser som resulterar i en perfektionism som hindrar projektet från att bli klart.

Många, går gärna direkt på HUR och missar ofta stegen VAD och framförallt VARFÖR. Det kan bero på en felaktig uppfattning kring vad som ska göras som leder till att personen ifråga sätter fart med första bästa idé.

Ptolemaios var astronom och matematiker i antikens Grekland och verkade i Alexandria. På den tiden var det viktigt att förutspå planeters gång. Ptolemaios lyckades ta fram en modell för att räkna ut var planeter befinner sig på himlavalvet. Ptolemaios modell fungerade, men eftersom den var baserad på den felaktiga tanken att alla himlakroppar roterar runt jorden så blev kalkyleringarna oerhört komplexa och tidsödande. Kan det vara så att Ptolemaios gick direkt på hur utan att passera vad eller varför (tanken att solen var i centrum av solsystemet förekom redan på den tiden).

Vad innebär då keep it simple i praktiken?

Det innebär inte att förenkla in absurdum, utan snarare att välja en så enkel lösning som möjligt i förhållande till uppgiften. Vi ska ta med komplexitet som betalar sig och skippa det som inte ger återvinningsbara effekter.

Ställ dig gärna frågorna:

Behövs verkligen den där enorma databasmodellen?
Blir vi verkligen mer effektiva om vi stoppar in fler personer i ett projekt?
Vad kommer det att kosta i längden att använda ett ramverk som vi misstänker komma försvinna från marknaden inom två år?
Varför ska man göra en mobilapplikation för X kronor när en responsiv websida bara kostar Y kronor?
Varför ska vi skapa den här sajten i ett CMS när det inte finns någon content som behöver publiceras och hanteras?
Varför ska vi införa en fullständig ärendeprocess enligt ITIL när vi i snitt bara har ett ärende i månaden?
Är tidplan och budget realistiska eller springer vi mot ett mål vi egentligen vet att vi inte kommer nå?
Vet vi ens målet med projektet?
Är det rätt person eller process som bestämt hur projektet ska utformas?

https://en.wikipedia.org/wiki/Minimalism_(computing)

https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it

https://en.wikipedia.org/wiki/KISS_principle

https://en.wikipedia.org/wiki/Don%27t_repeat_yourself

http://www.brighthubpm.com/project-planning/54894-example-of-costs-in-project-management/

https://en.wikipedia.org/wiki/Ptolemy

https://en.wikipedia.org/wiki/Aristarchus_of_Samos