Това е част от серия постове, в които описвам сблъсъка си със света последните две години. Как въобще ми хрумна е документирано тук.

– Ти си твърде голям перфекционист. Винаги искаш да правиш нещата по академично коректния начин. Искаш да е перфектно. Не разбираш, че в бизнеса това не важи. Човек не трябва да се стреми към най-якия код въобще. Перфектното е враг на доброто. Няма нужда да е написано правилно – важното е да работи.

Не мога да преброя колко пъти съм чувал горното. Събеседниците ми рядко са били прави. Лошото е, че това е напълно валиден аргумент. Но аз съм много далеч от академично коректен. Въпреки това, вярвам че нещата трябва да станат по правилния начин. Или по един от правилните начини. Иначе няма да станат. Все пак, това е дефиницията на „правилен“.

Но ако съм оставил у вас впечатлението, че съм фанатик на тема чист код/добри практики, нека се опитам да си изчистя името.

Уроци от agile

На помня коя беше книжката. Жалко, понеже имаше още добри съвети. Този гласеше:

В един проект може да разглеждаме четири компонента:

• Maintability – възможността да правим промени и да откриваме грешки в проекта за по-малко време. Инцидентно ни дава възможност нови програмисти да стават ефективни за по-малко време. Свързано е с добри практики при писането на кода, добър дизайн, повече автоматизирани тестове и документация, където е нужно.
• Scope – колко цялостно решава проблема на клиента. Ако приемем, че feature-ите са фиксирани, да намаляваш scope-а значи да ги опростяваш, така че да продължава да ги има, но да покриват по-малко нужди. Да разширяваш scope-а значи да ги обогатяваш, така че да покриват повече нужди. Може да се мисли за това и като брой feature-и.
• Време – колко календарно време ще отнеме проекта. Дали ще е готов утре или следващия месец.
• Бюджет – колко струва.

Урокът беше следния: ако не покривате целта си в един от компонентите, може да го направите като инвестирате в някой от останалите три. Например:

• Може да намалите feature-и (scope) за да спестите пари (бюджет)
• Може да наемете още програмисти (бюджет) за да покриете сроковете (време)
• Лошия код се пише по-бързо, но по-трудно се поддържа. Жертвате maintability за време
• Може да ограничите изискванията (scope) с цел дизайна на приложението да остане прост (maintability)
• Ако фиксирате времето (release след месец) и програмистите ви казват „няма да стане“, знате че трябва или да жертвате поддръжката, или да намалите feature-ите или да наемете още хора

Един сходен подход твърдеше, че можеш да фиксираш едното и трябва да приемеш другите за плаващи.

„Правилно“ значи да изберете конфигурация, удовлетворяваща нуждите на клиента. Да не правите повече, отколкото трябва. Да не харчите пари, които нямате. Да не се престаравате с поддръжката, ако приложението няма да живее дълго. Да инвестирате в нея иначе.

Очевидно има повече от една конфигурация. Има по-правилни и по-грешни подходи. Има близки подходи. Има тотално неподходящи подходи.

Но разбирането ми за „правилно“ не е свързано с добрите практики, а с прилагането им прагматично. „Академичното“ няма нищо общо.

Загубени в превода

Човекът, който ме нарича „твърде голям перфекционист“ – антагонистът в тази история – е програмист. Той е интелигентен. Разбира. Уверен е. Правил е работещ софтуер. Шефовете имат високо мнение за него. Открил е, че най-важното е софтуера да работи както клиента иска, а не колко добре е написан.

И отнякъде е чул, че „перфектното е враг на доброто“. Прочел е цяла библиотека за предприемачество, мениджмент или създаване на бизнес, но нито една за най-важното – ръководенето на софтуерен проект. Знае кой е Гай Кавазаки, но не знае кой е Фредерик Брукс.

Героят ми не е конкретен индивид. Той е сборен образ. Клас от хора. И когато някоя инстанция на този клас ми каже, че съм „твърде голям перфекционист“ се ядосвам.

Перфектното е враг на доброто

Това е напълно валиден аргумент.

Също така, това е последният урок във всяка методология. Разбираш как да се изправиш срещу хаоса на софтуерното разработване и да внесеш ред. Става с принципи и дисциплина. Разбираш защо тестовете пестят пари и време. Защо чистият дизайн прави проекта много по-евтин за поддръжка. Защо не трябва да оставяш счупени прозорци. Защо практиките трябва да се прилагат „по книга“.

Чак когато разбереш всичко това, научаваш че перфектното е враг на доброто. Че добрите практики трябва да се прилагат прагматично, не канонично. Че тестовете, рефакторингът и БД дизайнът се ползват докато нещата станат достатъчно добри. Но не отвъд това. Че не ти трябва шеста нормална форма, 100% покритие на тестове или пети рефакторинг на този компонент. Посланието е „ползвай всички тези принципи, но не изпадай в крайности“.

Моят герой не го разбира така.

Something for nothing

Моят герой не е извървял пътя – някой му е преразказал заключението. Не разбира контекста на поговорката. Не би направил разлика между добро, перфектно и архитектурна астронавтика – просто няма нужните познания. Но е разбрал малка част – „ОК е да се движим срещу добрите практики“. Не знае кога е ОК, не знае защо е ОК. Знае само че е.

И разбира „ползвайте добрите практики щедро, но в граници“ като „не ползвайте добри практики, освен в краен случай“. Но за него крайният случай е ежедневие – отдавна се е превърнал в норма. И те си остават само по книжките, които лицемерно стоят в библиотеката близо до бюрото му.

Има подходяща дума за такива хора: аматьори.

Изводи

До такава степен съм се наплашил от тях, че се опитвам да избягвам думата „правилно“ във всякакви разговори. Когато Веселин каже „да програмираш правилно“ ми идва отвътре да започна да обяснявам, че не е важно това – важно е да работи. Понякога дори го казвам. После се усещам, че говоря глупости, в които дори не вярвам. Докъде водят опитите за толерантност.

Така че първият ми извод е: аматьорщината може да бъде заразна.

Вторият е: трябва да се науча да се справям с такива хора. Да им обясня какъв е смисълът на добрите практики, да ги убедя да прочетат някоя друга книжка. Да им покажа, че смисълът на поговорката им е друг.

А в крайна сметка, ако са твърде упорити, да не се занимавам с тях. Живота е твърде къс да си губиш времето с глупости. Пък и не ми е цел да отварям очите на хората – предпочитам да се възприемам като ученик, не като учител.