Задумался вот - как возникают эти самые Pointing fingers (если правильно перевел - перевод стрелок, нытье и все такое). У них должна быть “почва”, на голом месте в нормальной ситуации этого быть не должно ни в коем случае.

На мой взгляд, причина все та же самая, что и в 95% проблем в IT: недостаток информации.

Если человек не знает чего-то о чем-то, но это что-то доставило ему неудобства, при этом он не может легко об этом чем-то узнать больше информации, то все что он может делать - выражать иррациональное недовольство, т.е. переводить стрелки, ныть, говорить что все кругом мудаки и мир вообще не очень-то и клевый.

Пример

Думаю стоит подкрепить это предположение примером.

Допустим в продукте используется библиотека/подсистема + есть небольшой сервис для неё. Подсистема общая и обязательная для всех продуктов компании. У неё нет документации, её писали и проектировали разные люди, причем писавший - уже уволился. Также эта либа используется в других продуктах, но несмотря на её очевидную важность - не имеет тестов. Вообще никаких. Её поведение в некоторых местах кажется нелогичным третьему человеку и периодически с ней возникают очень проблемы, очень сильно запрятанные за плохим логированием.

Сколько там худших практик я уже перечислил?:)

Набор цепочек причина-следствие

  1. Тесты не написать, потому что нет понимания как все должно работать.
  2. Понимания не получить, потому что нет документации.
  3. Документация не появится, потому что нет человека у которого есть ОБА понимания - как должно быть и как есть сейчас.
  4. Самостоятельно изучить код тяжеловато по причине редкостной говнокодистости:
    • ** kwargs
    • функции на 100 строк
    • плохое знание своих инструментов писавшим
  5. Выяснить как должно быть, задокументировать это (README.md на 15 строчек - это тоже документация и более того, хорошая документация) переписать с нуля (с оглядкой на старую версию, тестами и все такое, конечно) тоже нельзя, потому что продакшн, прямой денежной выгоды не принесет, короче протолкнуть эту идею сложно - неблагодатная мысль.

Заметьте, что все пункты так или иначе связаны с недостатком информации и любое их решение по сути устраняет этот самый недостаток.

Выводы просты

  1. Даже короткое README дает понимание как должно было быть.
  2. Чистый код дает понимание как есть.
  3. Тесты дают уверенность, что все будет хорошо.
  4. Писать код до первой рабочей версии должен тот, у кого есть полное понимание того, как все должно быть.

По последний пункт, который может показаться очень спорным поясню: люди теряют информацию при всех видах коммуникации и с этим ничего не поделаешь. You can’t fix people, по крайней мере до изобретения телепатии. При потерях информации возникают проблемы, которые решаемы, но неизбежны.

Postscriptum

Вообще я для себя отметил следующую цепочку:

  1. Понимание - залог продуманности.
  2. Продуманность - залог стройности.
  3. Стройность - залог понимаемости.

Если по какой-либо причине эта цепочка нарушается (хуяк хуяк и в продакшн, сдадим на аутсорс, мне некогда тесты/доку писать) - гарантированно получаем проблемы в будущем. Исключение одно - написанный код никогда не будет использоваться, но оно может считаться проблемой, так что только подтверждает это правило.

Еще один момент про который хочется напомнить - переизбыток информации ведет к её недостатку, так как люди начинают игнорировать шум. Важен не объем отправленной информации, важен объем полезной полученной информации.

Вообще ничего особо нового в этом тексте нет, все давно уже сказано в agile manifesto: Individuals and interactions over processes and tools. Здесь я просто попытался разжевать почему это утверждение вообще существует и что оно может означать.