KISS

Tento princip poprvé vyslovil americký systémový inženýr a letecký inovátor Kelly Johnson (1910–1990), který se snažil navrhovat letadla tak jednoduchá, aby je byl schopný opravit každý mechanik se standardní sadou nářadí na jakémkoliv letišti na bitevním poli. Princip KISS se potom rozšířil do dalších odvětví.

Zkratka se používala už v projektu Apollo v 60. letech; existuje (a hlavně v mimopočítačových kontextech se používá) i řada alternativních vysvětlení vyhýbajících se urážce.

• „Keep it short and simple“ – „Zachovej to krátké a jednoduché“
• „Keep it simple sir“ – „Zachovejte to jednoduché, pane“
• „Keep it simple or be stupid“ – „Zachovej to jednoduché nebo buď hloupý“
• „Keep it simple and straightforward“ – „Zachovej to jednoduché a přímočaré“
• „Keep it simple and sincere“ – „Zachovej to jednoduché a upřímné“

Podoba zkratky je zároveň slovní hříčkou – slovo kiss totiž v angličtině znamená také polibek.

Základní problém dnešních programátorů je přílišná snaha o zesložiťování řešení.^[zdroj?]

Typicky, když dostane vývojář problém k řešení, rozdělí ho na malé kousky, u kterých si myslí, že jim rozumí, a pak se snaží problém nakódovat. 8 až 9 z 10 programátorů si ovšem nerozloží problém na dost malé nebo dostatečně pochopitelné kousky.^[zdroj?] Z toho vznikají velmi komplexní implementace i těch nejjednodušších problémů a tzv. „špagetový kód“, který je v OOP (objektově orientovaném programování) reprezentován třídami s tisíci a více řádky a metodami se stovkami a více řádky.

Nejlepší algoritmy na světě^[zdroj?] jsou ty, které mají nejméně řádků a každý jim jednoduše rozumí.

Odpůrci jednoduchého řešení tvrdí: „KISS zní jako nasadit si zaslepující brýle, vypnout mozek a stát se cvičenou opicí. Zní to jako odstranit vše zajímavé okolo hraní si s myšlenkami, které jsou větší, než nějaké další nudné komerční stránky.“ Praxe ovšem ukazuje, že tvorba jednoduchého řešení se (kromě potřeby seberealizace některých jedinců) vyplácí snad ve všech směrech.^[zdroj?]

• Implementovat novou vlastnost nejjednodušším možným způsobem, který bude ještě fungovat. Nebudovat žádné rozsáhlé a dokonalé struktury. Spustit na novém kódu jednotkové testy.
• Refaktorovat celý systém (včetně nového kódu), aby obsahoval nejjednodušší možný kód. Dodržovat pravidla kvalitního kódu (např. žádné duplicity,…) a udělat systém co nejčistější.

• Buď pokorný, nemysli si, že jsi nějaký génius.^[zdroj?] To je první chyba.
• Rozděl svůj problém na spoustu menších problémů. Každý problém by měl jít vyřešit v jedné nebo několika málo třídách.
• Rozděl své úkoly do menších, u kterých si myslíš, že jejich nakódování nebude trvat déle, než 4–12 hodin.
• Udržuj své metody krátké. Každá by měla mít maximálně 30–40 řádků. Každá metoda by měla řešit pouze jeden problém.
• Udržuj své třídy krátké.
• Nejdřív si problém rozmysli, až pak ho nakóduj.
• Refaktoruj svůj kód znovu a znovu. Neboj se nějaké části kódu odstranit.
• Snaž se udržet řešení co nejjednodušší.

• Dokončíš práci rychleji.
• Tvoje práce je jednodušší ke komunikaci.
• Testy se píšou snadněji.
• Kód je jednodušší na správu.
• Máš menší stres, který ovlivňuje všechny výše uvedené efekty.

• Budeš schopný řešit více problémů rychleji.
• Budeš schopný produkovat kód, který bude řešit komplexní problémy v několika málo řádcích kódu.
• Budeš schopný produkovat kvalitnější kód.
• Budeš schopný vytvářet větší systémy, které budou lépe spravovány.
• Tvoje kódová základna bude více flexibilní, jednodušší na rozšíření, úpravu nebo refaktorování, když dorazí nové požadavky.
• Budeš schopný dosáhnout více, než sis někdy dříve dokázal představit.
• Budeš schopný pracovat ve velkých vývojových skupinách a projektech, když je všechen kód „stupid simple“.

Jak je z ukázky kódu (jazyk Java) níže vidět, metoda secti sčítá dvě čísla zadaná v parametrech a tato čísla „zaloguje“. Chyba číslo jedna je skutečnost, že by se metoda měla vždy jmenovat podle toho, co přesně dělá. V této ukázce jméno metody ovšem avizuje pouze polovinu funkčnosti. Hlavní chybou v této ukázce je její skutečná funkcionalita. Princip KISS hovoří o navrhování co nejjednodušších metod, přičemž každá metoda by měla dělat vždy pouze jednu věc. V této ukázce ovšem dělá věci dvě – sčítá a loguje. Vhodnou úpravou by bylo vytvoření samostatné metody pro logování, čímž by se návrh zjednodušil, zpřehlednil a především by novou metodu na logování bylo možné znovu použít i jinde, volat ji z dalších metod (reusability), čímž by se předešlo už důvodům pro vznik zbytečných duplicit. Další vážnou chybou je fakt, že funkce "zaloguje" sečtení dvou čísel ještě před tím, než se tak skutečně stane. Pokud z jakéhokoliv důvodu nepodaří čísla sečíst (např. proto, že jsou jednotlivé sčítance moc velké a dojde k přetečení součtu) je zalogovaná hodnota nepravdivá.

public int secti(int a, int b) {
        Logger.getLogger(NewClass.class.getName()).log(Level.SEVERE, "Sečtena čísla "+ a +" a "+ b);
        
	return a + b;
}