Преодоление медленного решения проблем из-за увеличения знаний о том, что может пойти не так [закрыто]

Это беспокоило меня в течение некоторого времени, и я очень ценю вклад других профессионалов.

Краткая справка: я начал программировать, когда мои родители купили мне мой первый компьютер в 1988 году (в 14 лет, сейчас мне 39 лет). Я прошел несколько других карьерных путей, прежде чем окончательно стать профессиональным программистом в 1997 году. Возможно, поздний расцвет, но так оно и было. Я все еще доволен своим выбором, я люблю программировать и считаю себя хорошим в том, что я делаю.

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

Тривиальный пример: это было просто «хорошо, напишите файл здесь». Теперь я беспокоюсь о разрешениях, блокировке, параллелизме, атомарных операциях, косвенных связях / инфраструктурах, различных файловых системах, количестве файлов в каталоге, предсказуемых именах временных файлов, качестве случайности в моем PRNG, нехватке электроэнергии в середине любого операция, понятный API для того, что я делаю, надлежащая документация и т. д. и т. д. и т. д.

Короче говоря, проблемы давно перешли от «как мне это сделать» к «каков самый лучший / самый безопасный способ сделать это».

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

Приведенный выше пример создания файла был именно этим примером. Реальные задачи, очевидно, являются более сложными, но менее подходят для такого общего вопроса, как этот. Я надеюсь, вы понимаете, куда я иду с этим. У меня нет проблем с разработкой эффективных алгоритмов, я люблю математику, мне нравятся сложные предметы, у меня нет проблем с концентрацией. Я думаю, что у меня есть проблемы с опытом, и, следовательно, со страхом перед ошибками (внутренними или внешними).

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

Как вы справляетесь с этим?

Вы не медленнее в завершении проектов. Раньше вы думали, что ваши проекты начинающих были выполнены, когда они действительно не были. Вы должны продавать это качество клиентам.

«Эта компания может сделать это быстрее и дешевле, но так ли это на самом деле? Или вы будете охотиться за ошибками в течение многих лет?»

Кроме того, вам нужно знать и принимать старую идиому: «совершенство - враг добра».

Похоже, пришло время присоединиться к темной стороне: управление.

Я не предлагаю вам отказаться от программирования и стать менеджером. Но похоже, что весь приведенный вами опыт носил технический характер. В простой операции записи файла вы можете подумать о 10 различных аспектах, которые менее зрелый разработчик никогда бы не рассмотрел. Не обязательно плохо, но ...

Темная сторона это все о текущей стоимости. Речь идет о минимальных инвестициях для максимальной выгоды (анализ затрат и выгод). В бизнесе все сводится к тому, сколько это будет стоить мне, вероятности успеха, вероятности неудачи, вероятности впечатляющего провала и потенциальной выгоды. Делать математику; Действуй соответственно.

Это работает так же хорошо, когда вы разработчик: создайте временный файл, игнорируя разрешения и конфликты имен - 5 мин. Чистая выгода, остальная часть команды может начать работать над любым кодом, который зависит от наличия этого файла. Это идеальное решение? Точно нет. Это даст вам 99%, 95%, может быть, 90%? Да, это, вероятно, будет.

Еще один вопрос: как вы относитесь к техническому долгу? Некоторые люди думают, что это должно быть устранено. Я думаю, что эти люди не правы. Как и в бизнесе, технический долг позволяет вам занимать «наличные» или «время», чтобы доставить что-то раньше. Что лучше: идеальное решение за 2 года или полный взлом, который клиент может использовать и купить за 4 месяца? Все ситуации разные, но в некоторых ситуациях, если вы подождете 2 года, ваш клиент уже зарегистрируется в вашем конкурсе.

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

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

Как примечание, я недавно начал делать технику pomodoro, и это очень помогло. Вместо того, чтобы идти по касательной к касательной, сосредоточьтесь на небольших временных интервалах и затем выделите pomodoros для будущей работы / исследования. Удивительно, сколько раз я делал заметки, чтобы исследовать тему, но через час, когда пришло время, я подумал про себя: «Есть как минимум 3 другие вещи, которые я мог бы сделать со своим временем сегодня, которые все более ценны».

У меня была (вероятно) та же самая проблема много лет назад, она длилась несколько лет, и я преодолел ее. Поэтому, возможно, вам было бы интересно узнать, как я этого добился, даже если я не уверен, что мой путь будет применим и к вам.

Вы также должны взглянуть здесь: Семь этапов экспертизы в разработке программного обеспечения. Это показывает, что производительность в значительной степени является побочным эффектом уровня квалификации. Может случиться так, что вы все еще находитесь в какой-то момент между этапом 3 и этапом 4 в отношении технологии, которую вы используете в настоящее время (мастерство зависит от технологии, вы можете овладеть некоторыми технологиями, все еще изучая другие).

Теперь я начну с биографических показаний.

Немного контекста. Мне 47. Я начал программировать в 12 в 80-х. В старших классах я также работал профессиональным программистом. По сути, это не принесло мне столько денег, просто достаточно, чтобы купить оборудование, но я наслаждался этим и многому научился. В 18 лет я начал формальное обучение информатике.

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

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

Тем не менее, я никогда не переставал пытаться программировать. И в какой-то момент он вернулся. Ключевым для меня было экстремальное программирование, а точнее принцип простоты: «Напиши простейшую вещь, которая могла бы сработать».

По сути, я заставил себя не заботиться об эффективности кода (это было моим основным препятствием, избегать неэффективных проектов), а просто идти самым простым путем. Я также заставил меня меньше заботиться об ошибках и отложить обработку ошибок на более позднее время после написания тестов, поднимающих ошибку (на самом деле это TDD).

Это то, что я узнал, когда писал. Когда я не знаю, что писать, или я знал, что я писал, было плохо . Просто иди. На самом деле пиши плохие вещи. Я со временем исправлю это позже. Или, если это действительно так плохо, стереть и переписать его, но гораздо быстрее написать вещи, которые напишут что-нибудь идеально с первого раза.

На самом деле очень вероятно, что код, который вы считаете хорошим при первом написании, нуждается в таком же улучшении, как и действительно плохой.

Если вы пойдете по пути Простоты, вы также получите дополнительный бонус. Вы легко соглашаетесь удалить / изменить первоначальный дизайн / кодирование. Вы получаете более гибкий ум.

У меня также появилась привычка вставлять временный комментарий в код, объясняя, что я не делал сейчас и собирался сделать позже, когда код будет функционировать в обычном случае использования.

Я также посетил XP Dojo с отработанными кодовыми кодами вместе с другими программистами, чтобы усвоить практики XP. Это помогло. Это сделало вышеуказанные формальные методы инстинктивными. Также помогло парное программирование. Работа с молодыми программистами дает определенный импульс, но с опытом вы также видите, что они не делают. Например, в моем случае я часто вижу, что они участвуют в чрезмерно сложных проектах, и я знаю кошмар дизайна, который может привести к. Ушел так. Сделал это. Были проблемы.

Для меня первостепенное значение имеет поддержание потока. Быть быстрым действительно помогает поддерживать поток.

Теперь я вернулся как профессиональный программист, и я верю, что я и лучше, и быстрее, с более глубоким пониманием того, что я делаю. Практикуя TDD, я все еще могу быть немного медленнее, чем когда был молодым быком (и ничего не проверял), но у меня также нет страха рефакторинга и, конечно, я трачу гораздо меньше времени на отладку (почти совсем нет, делаю это меньше, чем на 10% времени) ).

Вкратце: я преодолел свой кодовый блок, используя гибкие методы (XP), делая простоту, затем рефакторинг и тренируясь, чтобы сделать это инстинктивным. Это сработало для меня. Не уверен, что это может быть распространено на кого-либо еще.

Что касается уровня приобретения навыков, я в основном научился признавать, что каждый раз, когда я меняю технологию (изучаю новый язык, новую среду и т. Д.), Я прохожу через этап, когда замедляюсь. Это нормально и в конечном итоге преодолеет это. Я также могу компенсировать это хорошей методологией и навыками программирования общего назначения, и это не будет такой большой проблемой.

Важной частью программирования является управление и контроль сложности, и лично для меня это одна из главных проблем. Если их игнорировать, то либо увеличивается частота недостатков, либо, как в вашем случае, ETA готового программного обеспечения резко возрастает.

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

Другими словами, сложность программного обеспечения во многом зависит от того, насколько вы квалифицированы в управлении ожиданиями вашего клиента.

Когда кто-то принимает эту точку зрения, тогда становятся очевидными два важных момента:

1. ожидания клиента должны быть явными (в любой форме);
2. ожидания клиента всегда могут быть изменены, и это делается с помощью искусства переговоров.

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

Строительство F16 отличается от строительства Cessna, хотя оба они могут летать.

Простой ответ: примите это.

Во всех системах есть компромисс между надежностью, надежностью, безопасностью, скоростью, стоимостью оборудования, стоимостью разработки, временем выхода на рынок, как вы это называете. Вы не всегда соглашаетесь с тем, как клиент делает эти компромиссы, но вы не тот, кто принимает эти решения. Все, что вы можете сделать, это предоставить взвешенное мнение. Разработка программного обеспечения охватывает всю гамму, от «моей личной веб-страницы» до «запуска ядерного реактора», и код должен быть написан соответствующим образом. Если сбой означает «перезагрузить мою личную веб-страницу», то кого это волнует? Но если сбой означает «чернобыльский», то вы предпочитаете твердый код, если что-то немного случайное на мой вкус.

Есть некоторые клиенты, которые с радостью примут код уровня «Доказательство концепции» и запустят его в своих действующих системах, и часто у них есть системные администраторы, которые к этому хорошо привыкли. IME их системы обычно недоступны в течение часа или около того в середине ночи, когда происходит куча запланированных перезапусков. Но они приняли деловое решение, что именно так они хотят катиться. В идеале, потому что их поле настолько быстро движется, что высококачественный код никогда не будет готов, но часто потому, что они не могут видеть значение (если система «просто работает», они никогда не замечают этого, поэтому эта система не представляет значения для Деньги). Если это вас слишком беспокоит, постарайтесь избегать этих клиентов.

Чтобы быть в курсе - это время, которое мы все должны потратить или, по крайней мере, должны потратить. Иногда это заставляет вас работать, а иногда просто поддерживает ваш ум в тонусе. В любом случае, попытайтесь насладиться этим.

Похоже, ваши навыки были бы очень полезны для разработки высококачественных критически важных систем, таких как приложения, связанные с финансами / торговлей, радиовещание, авиакосмическая промышленность, оборона ...

Ошибки в таких приложениях очень дороги, и в них работают люди, которые думают как вы, поскольку вы можете охватить все случаи.

Правда в том, что современные системы становятся все более сложными. Компьютер теперь похож на ту игру «Дженга», где у вас есть все эти части, опирающиеся на многие другие. Вытащите не ту часть, и у вас возникла ошибка, вытащите нужную / нужную часть, и вы все равно можете выдать ошибку. Чем сложнее система, тем больше времени вы, вероятно, потратите на размышления о том, как сделать ваш код более надежным и, как мы надеемся, более безопасным. Скорость была бы хорошей, но я думаю, что в наши дни скорость отодвигается на задний план, когда вы слышите в новостях, что компания «XYZ» была взломана и было украдено 6 миллионов номеров кредитных карт клиентов.

Ваши клиенты могут не захотеть слышать, что их программа должна быть безопасной, надежной и т. Д. Но вы можете сказать им, что их машине не нужны ремни безопасности и подушки безопасности, а их дому не нужны замки и двери ... потому что кто хочет услышать все это?

Если вы слишком продуманны, вы идете в правильном направлении, за исключением того, что вам нужно выбрать стратегию, которая кажется «конкретной», и просто пойти с ней.

Похоже, вы знаете о своей склонности думать обо всем, что может пойти не так.

Опытные осторожные разработчики часто учатся следовать мантре YAGNI, она вам не понадобится, когда они пытаются вернуться к скудному, гибкому и продуктивному рабочему процессу после того, как слишком задохнутся в сорняках отказа-режима-анализа-ушли-амок.

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

Запомни:

• Учитывайте общую стоимость обслуживания, общую стоимость владения и общую стоимость развертывания и поддержки решений, когда вы рассматриваете изменения в своем подходе. Быть быстрее и делать больше ошибок может или не может сделать вещи лучше.

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

Единственное, что я вижу, это: «Вы становитесь все более и более ценным».

По мере того, как вы получаете больше опыта, вы узнаете о вещах, которых следует избегать, и это делает вас лучше других.

Одна вещь, которую вы заметили, теперь ваш код будет более безопасным и более удобным в обслуживании.

• Единственное, что вам нужно сделать, это объяснить вашему клиенту, почему это заняло время и как это было бы полезно для них.
• Вы должны показать им глубину своих знаний.
• Вы должны рассказать им, почему вы это сделали, что вы сделали и как это имело бы значение для них и их бизнеса.

Мое предложение будет сосредоточиться на этой части.

когда сомневаешься, что по умолчанию плохо цитируешь Кнута ...

«Преждевременная оптимизация - корень всего зла».

Вот что я хотел бы предложить, так как кажется, что у вас есть проблема, которая у меня время от времени ...

Что действительно работает для меня ...

1. Напишите модульные тесты, как будто весь код был сделан.
   
2. документировать интерфейс.
   
3. реализовать интерфейс.

что вы действительно сделали:

1. проработать требования к слоям модели
2. действительно настроить разделение работы, какие объекты отвечают за что
3. приступить к работе в среде, когда вы действительно можете пройтись по рабочему коду, что делает вещи намного быстрее и точнее ...

также полагайтесь на утверждения в ранней разработке ... затем выясните, какие средства должны быть реализованы, и вы не будете писать код, который недоступен или труден для тестирования.

Я думаю, что вы должны придерживаться своих стандартов кодирования, но убедитесь, что вы честны со своими клиентами. Многие клиенты не знают, что нужно / стоит для создания хорошего программного обеспечения. Обучать их - это часть работы профессионального разработчика.

Будь вы ловкий или водопад, вы получаете какое-то согласие от клиента относительно того, что они ожидают от приложения. Слишком много разработчиков (хорошо, может быть, больше продавцов) виноваты в мешках с песком . «Они не сказали, что хотят сайт с высокой степенью защиты». В большинстве случаев это потому, что их не спросили. "Вы не возражаете, если ваш сайт электронной коммерции будет взломан?" Конечно, их это волнует, и зачем вам это делать, чтобы кто-нибудь проник в систему безопасности? Вы должны обучать их.

Просто убедитесь, что вы делаете только то, что вам платит клиент. Частью вашего обслуживания является ваш опыт. Клиенты ожидают, что вы будете знать подводные камни без необходимости их спрашивать. Это зависит от них, чтобы включить требование. Возможно, вы захотите передать клиентам, которые хотят что-то дешевое.

Подумайте о практических последствиях ошибки по сравнению со всеми другими проблемами, которые необходимо решить.

Рассмотрим следующие последствия создания плохо написанного фрагмента кода:

1. Вся база данных сбрасывается через месяц. 48 часов простоя при восстановлении резервных копий.
2. Записи клиентов становятся сшитыми. Заказы на сумму $ 200 доставляются неправильным клиентам в месяц.
3. Заказ застревает в неправильном состоянии один раз в неделю. Заказывайте суда, но склад должен вызывать службу поддержки каждый раз, когда это происходит.
4. Примерно через две недели приложение вылетает, и пользователь должен повторно ввести данные за 2 минуты.
5. Раз в месяц приложение зависает при запуске. Пользователь должен убить процесс и начать все сначала.

Первый явно недопустим. # 2 - # 5 может или не может быть, в зависимости от характера бизнеса. № 2 - № 5 необходимо оценивать в контексте других проблем, с которыми сталкивается бизнес.

В идеале, № 2 - № 5 никогда бы не случилось. В реальной жизни, с противоречивыми приоритетами, люди, подписывающие вашу зарплату, могут захотеть, чтобы вы работали над другими вещами, а не писали идеальный код, у которого никогда и никогда не возникало проблем. Они не будут впечатлены, если № 5 будет исправлен за счет не исправления более серьезной ошибки в другой программе.

Решение состоит в том, чтобы создать коллекцию библиотек с часто используемыми функциями, которые вы можете повторно использовать в разных проектах. Например, у меня есть библиотека StringFunctions.dll .NET, которая выполняет такие вещи, как кодирование, шифрование, дешифрование, оценка регулярных выражений и т. Д. Таким образом, мне не нужно постоянно переписывать вещи, которые не меняются.

Наличие оболочки для задач по созданию файлов также имеет большой смысл. Ваша библиотека может предоставить метод с именем GetFile (), который выполняет все проверки за вас и возвращает либо ноль, либо файл (или то, что вы считаете полезным).

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

Написание программы, которая может хорошо масштабироваться для более чем миллиона пользователей, потребует времени и опыта, которые у вас есть сейчас, но если вы знаете, что ваше приложение не будет использоваться максимум 1000 пользователями, нет смысла тратить все в то время совершенствуя это.

Я думаю, что это важный этап в вашей карьере программиста, и теперь вам нужно перейти на следующий уровень, который связан со зрелостью, а не программированием. Вы должны быть в состоянии правильно решить, сколько времени и кода должно быть достаточно для любого конкретного проекта.

И, как и все остальное, вы можете достичь этого также с практикой. Поэтому постарайтесь решить это до того, как начнете проект, иногда, даже когда вы уже работаете над ним, с опытом вы тоже это пройдете. В начале может быть несколько попаданий и промахов, но со временем вы улучшите это (принятие решений, а не код).

@Zilk, я не большой программист, и я программирую с 1998 года. Даже сейчас я сталкиваюсь с этой проблемой. Но то, что я понял, в конечном счете имеет значение качество. Если я умру сегодня, кто-то должен быть в состоянии забрать то, что я делаю сейчас, с того места, где я ушел. Таковы должны быть стандарты программирования (универсальные).

Теперь я перешел от разработчика к архитектору. Переезд в Управление меняет линию. Если вы хотите продолжить со своей страстью, вы можете стать архитектором.

Изначально как Технический Архитектор -> Архитектор Решений -> Архитектор Предприятия -> Главный Архитектор и так далее.

Как архитектор, вы будете направлять людей к успеху. Люди, подобные вам, которые десятилетиями программируют, те годы опыта, которые вы можете использовать, чтобы направлять других.

Как птица выше, она летит больше земли, которую она может видеть, так же, как и ваш опыт.

Позвольте мне также сказать, что программирование правильной реализации важно, чем программирование неправильной реализации быстрее. Недавно один из моих юниоров запрограммировал что-то не так, и это стоило банку больших денег. Конечно, мы доставили вовремя раньше, но это было бесполезно! Если бы мне дали роль гида, даже если бы тот же младший закодировал бы, что проблемы бы не было. Я привожу этот пример, чтобы подчеркнуть, что хорошее руководство также важно. Некоторые называют эту работу консультантом.

Другой вариант: прекратить писать код, а не продавать свой опыт в выявлении проблем заранее.

Другими словами, станьте консультантом .

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

Вы не будете писать столько кода, и вы, вероятно, пропустите это, но тогда кажется, что фактические строки кода - это не ваша сила, а знание того, какие строки кода следует писать, а какие - нет.

Сосредоточьтесь на своих сильных сторонах.
(ну, если это то, что вам нравится ...)

Моя лучшая рекомендация для вас: строительные блоки.

Создайте файловый строительный блок, которому вы всегда можете доверять, создайте его для своего API, перестаньте тратить время на написание одной и той же вещи снова и снова. Подумайте о каждой проблеме один раз и исправьте ее раз и навсегда.

Никто не догонит это, конечно же, не новичок, который тратит 80% своего времени на отладку кода, который не выполняется в непонятных случаях.

Прежде всего, не исправляйте проблемы, которые не могут возникнуть, например, неправильные разрешения.

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

В какой-то момент вы должны просто не выстрелить себе в ногу вместо того, чтобы всегда проверять, сделали ли вы это или нет.

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

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

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

Поэтому большие достижения в настоящее время и в будущем будут исходить от программистов - продвинутые алгоритмы и более эффективный код.

Если вы посмотрите на GTA 4 и GTA 5, различия поразительны. Но они оба работают на одном оборудовании. Это результат некоторой очень умной и продвинутой практики программирования, которая просто не требовалась или не была доступна 10 лет назад.

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

Как и вы, я начал программировать в 14 лет, также, когда у меня появился первый компьютер (хотя я учился в течение нескольких месяцев). Однако мне сейчас всего 33 года. :-)

Я предлагаю, чтобы при разработке чего-либо вы брали на себя все эти заботы (права доступа к файлам, количество файлов в каталоге и т. Д.), А затем использовали весь свой огромный опыт, чтобы ответить на несколько вопросов об этом, в этом духе:

• Сколько времени потребуется, чтобы правильно решить эту проблему в вашем коде?
• Если вы не справитесь с этим должным образом, насколько вероятно, что эта вещь укусит вас позже?
• Если это вас кусает, каковы последствия?

Вооружившись этими ответами, у такого опытного парня не возникнет проблем с принятием мудрого решения. ;-)

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

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

По словам Эдсгера Дийсктра: «Если отладка - это процесс удаления программных ошибок, то программирование должно быть процессом их устранения». Вы просто делаете меньше последних, поэтому вы должны делать меньше первых. Это просто вопрос обучения тратить время на правильное кодирование. Я все еще относительно молодой программист (читай 20-й), и я стремлюсь когда-нибудь написать что-то совершенно правильное. Час планирования и 10 минут кодирования намного лучше, чем 10 минут планирования, час кодирования и три отладки.