Сабж, который хотел бы поднять, думаю знаком многим.
Есть проект — давность написания которого 6 лет.
Написан криво. База тоже кривая. Сейчас он устарел и новые функциональности просто с трудом удается внести.
Казалось бы ничего проще как переписать...НО нужно убедить руководство (манагеры, которые не вникают в нюансы и понятия о программировании не имеют) это задача еще та.
Их понять тоже можно, щас работает всё, система не является коммерческой, а системой внутреннего пользования, да и на переписывание уйдет времени
не меньше 0,5 человека-года.
Собсна хотелось бы услышать как продвинуть проект? Как подкатить с этим, если была уже попытка? Когда это лучше делать?

Здравствуйте, peer, Вы писали:

P>Сабж, который хотел бы поднять, думаю знаком многим.
P>Есть проект — давность написания которого 6 лет.
P>Написан криво. База тоже кривая. Сейчас он устарел и новые функциональности просто с трудом удается внести.
P>Казалось бы ничего проще как переписать...НО нужно убедить руководство (манагеры, которые не вникают в нюансы и понятия о программировании не имеют) это задача еще та.
P>Их понять тоже можно, щас работает всё, система не является коммерческой, а системой внутреннего пользования, да и на переписывание уйдет времени
P>не меньше 0,5 человека-года.
P> Собсна хотелось бы услышать как продвинуть проект? Как подкатить с этим, если была уже попытка? Когда это лучше делать?

А ты аргументированно можешь показать выгоду от такой "переписки"? Т.е. взять, посчитать прибыли от нового варианта, причём вопрос — есть вообще список бенефитов получаемых в данном случае? Плюс прикидку на саму работу по переписыванию иметь надо, чтоб получить в итоге некий "сухой остаток", в примитивной схеме "прибыли — затраты". Ну и конечно на самом деле всё должно быть сложнее, те же прибыли думаю не единовременно получаются, т.е. получаем что-то аля "периода окупаемости".
Т.е. имхо у тебя должна быть схемка типа "3 месяца на переписывание, 2 человека итого 6 окладов, прибыль от внедрения 1-2 оклада в месяц, т.е. срок окупаемости полгода, плюс в Х раз снижаются затраты на модификацию, за счёт которой прибыль ещё более повышается".
В любом случае решение должно быть аргументированно экономически — зачем именно мы это делаем и чего добъёмся в результате.

peer wrote:
>
> Есть проект — давность написания которого 6 лет.
> Написан криво. База тоже кривая. Сейчас он устарел и новые
> функциональности просто с трудом удается внести.
> Их понять тоже можно, щас работает всё, система не является
> коммерческой, а системой внутреннего пользования, да и на переписывание
> уйдет времени
> не меньше 0,5 человека-года.
> Собсна хотелось бы услышать как продвинуть проект? Как подкатить с этим,
> если была уже попытка? Когда это лучше делать?
Ну во-первых, ответить себе, "тебе это лично надо? зачем?"
Второе, проект работает, выполняет свою функциональность, зачем
переписывать?
Третье, посчитай стоимость переписывания проекта с учетом риска, что
сроки ты привел сильно оптимистичные и ответить меньше ли она стоимости
поддержки того, что есть сейчас, хотя бы в течении года.

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

З.Ы. А 6 лет — это не много. Я видел код, которому уже 2000-м было 10
лет (код не то что ужастный, он жуткий), но этот код до сих пор работает
на всех заводах мира, производящих микросхемы и причем поддержка этого
кода с дописыванием всякого до сих пор идет.

Здравствуйте, peer, Вы писали:

P> Собсна хотелось бы услышать как продвинуть проект? Как подкатить с этим, если была уже попытка? Когда это лучше делать?

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

Здравствуйте, ilnar, Вы писали:

I>Здравствуйте, peer, Вы писали:

P>> Собсна хотелось бы услышать как продвинуть проект? Как подкатить с этим, если была уже попытка? Когда это лучше делать?

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

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

Здравствуйте, peer, Вы писали:

P>Есть проект — давность написания которого 6 лет.
P>Написан криво. База тоже кривая. Сейчас он устарел и новые функциональности просто с трудом удается внести.
P>Казалось бы ничего проще как переписать...НО нужно убедить руководство (манагеры, которые не вникают в нюансы и понятия о программировании не имеют) это задача еще та.
P> ... на переписывание уйдет времени
P>не меньше 0,5 человека-года.

А какие (хотя бы приблизительно) объем и сложность проекта?

Был у меня такой случай. Начинали работать с одной системой, дописывали в ней некоторую функциональность. Очень не нравился дизайн, не нравилась излишняя сложность системы, в некоторых местах код был просто ужасен.
И у нас в воздухе все время носилась идея переписать все. По нашим оценкам (а у нас был довольно немаленький опыт в software development'e) требовалось Х человеко-месяцев.
Так вот, после более продолжительного знакомства с системой оказалось, что наша первоначальная оценка неверна раз в 30 (!!!) — столько было всяких вещей, которых мы на тот момент не знали.

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

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

> Собсна хотелось бы услышать как продвинуть проект? Как подкатить с этим, если была уже попытка? Когда это лучше делать?

Есть ли какие-либо перспективы развития этого продукта?

Любой русский программист после пары минут чтения кода, обязательно вскочит и произнесет обращаясь к себе: переписать это все нафиг. Потом в нем шевельнется сомнение в том, сколько времени это займет, и остаток дня русский программист потратит на то, что будет доказывать самому себе, что это только кажется, что переписать это много работы. А если взяться и посидеть немного, то все получится. Зато код будет красивый и правильный.

...

Далее здесь http://www.rsdn.ru/Forum/?mid=156660

Автор: Anatolix
Дата: 18.12.02

Здравствуйте, peer, Вы писали:

Скорее всего начальство право. Писать проект с нуля — это как минимум риски, что не успеете, сделаете новые баги, что-то реализуете не так.
Не лучше ли произвести рефакторинг существующего проекта. Переписать часть функциональности.

peer wrote:
> Сабж, который хотел бы поднять, думаю знаком многим. Есть проект — давность написания которого 6
> лет. Написан криво. База тоже кривая. Сейчас он устарел и новые функциональности просто с трудом
> удается внести. Казалось бы ничего проще как переписать...НО нужно убедить руководство (манагеры,
> которые не вникают в нюансы и понятия о программировании не имеют) это задача еще та. Их понять
> тоже можно, щас работает всё, система не является коммерческой, а системой внутреннего
> пользования, да и на переписывание уйдет времени не меньше 0,5 человека-года. Собсна хотелось бы
> услышать как продвинуть проект? Как подкатить с этим, если была уже попытка? Когда это лучше
> делать?

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

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

--
Дмитрий

Захотелось создать тему "Как убедить неопытных програмистов, что проект не надо переписывать с нуля"

Обычно за желанием переписать проект стоит

1. Неопытность , нет квалификации разобраться с существующим кодом.
2. Уверенность что сделаешь лучше причем обычно вместе с пунктом 1.


а тепер "что делать"

1. Описать структуру проекта.
2. Убрать горизонтальные зависимоти.
3. Структурировать.
4. Выделить НЕзависимые модули.
5. В процесе работы рефакторить модули.
6. Зачем начальству знать какой рукой вы набираете код на клавиатуре ,им нужен результат.

Здравствуйте, minorlogic, Вы писали:

M>Обычно за желанием переписать проект стоит

M>1. Неопытность , нет квалификации разобраться с существующим кодом.

Дык и так все ясно было с самого начала господа

Здравствуйте, ChMaker, Вы писали:

CM>Здравствуйте, minorlogic, Вы писали:

M>>Обычно за желанием переписать проект стоит

M>>1. Неопытность , нет квалификации разобраться с существующим кодом.

CM>Дык и так все ясно было с самого начала господа


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

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

Вот ровно для этого и нужен рефакторинг, что это такое — к Фаулеру. Другое дело если ты собираешься переписывать под другие технологии (с C++/vb6.0 под .net, например, или с asp под asp.net, если проект вебный).

Здравствуйте, Vzhyk, Вы писали:

V>З.Ы. А 6 лет — это не много. Я видел код, которому уже 2000-м было 10
V>лет (код не то что ужастный, он жуткий), но этот код до сих пор работает
V>на всех заводах мира, производящих микросхемы и причем поддержка этого
V>кода с дописыванием всякого до сих пор идет.

Оффтоп: а это часом не "в широко известной в узких кругах" фирме Cadence ты его видел?
Просто не далее как позавчера имел увлекательную беседу именно на эту тему со знакомым,
работающим в её московском офисе. Так он очень похожие вещи рассказывал.

Здравствуйте, vitaly_spb, Вы писали:

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

_>Вот ровно для этого и нужен рефакторинг, что это такое — к Фаулеру. Другое дело если ты собираешься переписывать под другие технологии (с C++/vb6.0 под .net, например, или с asp под asp.net, если проект вебный).

так и есть

frogkiller пишет:
>
>
> Оффтоп: а это часом не "в широко известной в узких кругах" фирме Cadence
> ты его видел?
Нет. Это был RESIF.
> Просто не далее как позавчера имел увлекательную беседу именно на эту
> тему со знакомым,
> работающим в её московском офисе. Так он очень похожие вещи рассказывал.
А потому что это ситуация достаточно типичная.

Здравствуйте, peer, Вы писали:

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

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

Здравствуйте, minorlogic, Вы писали:

M>Захотелось создать тему "Как убедить неопытных програмистов, что проект не надо переписывать с нуля"

M>Обычно за желанием переписать проект стоит

M>1. Неопытность , нет квалификации разобраться с существующим кодом.
M>2. Уверенность что сделаешь лучше причем обычно вместе с пунктом 1.

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

Здравствуйте, peer, Вы писали:

P>Сабж, который хотел бы поднять, думаю знаком многим.
P>Есть проект — давность написания которого 6 лет.
P>Написан криво. База тоже кривая. Сейчас он устарел и новые функциональности просто с трудом удается внести.
Увольняйся

Здравствуйте, Геннадий Ванин, Вы писали:

ГВ>Здравствуйте, minorlogic, Вы писали:

M>>Захотелось создать тему "Как убедить неопытных програмистов, что проект не надо переписывать с нуля"

M>>Обычно за желанием переписать проект стоит

M>>1. Неопытность , нет квалификации разобраться с существующим кодом.
M>>2. Уверенность что сделаешь лучше причем обычно вместе с пунктом 1.

ГВ>2а. "Уверенность", что сделаешь то и так, что обычно никто никогда не делает
ГВ>3. Уверенность, что существуют универсальные решения
ГВ> Другими словами, уверенность, что удастся создать решение и для настоящих потребностей и для будущих,
ГВ> заранее неизвестных, иначе снова надо будет выбрасывать решение и создавать все с нуля

а где гарантия что предскажешь правильно?
подход ХР, например, предполагает реализацию того, что надо, а не того, что может понадобится и то ли понадобится.

Здравствуйте, ilnar, Вы писали:


I>а где гарантия что предскажешь правильно?
I>подход ХР, например, предполагает реализацию того, что надо, а не того, что может понадобится и то ли понадобится.

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

XP предполагает тесное общение, даже включение в команду представителя Заказчика. Где ж такое видано?

А вообще я вопрос не понял — что я предсказываю?
Я добавил в аргумент против начинаний с нуля

У меня совсем был недавно начальник в Новосибирске — у него идея переписать все с нуля (кстати свою собственную разработку на MS Access), перекачав все данные в базе данных в одну колонку одного типа sql_variant. Он называл эту идею — воплощениями принципов ООП в MS SQL Server и все обьяснения сводились к отсылке на форумы sql.ru.

А еще он настаивал на том, что объекты в .NET надо создавать хранимыми процедурами, написанными на SQL!

Универсальность? О, да! Психическая нормальность? Нет!
Если пересесть на калькулятор и бумагу с карандашом, то еще все проще, универсальнее и наверняка без сбоев получится

У меня такое ощущение сложилось, что если с первого раза не поняли, то и не поймут никогда.
В самой первой конторе, которой я работал, пришлось где-то месяц давить на мозги начальства, чтобы переписать очень ответственный блок. В результате я его переписал своими силами (читай в доп. время), что позволило сильно ускорить работу приложения. Скорость была критическим параметром. Но в этой конторе была проточная система, в год менялось до 1/2 сотрудников, я там больше не работаю и не жалею.
А из другой конторы просто пришлось уйти из-за плохого кода. Начальство просто не хотело слушать мои идеи о создании системы автоматического тестирования или переписывании кусков ядра.

Здравствуйте, peer, Вы писали:

P>Сабж, который хотел бы поднять, думаю знаком многим.
P>Есть проект — давность написания которого 6 лет.
P>Написан криво. База тоже кривая. Сейчас он устарел и новые функциональности просто с трудом удается внести.
P>Казалось бы ничего проще как переписать...НО нужно убедить руководство (манагеры, которые не вникают в нюансы и понятия о программировании не имеют) это задача еще та.
P>Их понять тоже можно, щас работает всё, система не является коммерческой, а системой внутреннего пользования, да и на переписывание уйдет времени
P>не меньше 0,5 человека-года.
P> Собсна хотелось бы услышать как продвинуть проект? Как подкатить с этим, если была уже попытка? Когда это лучше делать?

Единственный вариант — менять работу.
Тут будешь это сопровождать до тех пор, пока хватит тебя.
Не жди, что тебе дадут все переделать. Это ФАКТ!

Здравствуйте, s.ts, Вы писали:

ST>Единственный вариант — менять работу.
ST>Тут будешь это сопровождать до тех пор, пока хватит тебя.
ST>Не жди, что тебе дадут все переделать. Это ФАКТ!

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

Здравствуйте, peer, Вы писали:

P>Здравствуйте, s.ts, Вы писали:

ST>>Единственный вариант — менять работу.
ST>>Тут будешь это сопровождать до тех пор, пока хватит тебя.
ST>>Не жди, что тебе дадут все переделать. Это ФАКТ!

P>Как случай рассматриваю смену,

Добрый день.
А Вы давно там работаете?

Здравствуйте, peer, Вы писали:

ST>>Единственный вариант — менять работу.
P>Как случай рассматриваю смену, но мне хочется быть не просто кодером, а развивать в себе умение убеждать руководство в необходимости тех или иных задач, т.к. не планирую до пенсии Поэтому и есть...

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

удачи. она тебе при любом раскладе понадобиться.
во

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

Кто-либо вообще видел проекты, которые можно демонтрировать в качестве 'правильного' продукта? А то что ни пост — ужас, ужас...

З.Ы. Сам я видел только 'ужас, ужас'.

trophim wrote:
>
>
> Кто-либо вообще видел проекты, которые можно демонтрировать в качестве
> 'правильного' продукта? А то что ни пост — ужас, ужас...
Видел. Правда к оному проекту приложил руку Майерс.

А вот большинство именно дерьмом и было. Причины тоже понятны, почему
делалось так ("что там думать, трясти надо").

Здравствуйте, peer, Вы писали:

P>Сабж, который хотел бы поднять, думаю знаком многим.
P>Есть проект — давность написания которого 6 лет.
P>Написан криво. База тоже кривая. Сейчас он устарел и новые функциональности просто с трудом удается внести.
P>Казалось бы ничего проще как переписать...НО нужно убедить руководство (манагеры, которые не вникают в нюансы и понятия о программировании не имеют) это задача еще та.

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

рефакторя проект ты улучшаешь скил в архитектуре и дизайне и уважаешь чужой труд

расписаться в собственной глупости — переписать свою прогу с нуля

не люблю тех кто с нуля переписывать любит

Здравствуйте, Dan Dare III, Вы писали:

DDI>не люблю тех кто с нуля переписывать любит

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

Здравствуйте, BulatZiganshin, Вы писали:

BZ>Здравствуйте, Dan Dare III, Вы писали:

DDI>>не люблю тех кто с нуля переписывать любит

тоже не люблю

BZ>по моему опыту — самые лучшие программы получались тогда, когда через некоторое время после начала разработки были утеряны все исходники

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

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

Dan Dare III wrote:
>
>
> переписывая проект ты выбрысываешь на помойку труд всех разрабов
>
> рефакторя проект ты улучшаешь скил в архитектуре и дизайне и уважаешь
> чужой труд
>
> расписаться в собственной глупости — переписать свою прогу с нуля
>
> не люблю тех кто с нуля переписывать любит

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

Здравствуйте, Vzhyk, Вы писали:

V>Dan Dare III wrote:

>> не люблю тех кто с нуля переписывать любит

V>Много категоричных высказываний, но есть известная шутка, как "прогеры с
V>манагерами небоскреб строили". В ней есть опровержение всем твоим
V>каегоричным высказываниям.

Делись

Здравствуйте, dmoz, Вы писали:

BZ>>по моему опыту — самые лучшие программы получались тогда, когда через некоторое время после начала разработки были утеряны все исходники

D>это никаким боком не относится к бизнес-планам начальства, им не надо "лучшего", им надо "то, что работает".

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

Здравствуйте, BulatZiganshin, Вы писали:

BZ>относится. если программу предполагается модифицировать 6 лет, то через полгода после начала разработки полезно "потерять исходники". и на программу, которую удобно развиввать, проще найти/сохранить рабюотника, вы похоже этого фактора не учитываете

техпроцесс не поставлен должным образом

Здравствуйте, Vzhyk, Вы писали:

V>Много категоричных высказываний, но есть известная шутка, как "прогеры с
V>манагерами небоскреб строили". В ней есть опровержение всем твоим
V>каегоричным высказываниям.

знал ли автор шутки про рефакторинг и умел ли его я в этом сомневаюсь

Здравствуйте, Dan Dare III, Вы писали:

BZ>>относится. если программу предполагается модифицировать 6 лет, то через полгода после начала разработки полезно "потерять исходники". и на программу, которую удобно развиввать, проще найти/сохранить рабюотника, вы похоже этого фактора не учитываете

DDI>техпроцесс не поставлен должным образом

ok, поведай нам как у вас поставлен техпроцесс и сколько лет вашим программам

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

золотой пост. особенно хорошо видно по субъективной схеме
"я правильный пацан" vs. "злобные ОНИ со своим кривым 6-тилетним программным проектом"

как быть с такими разработчиками или просто уволить от греха подальше?

никто не может поделится опытом?

Здравствуйте, phront, Вы писали:

P>золотой пост. особенно хорошо видно по субъективной схеме
P> "я правильный пацан" vs. "злобные ОНИ со своим кривым 6-тилетним программным проектом"

"ОНИ" не злобные но проекты до 15 лет есть

Здравствуйте, Dan Dare III, Вы писали:

DDI>Здравствуйте, peer, Вы писали:

P>>Написан криво. База тоже кривая. Сейчас он устарел и новые функциональности просто с трудом удается внести.

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

мнение небезызвестного Джоэля, мне понравилось:

SMS: Joel, what, in your opinion, is the single greatest development sin a software company can commit?


Joel: Deciding to completely rewrite your product from scratch, on the theory that all your code is messy and bug prone and is bloated and needs to be completely rethought and rebuild from ground zero.


SMS: What's wrong with that?


Joel: Because it's almost never true. It's not like code rusts if it's not used. The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they've been fixed. There's nothing wrong with it.


SMS: Well, why do programmers constantly go charging into management's offices claiming the existing code base is junk and has to be replaced?


Joel: My theory is that this happens because it's harder to read code than to write it. A programmer will whine about a function that he thinks is messy. It's supposed to be a simple function to display a window or something, but for some reason it takes up two pages and has all these ugly little hairs and stuff on it and nobody knows why. OK. I'll tell you why. Those are bug fixes. One of them fixes that bug that Jill had when she tried to install the thing on a computer that didn't have Internet Explorer. Another one fixes a bug that occurs in low memory conditions. Another one fixes some bug that occurred when the file is on a floppy disk and the user yanks out the diskette in the middle. That LoadLibrary call is sure ugly but it makes the code work on old versions of Windows 95. When you throw that function away and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work.

Здравствуйте, peer, Вы писали:
P>Следовательно есть какие то факты, которые заставят рук-во принять решение переписывать проект. К тому же руководство открыто и разв полгода само спрашивает предложения по проекту, а также ставит какие задачи.
А вы попробуйте провести инициативную разработку эскизного проекта новой версии программы, нарисовать красивые граффики того, какие преимущества будут от внедрения программы( например экономия средств на сопровождение, можно ещё даже какую-то часть часть программы сделать и сказать, что тут осталась чуток подкрутить и в бой. Срок у вас есть до следующих разговоров о предложениях по проекту.
P.S. Только лучше если и превирать или перегибать, то не сильно, иначе вас самого могут за это перегнуть за невыполнение своих же планов...