Чей это риск, это другой вопрос. Если вы пытаетесь опровергнуть мое определение плохой работы, приводите, пожалуйста аргументы на эту тему. Если аргументов больше нет, то я благодарю вас за дискуссию.
Кто говорит о «непредвиденных затрат от заказчика»?
Непредвиденные затраты могут быть и на стороне исполнителя, когда заказчик, например, запланировал новую фичу, а чтобы ее добавить, нужно выбросить старый код и написать новый (допзатраты), который все-таки можно масштабировать и только после этого добавить новое.
В этот момент кто-то поймет, что ту, первую работу сделали плохо.
При этом неважно, какие выгоды удалось или не удалось получить при использовании плохой работы. Речь идет о самом факте того, что кем-то была сделана тогда плохая работа.
Нет- нет, не путайте. Если новую версию изначально планировалось писать, то это не дополнительные затраты, а запланированные изначально затраты.
Нет дополнительных затрат на поддержку первой версии — значит, работа по ней сделана хорошо. Что-то не работает, незапланированные доработки, переделки — значит, плохо.
Итого: раз пришлось тратить доп. ресурсы (переписывание профессионалом), кто-то сделал работу плохо (в вашем примере это быдлокодер). Это как раз то, что я утверждаю.
Так что, плохую работу никак нельзя определить? Все можно объяснить/оправдать стилем, постановкой задачи, субъективностью оценок? Я правильно понимаю ваш тезис? (надеюсь, нет)
Можно сколько угодно далеко углубляться в философские вопросы вроде «что понимать под...», «что такое работа» и т.д. Но плохой код (объективно плохой) существует. Как распознать эту объективность? Его существование отнимает дополнительные ресурсы. А это значит, что кем-то была сделана плохая работа.
Мой критерий определения плохой работы — это дополнительные затраты любых ресурсов, связанных с этой работой, которые пришлось понести впоследствии.
Это совсем не то, что «соответствует, но внезапно захотелось больше чем в ТЗ записано».
Непредвиденные затраты могут быть и на стороне исполнителя, когда заказчик, например, запланировал новую фичу, а чтобы ее добавить, нужно выбросить старый код и написать новый (допзатраты), который все-таки можно масштабировать и только после этого добавить новое.
В этот момент кто-то поймет, что ту, первую работу сделали плохо.
При этом неважно, какие выгоды удалось или не удалось получить при использовании плохой работы. Речь идет о самом факте того, что кем-то была сделана тогда плохая работа.
Так не распознать плохую работу. Я предлагаю другой признак разпознавания.
Затраты на достижение 100к не связаны с работой старого кода, это новая цель, новый проект.
А если это не работа старого кода привела к допзатратам, то это не тот случай.
Значит ли это, что аргументов против моего начального тезиса больше нет?
Если после выполнения не пришлось тратить время и деньги на его код, проект не стрельнул по другим причинам, к исполнителю претензий нет.
Я говорю о том, что дополнительные затраты говорят о плохой работе, а не о том, что «простыня спагетти» это плохая работа.
Нет дополнительных затрат на поддержку первой версии — значит, работа по ней сделана хорошо. Что-то не работает, незапланированные доработки, переделки — значит, плохо.