Рубрика: Разработчикам

samdark Бизнес, ошибки, карьера, бэкапы, тимлидство, баги

Если более кривое решение стоит дешевле и не сильно повредит в долгосрочной перспективе, его и будут делать.
Нельзя считать что у вас есть бэкап, если вы из него ни разу не пробовали восстановить систему.
Теория разбитых окон прекрасно применима к проектам. Не оставляйте мусор. Удаляйте сразу.
Бинарный поиск работает и для поиска бага. Если не ясно где он и о чём, делим систему пополам, ищем в какой части из двух… ну и так далее.

Читать дальше

На смерть Fixed Cost

Alexander Shishenin·Wednesday, February 13, 2019

Давно была мысль написать текст о том, почему разработка по модели Fixed Cost постепенно уходит в прошлое, но после пары диалогов на обедах во время Лидеров России, понял, что проблему многие уже ощущают, но не могут формализовать. Поэтому решил всё же написать, почему идея разработки по ТЗ и как следствие модель Fixed Cost останутся в очень небольшом сегменте рынка.

Для начала опишу ключевые фразы, которые являются маркерами проблемы. “Мы не можем найти программистов на наше замечательное ТЗ!”, “Руководство не понимает, чем заняты разработчики!”, “Да, вы сделали по ТЗ, но у конкурентов ведь лучше! Куда вы смотрели!!!”, “Мы вам выделили огромный бюджет, но после пяти лет разработки продукт не окупается!”, “Мы начали контролировать маржинальность разработки, а они начали крутить каждую гайку по два года!”

На первый взгляд может показаться, что это всё про разное, но на самом деле корень проблемы один. Ещё Брукс в своей книге “Мифический человекомесяц” в заключении писал, что время когда один человек мог уместить в мозг все аспекты цифрового мира, давно канул в прошлое. С тех пор ситуация для сторонников “продуманного плана” стала только хуже. Языков программирования и технологий расплодилось великое множество и даже в своей предметной области уместить всё в голову никто не может.

В результате мы имеем ситуацию, когда создание качественного ТЗ по своей сложности сравнимо с созданием самой системы. Это ооочень долго и ооочень дорого. Сторонники этого метода парируют, что разработка то теперь будет стоить дёшево, но вот только фигушки. Рынок программистов постоянно нагревается, разговоры о том, что он перегрет, среди сторонников ТЗ, идут постоянно, но вот только дефицит кадров такой, что ни о каком остывании пока речи не идёт. В результате, даже если хорошее ТЗ сделано, программистов на него найти сложно. Делать так, как написал другой дядя, с карьерной точки зрения, не имеет никакого смысла. Поэтому этим готовы заниматься только совсем начинающие, за которыми надзор нужен. А надзор сам по себе требует квалификации и желающих им заниматься на рынке не много, и стоят они дорого. Итог для любителей ТЗ очень печальный, им остаются индустрии, где итерации невозможны. Это в первую очередь медицина и космос, но в общей массе проектов, это капля в море.

Вторым важным фактором является предельная зависимость IT проектов от скорости разработки. Это доказал ещё Microsoft в момент своего вертикального взлёта и это ещё во времена офлайн. С приходом интернета понятие скорости разработки перешло на качественно иной уровень. Сейчас схема – сделали за неделю, раскатили на 1% аудитории, посмотрели реакцию, если хорошо, раскатили на 10% аудитории, если хорошо, то раскатили на всех, не вызывает удивления в индустрии.

Но ровно эта схема, это ночной кошмар сторонников fixed cost. Оплачивать каждую неделю отдельно? А что если аудитории не понравится? А как же длительные итерации, долгие переговоры и согласования? И правда в том, что на эти вопросы нет ответа, кроме как – смиритесь, жизнь изменилась и по-старому уже не будет. Причин две. При реализации нового, право первой ночи критически влияет на успех. А при развитии старого, никто не может предсказать реакцию текущей аудитории, а именно она является священной коровой большинства текущих сервисов. Может ли из-за плохого обновления разбежаться треть аудитории? Ещё как может и это не самый плохой вариант. И зачем тогда клепать обновления по несколько миллионов долларов? Только если маркетинг обещает привести под обновление больше, чем можно потенциально потерять. У молодого продукта математика этого решения ещё может сойтись, у возрастного и популярного, практически нет.

Третьим важным фактором является эффект бабочки в ТЗ. Дело в том, что желание что-то поменять у заказчика возникает регулярно. Этому способствуют действия конкурентов, результаты промежуточных приёмок и много чего ещё. Да и само по себе это желание правильное, но вот только модель fixed cost его не предполагает. Связано это с тем, что атомарные изменения в современных IT системах можно сделать крайне редко. Да и нормальный заказчик смотрит именно ключевой функционал, от которого должна зависеть вся система. Но формальное ТЗ в случае fixed cost это штука плоская. В нём нельзя написать, что этот интерфейс не особо важен для ключевого функционала, согласуем в последний месяц разработки. Каждый элемент должен быть описан заранее. Но вот бац, заказчик осознал что в ключевом функционале есть проблема и её надо поменять. И вот мы видим эффект бабочки или как по всему ТЗ катится цунами обновлений, которые ведь надо согласовать, забюджетировать и много чего ещё. Эксперты и аудиторы потирают руки и прикидывают, какой бонус попросить за внеурочную работу. И так будет каждый раз, когда нужно будет что-то изменить и цена такой итерации совсем не нулевая и в итоге fixed cost может вырасти и в два и более раз. Тем, кто думает, что такое случается только в IT, советую почитать, как строят новый аэропорт Берлина. И это в Германии, которая достаточно прозрачная страна. Поэтому да, помните про эффект бабочки в большом проекте. Он может стоить очень дорого.

Казалось бы, уже этого достаточно, чтобы убить fixed cost, но есть ещё один важнейший фактор. Это техническая сложность систем и предельная зависимость от личной ответственности практически каждого разработчика. В современном IT настолько просто сидеть на зарплате и пилить задачи по плану, что практически все системы контроля рабочего времени работают крайне плохо. Обосновать, почему задача на 1 час, стоит 8 часов, может практически любой программист. Раскрыть его могут только коллеги и иногда руководитель группы. Те, кто выше, практически не имеют шансов предъявить конкретные претензии ощутимому проценту разработчиков.

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

Как следствие, очень большой процент компаний в долине, а вслед за ними и во всём мире, начинают применять систему мотивации, построенную на опционах или акциях. Смысл её крайне прост, собственники компании хотят не хороший продукт, они хотят, чтобы акции росли в цене. Хороший продукт, это инструмент в достижении этой цели. Но как показывает опыт, обычный программист отлично понимает проблемы из предыдущего параграфа и никуда не торопится. Но вот если компания выдаёт разработчику опционы, то ситуация резко меняется.

Цена акции и общая успешность компании из проблемы далёкого дяди, становится личной шкурной мотивацией. И вот случается чудо, Вася видит, что Петя пилит по восемь часов, то, что надо пилить за час. Ранее его мотивации начать делать то же самое, ничего не мешало. Круговая порука и всё такое. Но вот акции… Если мы будем бездельничать, то опцион не вырастет в цене и шансов стать миллионером не будет. Да, если я стану миллионером, то дядя сверху станет миллиардером, но блин… другого легального способа на простой работе стать миллионером нет. И вот круговая порука ломается, Вася вначале говорит с Петей, если тот не понимает, то с начальником Пети, если тот не понимает, то Вася идёт выше. Вася не боится потерять работу, так как он хороший программист и найти схожую вакансию для него не проблема. То есть хуже ему не станет, даже при увольнении, а вот не потерять возможность стать миллионером, это стоит того чтобы добиться решения проблемы. И вот у нас уже не коллектив исполнителей, а коллектив собственников. Да, им куда сложнее управлять, но зато в нём каждый реально нацелен на рост стоимости компании.

Казалось бы, а какое отношение опционы имеют к fixed cost? Ведь заказная разработка практически не имеет отношения к стоимости компании. Ах да… найм… Чтобы перекрыть бонусы от опционов, основное тело зарплаты надо поднимать до совершенно неприличных размеров, да и то, от проблемы высиживания стула, это не избавит.

В итоге не делать опционы могут позволить себе только проекты, у которых предельно высока нематериальная стоимость. Это в первую очередь социальные проекты, а во вторую оборонка и общегосударственные сервисы, где умелое использование патриотизма исполнителей может давать огромный эффект. Но это всё очень тонкие материи, работать с которыми умеют единицы, да опять-таки, патриотизм и социальная ответственность по фиксированной цене не бывает.
В итоге fixed cost останется только в космосе, медицине и других подобных областях, где итеративность невозможна просто в силу природы этой области. В остальных переход на опционы и схему time and material по сути неизбежен. Те, кто этого не будут делать, рано или поздно проиграют конкуренцию.

Цитатка

«Тестирование не позволяет обнаружить такие ошибки, как создание не того приложения»

— Стив Макконелл

Исследование выявило плюсы и минусы перфекционизма

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

общий эффект перфекционизма для сотрудников и организаций оказывается отрицательным

Читать дальше

ТОП 50 шуток программистов о себе

Если вы посмотрите на код, который вы писали более полугода назад, то, скорей всего, вам покажется, что автор – кто-то другой.
Главная проблема при работе со штатом программистов: никогда не поймешь, чем заняты сотрудники, пока не окажется, что уже наступил дедлайн.
Обычно на написание 90% программного кода разработчикам требуется 90% отведенного на проект времени. А дальше случается парадокс: оставшиеся 10% работы требуют … 90 или даже 100% времени.

Читать дальше

Дублирование намного дешевле, чем неверная абстракция

Правило трех

Подумайте о математической последовательности чисел. Я называю число 2 и спрашиваю: «Какое следующее?» Возможно, это 3 или 4, но может быть и 1, и 2,1. На самом деле вы понятия не имеете. Поэтому я называю еще одно число последовательности – 4 (теперь имеем 2, 4) и спрашиваю: «Какое следующее?» Вероятно, это 6 или 8, или 16. Опять же, несмотря на нашу растущую уверенность, на самом деле мы не знаем. Я выдаю еще одно число из серии, теперь это 2, 4, 16, и спрашиваю: «Какое следующее?» Имея три точки данных, мозг программиста видит последовательность квадратов и определяет, что следующее число – 256. Это правило трех.

Данный пример и без привлечения кода показывает, что мы не должны сразу предполагать абстракцию или дизайн. С помощью отсрочки правило трех противостоит необходимости борьбы с дубликатами. Отсрочка позволяет собрать больше данных для принятия решения на их основе. Говоря словами Сэнди Мец, «дублирование намного дешевле, чем неверная абстракция».

10 способов сделать свой код более читаемым

 

Разница между «программированием» и профессиональной разработкой ПО

Это нормально, когда у вас в тестах строк больше, чем в продакшен-коде.
Написание кода это лишь малая часть того, что нужно сделать для поставки готового программного обеспечения.
CSS это самый сложный из современных языков.
Не обязательно побеждает лучшая технология. Фактически, часто бывает наоборот.
Ставка вашей зарплаты при выполнении одинаковой работы может отличаться на 100% в зависимости от того, работаете вы в крупной корпорации или маленькой компании.
Умение управлять собственной энергией и настроением это один из самых важных навыков, который пригодится при сложном процессе отладки.

Читать дальше

Почему разработчики НЕ бросают свою работу

1. Хорошие отношения с менеджером
2. Мои идеи и мой вклад имеют значение
3. У меня есть возможность работать из дома, когда мне это нужно
4. Дружелюбные коллеги
5. Работа интересная и я постоянно узнаю что-то новое
6. Работа, которую вы выполняете, ценится другими людьми
7. Отсутствие дресс-кода

Читать дальше

Костыли, говно, и ебанина

Vlad Balin:

#javascript Эта картинка вызвала оживленную дискуссию в MoscowJS. Люди не понимают разницу между ебаниной, костылями, и говном. Это очень просто, я сейчас объясню.
14572811_1234711266591045_6966028968720558313_n

Костыли – это в своей природе рациональная штука, она решает реальную проблему. Просто делает это кое-как, через жопу, и на скорую руку. Вот, скажем, если ваш программист с тяжелым вздохом говорит – “ладно, сейчас сговнякаем что-нибудь” – будьте уверены, он приготовился делать костыли. “Хуяк, хуяк, и в продакшн”.

А вот ебанина – это совсем другое дело. Она никакого отношения к рациональной реальности не имеет. Она берется не из нее, а целиком из мозга. Это победа интеллекта над разумом. Это, сцуко, Торжество Идеи.

Другими словами, если костыли – это недостаток ума или (чаще) времени, то ебанина – это напротив, избыток и того и другого.

С другой стороны, говно – это просто говно. Если у программиста руки растут из жопы (что в случае программиста надо понимать не буквально, а как отсутствие элементарного эстетического чувства), то независимо от наличия времени и ума не получаются ни костыли, ни ебанина. А выходит какое-то говно. Об этом явлении пишут поэты:

Олег за все берётся смело
Все превращается в говно
А если за говно берётся
То просто тратит меньше сил

Все просто, ну. Русский язык точен. Как можно эти вещи перепутать.

И я должен отметить – это самая правдивая и точная карта технологий JS из всех, что я видел.

is Yii dying?

Вот такой ответ на вопрос is Yii dying? дал один из основных разработчиков

You may be surprised to hear this from one of the YiiSoft core memeber, but DO NOT recommend to start new project on Yii2 or migrate project from other framework to Yii2. It would be much more reliable for you to use Laravel. It is relatively close to Yii by its architecture and approaches, while it has a commercial background and support, which make its future reliable.

Читать дальше