Поглед назад II: Перфектното, враг на доброто

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

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

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

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

Уроци от agile

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Something for nothing

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

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

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

Изводи

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

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

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

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

4 thoughts on “Поглед назад II: Перфектното, враг на доброто

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

    Мисля, че малко усложняваш нещата. Проект, който влезе в експлоатация по някое време ще започне да страда от грешките и пропуските допуснати при неговото създаване. С течение на времето липсата на тестове ще увеличи драстично нивото на бъгове, а грешките в дизайна или липсата на практика за рефакторинг ще надуе естимейта. В крайна сметка ще се стигне до приказки за „The big rewrite“, или нещо подобно.

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

    Тук има едно голямо „но“. Разработките рядко влизат в реална експлоатация. Учудващо рядко. А има и такива, които след влизане в експлоатация се замразяват, и се ползват във версия 1.0. Чиста работа.

    За това и у голяма част от съсловието са насадени други ценности, тези, които описваш по-горе. Че трябва да работи, пък как е написано, майната му. Тъй като няма сблъсък с реални последици. Щото не правят неща, които се ползват.

    А като споменах и за the big rewrite, технологиите и платформите се сменят толкова начесто, че кодовата база рядко има шанса да преживее повече от 2-3 години, преди да решат че трябва да сменят интерфейса от уеб на десктоп и обратно. И как да не пренапишеш и останалото :).

    Tа тъй. Kато опре да има нужда от качествен софтуер, се достига до практиките. Където не – се правят каубойски веселби с Rump Rangers и Butt Pirates.

  2. Само две забележки:

    1. Дев екипа няма да стане по-добър, ако сам не осъзнава колко е зле. Това с ръчкане няма да стане посмъртно. Насила не става – виждал съм хора принудени да ползват Rails. Резултатите бяха плачевни. Не искам да си представям какво ще стане, ако хора, неразбиращи и неискащи TDD,-то започнат да го прилагат лошо.

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

  3. 🙂 Kато казвам ръчкане, не очаквай някой да дойде да ти каже „Почвай да пишеш тестове“. Няма да стане, те хората не им е и това работата.

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

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

  4. Имаше народна приказка за Синдил-Пиндил и Джаста-Праста. И двете трябвало да си ушият рокли, за да се хванат на хорото. Когато дошло времето за хорото, Джаста-Праста отишла, роклята и висяла на разни страни и изглеждала жалко и нелепо. През това време Синдил-Пиндил още шиела роклята си и плачела.

Вашият коментар

Вашият имейл адрес няма да бъде публикуван.