Кодирование до остановки
Какой это был день, занят, но ничего не добился — разочарованный разработчик
Быть разработчиком программного обеспечения несправедливо (никто не говорил, что так будет). Вы можете быть заняты весь день и ничего не добиться. Такое ощущение, что вы ничего не добились, потому что целый день пробовали вещи, которые не работали, или писали не то программное обеспечение.
Как Эдисон, пытающийся создать лампочку и потерпевший неудачу 10000 раз. Разработчики не подводят. Мы приближаемся к правильному решению, но сначала пробуем все неправильные.
Неважно, насколько хорош код, если вы пишете что-то не то. Не существует фиксированного времени для поиска основной причины ошибки.
Измерение продуктивности разработчиков
Однажды я потратил один день, добавляя новое отображение карты, показывая его на следующий день, прежде чем потратить день на удаление нового отображения карты и возвращение старого отображения карты. На бумаге это 2 продуктивных дня, в действительности я был занят кодированием 2 дня, чтобы стоять на месте.
Измерение производительности разработчиков — недостижимая цель, такая же, как поиск лохнесского чудовища, йети или всех требований, определенных до начала разработки. Обычным людям это недоступно.
Продуктивность разработчиков измеряется в баллах и часах, потраченных на работу, но это не точные измерения. Вы можете быть заняты созданием неправильного программного обеспечения.
Производительность офисных работников измеряется количеством отработанных часов, но на самом деле ее следует измерять по выработке и качеству продукции.
Большая часть времени, затрачиваемого на измерение производительности, создание информационных панелей, добавление точек обзора и отчетов, в основном тратится впустую, потому что это не способствует созданию программного обеспечения.
Неизвестные неизвестные
Это не заданная цель при создании программного обеспечения; большую часть времени мы создаем уникальное программное обеспечение, которое никто не знает, как оно должно работать.
Единственный способ узнать, является ли созданное программное обеспечение правильным, — создать запрошенное программное обеспечение, а затем показать его заказчику и протестировать.
Это может показаться провалом, когда вы показываете программное обеспечение, а затем пользователи говорят, что оно не должно так работать. Это разрушает план, но цель создания программного обеспечения состоит в том, чтобы создать программное обеспечение, необходимое пользователям.
Эта цитата подчеркивает, что удаление кода может двигаться вперед.
В один из моих самых продуктивных дней я выбросил 1000 строк кода. Кен Томпсон
Заводское мышление
Менеджеры, заказчики и люди, не являющиеся техническими специалистами, рассматривают разработку программного обеспечения как фабрику. Вы ставите требования с одной стороны, включаете машину для производства сосисок, а программное обеспечение появляется с другой стороны.
Разработчики — это товар, все разработчики одинаковы, а разница в цене — из-за опыта.
Такой ход мыслей приведет к разочарованию, разочарованию и задержке проектов.
Сметы и планы составляются без использования окончательных требований, а это означает, что план и смета гарантированно будут ошибочными.
«Ходить по воде и разрабатывать программное обеспечение на основе спецификации легко, если и то, и другое заморожено». ― Эдвард В. Берард
Большая часть усилий, измеряемых в проектах программного обеспечения, связана с созданием программного обеспечения, а не с созданием правильного программного обеспечения. Каждый раз, когда обнаруживается неправильное программное обеспечение, это прогресс в создании правильного программного обеспечения, но плохая новость для плана.
Когда вы пишете код и создаете программное обеспечение, будут ошибки. Исправление ошибок — это шаг к правильной работе программного обеспечения.
Результаты связаны с усилиями
«Я не потерпел неудачу — я только что нашел 10 000, которые не сработают». - Томас Эдисон
Одной из лучших работ, которые я видел и в которых принимал участие, было программное обеспечение, созданное в рамках неудачного проекта.
Команда разработчиков программного обеспечения находилась в роще; мы принимали требования, создавали программное обеспечение, и качество было высоким. Все в команде разработчиков знали свою работу, дух был велик, а созданное программное обеспечение было хорошим.
Единственная проблема заключалась в том, что первоначальный план проекта сильно недооценивал задачу, и руководство прошло через смертельную спираль постоянной смены приоритетов и плана.
Требования были неправильными, отсутствовали, и потребовалось некоторое время, чтобы необходимое программное обеспечение было обнаружено и закодировано.
Программное обеспечение постоянно создавалось, и с учетом отзывов пользователей оно делало то, что им нужно, и работало так, как нужно. К сожалению, компания была слишком агрессивна со своими планами и одновременно работала 5 команд.
Вместо того, чтобы начинать с малого, быстро строить, быстро учиться.
Они начали с большого, кодируя не то, медленно учились, и у них кончились деньги.
Заключение
Разработка программного обеспечения редко представляет собой прямую линию от требований к сборке, тестированию и производству.
Создание программного обеспечения — это марафон; цель состоит в том, чтобы продолжать делать устойчивый прогресс. Каждый день нам нужно продолжать двигаться к цели создания правильного программного обеспечения для пользователей.
Плавная постоянная работа, исправление ошибок, обновление программного обеспечения на основе отзывов и добавление недостающих требований.
Программное обеспечение сложнее, чем все думают, и всегда занимает больше времени. Планы, оценки — это ориентиры, единственная мера производительности, которая чего-либо стоит, — это созданное программное обеспечение.
