> Alex Konshin ©   (04.10.18 04:29) [43]
>
> Один из законов Мерфи:
> Если программа работает, то она устарела и её нужно исправить.
>
>
> А если серьёзно, то законченой программы даже теоретически
> быть не может хотя бы с точки зрения безопасности. Любая
> программа содержит ошибки и со временем устаревает.
>

Насчёт некоего из законов Мерфи сказать нечего, ибо о таком законе не слышал. Но насчёт "Любая программа содержит ошибки и со временем устаревает" готов поспорить.

> Alex Konshin ©   (04.10.18 04:29) [43]
>
> Один из законов Мерфи:
> Если программа работает, то она устарела и её нужно исправить.
>
>
> А если серьёзно, то законченой программы даже теоретически
> быть не может хотя бы с точки зрения безопасности. Любая
> программа содержит ошибки и со временем устаревает.
>

Насчёт некоего из законов Мерфи сказать нечего, ибо о таком законе не слышал. Но насчёт "Любая программа содержит ошибки и со временем устаревает" готов поспорить.

> Alex Konshin ©   (04.10.18 04:29) [43]
>
> Один из законов Мерфи:
> Если программа работает, то она устарела и её нужно исправить.
>
>
> А если серьёзно, то законченой программы даже теоретически
> быть не может хотя бы с точки зрения безопасности. Любая
> программа содержит ошибки и со временем устаревает.
>

Насчёт некоего из законов Мерфи сказать нечего, ибо о таком законе не слышал. Но насчёт "Любая программа содержит ошибки и со временем устаревает" готов поспорить.

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

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

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

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

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

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

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

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

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

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

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

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

>  KSergey ©   (04.10.18 13:49) [45]
>
> > Германн ©   (18.09.18 03:10) [42]
> > > любой софт доделан... пока не покажешь заказчику, и
> тут начинается
> >
> > Как пофигист широкого профиля скажу лишь то, что этими
> вопросами
> > не должен заниматься разработчик. Если это конечно не
> индивидуальный разработчик.
>
> Вот не согласен я.
> Программист, как ремесленник - да, видимо не должен.

Во-первых что плохого в слове ремесленник?
Во-вторых не надо воображать программиста как "творца чистого искусства". Это художник может задумать нарисовать что-то неизвестно что. И нарисует как-то. А потом будет ждать как его творчество оценят.

>  KSergey ©   (04.10.18 13:49) [45]
>
> > Германн ©   (18.09.18 03:10) [42]
> > > любой софт доделан... пока не покажешь заказчику, и
> тут начинается
> >
> > Как пофигист широкого профиля скажу лишь то, что этими
> вопросами
> > не должен заниматься разработчик. Если это конечно не
> индивидуальный разработчик.
>
> Вот не согласен я.
> Программист, как ремесленник - да, видимо не должен.

Во-первых что плохого в слове ремесленник?
Во-вторых не надо воображать программиста как "творца чистого искусства". Это художник может задумать нарисовать что-то неизвестно что. И нарисует как-то. А потом будет ждать как его творчество оценят.

>  KSergey ©   (04.10.18 13:49) [45]
>
> > Германн ©   (18.09.18 03:10) [42]
> > > любой софт доделан... пока не покажешь заказчику, и
> тут начинается
> >
> > Как пофигист широкого профиля скажу лишь то, что этими
> вопросами
> > не должен заниматься разработчик. Если это конечно не
> индивидуальный разработчик.
>
> Вот не согласен я.
> Программист, как ремесленник - да, видимо не должен.

Во-первых что плохого в слове ремесленник?
Во-вторых не надо воображать программиста как "творца чистого искусства". Это художник может задумать нарисовать что-то неизвестно что. И нарисует как-то. А потом будет ждать как его творчество оценят.

>  KSergey ©   (04.10.18 13:49) [45]
>
> > Германн ©   (18.09.18 03:10) [42]
> > > любой софт доделан... пока не покажешь заказчику, и
> тут начинается
> >
> > Как пофигист широкого профиля скажу лишь то, что этими
> вопросами
> > не должен заниматься разработчик. Если это конечно не
> индивидуальный разработчик.
>
> Вот не согласен я.
> Программист, как ремесленник - да, видимо не должен.

Во-первых что плохого в слове ремесленник?
Во-вторых не надо воображать программиста как "творца чистого искусства". Это художник может задумать нарисовать что-то неизвестно что. И нарисует как-то. А потом будет ждать как его творчество оценят.

> Сергей Суровцев ©   (10.10.18 14:41) [69]
> С чего бы это?

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

>kilkennycat ©   (10.10.18 14:44) [71]
>А большинство работает из-под палки.

Во-первых откуда такая статистика? А во-вторых как это зависит от наличия или отсутствия нормального планирования?

> Сергей Суровцев ©   (10.10.18 14:51) [72]

статистика из довольно-таки большого рабочего опыта, который очень разнообразен - от плотника на стройке до руководителя собственной компанией.
А как зависит от нормального планирования- не знаю. Наверное, наоборот - нормальное планирование должно это учитывать.
Вот помнится две истории, еще при СССР. Провалился в институт, до службы надо было как-то себя куда-то деть. Программистом тогда устроиться было ваще непонятно как, по радиоэлектронике мест не было, пристроили меня через комсомол учеником плотника. Пришел на работу. Показали козла для маляров и спросили: могешь такой сколотить?
Ну, грю, сколочу. Ну, колоти, сказали бригадир с наставником и свалили. Вечером пришли и ругаться начинают нехорошими словами. А я конструкцию слегка изменил, чтобы они удобнее и надежнее были (малярши потом благодарили даж). Пытаюсь объяснить, что так лучше ж,и тут выясняется, что не в этом дела - много сколотил. Недельный план. И теперь с этой непыльной работы нас кинут на какую-нить другую.
Вторая история: спустя полгода на пилораме, две смены. ну, отработал дневную, вроде ниче, терпимо. Пилим бревна. Тут бац, ночная смена. Норма та же, как и днем. Но работали в три раза быстрее - ночью начальства нет, они лишь утром проверяют выполнение нормы. А мы вечером приехали, а ближе к ночи уехали. И норма, и ночь дома спим, и день свободен.
И где бы я не был потом, везде схоже.
Так что, нормальное планирование - оно, конечно, вещь полезная, если включает в себя надсмотрщика с кнутом.

kilkennycat ©   (10.10.18 15:40) [73]

Что-то я ни в одной из историй "из-под палки" не увидел. Наоборот - энтузиазм так и пышет. По плану да с перевыполнением.

>и тут выясняется, что не в этом дела - много сколотил. Недельный план. И теперь с этой непыльной работы нас кинут на какую-нить другую
 
 "До чего приятно следить, как гребет старый лодочник, - особенно если он нанят по часам. Какое восхитительное спокойствие, какая умиротворенность в каждом его движении! Ни малейшего намека на суетливую поспешность, на лихорадочное стремление вперед, которое становится сущим проклятием девятнадцатого века. Старый лодочник никогда не утруждает себя попытками обогнать другие лодки. Он нисколько не тревожится, когда какая-нибудь из них обгоняет его, - собственно говоря, они все его обгоняют, если только плывут в ту же сторону. Есть люди, которых это раздражает и выводит из себя; великолепная невозмутимость наемного лодочника во время этого испытания может послужить нам прекрасным уроком и предостережением против честолюбия и гордыни."
 Трое в лодке (не считая собаки) - Джером К. Джером.

> Сергей Суровцев ©   (10.10.18 15:51) [74]
> Что-то я ни в одной из историй "из-под палки" не увидел.

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

>kilkennycat ©   (10.10.18 16:38) [76]

ИЗ-ПОД ПАЛКИ — делать что л. По принуждению, под страхом наказания. Имеется в виду, что лицо, группа лиц (Х), не желая выполнять свои обязанности или чьё л. задание, вынуждены это делать. Говорится с неодобрением. неформ. ✦ Х делает что л. из под палки. неизм.… …   Фразеологический словарь русского языка

>[76]
"..во второй ее не было днем, а ночью палка была - хотели побыстрее домой"

какая же это палка  - это заинтересованность

какая же это заинтересованность .. это просто раздолбайство )