Допустим клиент отпочковывает задачи регулярно.
Платит только за расчетное время.
В процессе на 5-6 связанной задаче понимаешь, что можно оптимизировать написанный ранее по другим ТЗ свой же код.
Как Вы поступаете?

если затрагивает тек работу то оптимизирую. Если клиент не жалуется - то принцип "не трогай рабочую систему"

(0) Плачу отдельно

Задачи отпочкованные появлялись? В письменном/электронном виде есть? Обосновать необходимость можем?
Если да, то...
(1) +100 Опять же, если клиент не жалуется/не хочет, то оставим как есть...

(2) Ну плакать совершенно не обязательно.

Одно из правил, не делай "улучшений, оптимизаций т.д." без согласия на то клиента.

(4) Ну оплачиваю

имхо так правильно

Если оптимизация не займет существенное время, то

Каждое задание отдельно может быть выполнено оптимальным образом, а работа в качестве взаимосвязанных звеньев системы - нет.
Если задания выдавались отдельно (а не в рамках системы), а в последствии захотелось сделать что-то большее то за это надо платить.

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

Но общий подход - работа не за идею, а за деньги.

Все 4 пункта могут быть уместны в своей ситуации

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

так как стараюсь не делать кривых решений и допускаю дальнейшее развитие разработок, то выберу

Собственно, и никак иначе.

И никаких
"А, пох, потом допилю нормально".

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

если такое такой будущей экономии нет, то и смысла в оптимизации нет как бэ

(13) Отличный вариант
(7) А вот так, наверное, нельзя, ибо клиент проверяет и принимает работу, если ее оптимизировать то надо хотябы предупредить и попросить проверить узел заново.

только так

а оптимизация ранее написанного под расширение взаимодействия - это новый функционал (не то что отдельно а в составе очередной задачи)

(0) просто чтобы избежать такой ситуации я сразу прогеру объясняю всю задачу

Таки по голосовалке жадность побеждает :)

ну я за халяву

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

(0) фантастика ....

Работать на почасовке - себя не уважать.

(22) поэтому ты работаешь по ставке 20 рублей в месяц?

(0)Именно поэтому я всегда был сторонником абонплаты. Когда затишье и нет ничего срочного можно оптимизировать старые наработки.

один хрен всё упирается в сдельщину
даже при абонплате есть такое понятие как нормативные часы
касаемо же 1са там вообще часы выставляются на глазок
скажу 10, а сделаю за 1 или скажу 1, а потом выяснится шляпа и буду делать 10

это типа пришёл в стоматологию, заплатил 5 штук
за месяц отремонтировал три зуба
а потом врач говорит: слышь, перчег, я там кое-чё не так как надо сделал, давай ещё 3 тыщи и я тебе первый зуб поправлю
что подумает клиент?

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

Платит только за расчетное время - клиент сам виноват.

Деньги уплачены, результаты получены.

Код можно оптимизировать за деньги, только если это не твой код.

Если это твой бок, то ты должен его убрать

Но не всегда это целесообразно. Например, клиент переходит на 8ку с нового года. Есть смысл менять что то в коде на 7ке за месяц до перехода?

Хотя продумывать нужно стараться заранее. Но это бывает редко возможным

возможно, автор имел ввиду не столько оптимизацию, сколько рефакторинг...

(11) Ну, "идеальный код" это достаточно трудоемко. И дорого, соответственно. А цель все таки - обеспечить автоматизацию работы пользователей в срок.

Главное это изначально заложить в разработку правильные принципы, чтобы потом в 2-3 захода рефакторинга, если они состоятся, довести все до отличного состояния.

В моей практике обычно сеансы рефакторинга состоятся при:
а) написании документации на разработку (в этом процессе все окончательно осмысливается и подводится под теоретическую базу)
б) при дальнейшем развитии функционала
в) при поддержке, когда регулярно оплачивается некоторый объем работ "на общее обслуживание базы"

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

Когда клиентов начала интересовать оптимизация кода?