Цена ошибки и внимание к мелочам
22.09.2010 о человеках технологии
Не было гвоздя — подкова пропала,
Не было подковы — лошадь захромала,
Лошадь захромала — командир убит,
Конница разбита — армия бежит.
Враг вступает в город, пленных не щадя,
Потому что в кузнице не было гвоздя!
Сейчас читаю Совершенный код, наткнулся там на интересный факт. В семидесятых годах прошлого века был потерян космический зонд стоимостью полтора миллиарда долларов… потому что в программе вместо точки поставили запятую.
Можно было предотвратить это? Конечно, можно. Теоретически :) А по факту, в любой программе чуть сложнее, чем Hello, World, обязательно будут ошибки. Даже если это программа управления ядерным реактором.
Все ошибаются
Но не стоит паниковать, это нормально и неизбежно. Думаю, хорошая программа отличается от плохой прежде всего типом допущенных ошибок и количеством оных. Впрочем, подобная ситуация не только в программировании, этот рок сопровождает вообще всё техническое творчество. Не следует думать, что ошибки допускают только начинающие и мелкие разработчики. Вовсе нет, от этого не застрахованы и всемирно уважаемые гиганты.
В прошлом году Toyota отозвала миллионы автомобилей из-за проблем с электронной педалью газа. Ошибка в её конструировании стоила не только огромных финансовых затрат на переделку, но и прежде всего нескольких человеческих жизней.
Может, это цинично, но инцидент на самом деле стал благом для всех оставшихся в живых автолюбителей — теперь автомобили Toyota станут ещё надёжнее, хотя они и так были на высших строчках любых рейтингов связанных с качеством. Я уверен, что японцы умеют признавать свои ошибки и делать правильные выводы, а слова извинения президента корпорации Акио Тойоды я считаю вполне искренними.
Что будет дальше?
А вот это интересный вопрос. Технический прогресс мчится с огромной скоростью, появляется множество новых технологий, а значит будет появляться множество новых проблем и ошибок.
Замечательно, что в науке и технике ошибки обычно документируются и люди действительно учатся на чужих ошибках, это на самом деле прекрасно. Но массив информации, которую нужно знать становится всё больше и больше — специалисты широкого профиля становятся динозаврами, область знаний каждого отдельного человека углубляется, но при этом становится всё более ограниченной. К чему же это приведёт в итоге? Не знаю, давайте обсудим.
Поскольку начал про ошибки и мелочи, этим и закончу заметку. Думаю, постепенно будут созданы совершенные компьютерные аналитические системы (наверняка что-то уже есть), которые смогут анализировать новые проекты на предмет наличия уже известных человечеству ошибок. Потому что обязательно настанет время, когда один человек уже просто не сможет уместить в своей голове все знания, необходимые для эффективной работы в какой-либо сфере науки и техники.
Комментарии
Комментирование этой статьи закрыто.
« Как испортить правильную идею никудышным исполнением Обязательно обновите Daos и Daos Mini »
Ошибки в любом случае неизбежны, люди же не роботы, да и роботы, бывает, ошибаются. Багфиксы не зря ведь существуют даже у крупных систем, у которых многоопытные разработчики.
Я думал, что в конце ты напишешь, что нибудь шокирующее.
Лифчик!!!
Тормоз, нельзя оправдывать ошибки тем фактом, что ошибаются все – это безответственно. Да, я могу ошибиться, но за каждую свою ошибку я должен отвечать. Тем более если я взял на себя обязательства перед людьми.
Если речь о ПО то есть соглашение об использовании, где автор прописывает какие гарантии он дает и какую ответственность несет. По ним и определяется, чем отвечает разработчик перед пользователями
А причём здесь оправдания? Каждый видит своё, воистину.
Но ведь в совершенной компьютерной аналитической системе тоже неминуемо будут ошибки?
А как же! Обязательно будут :)
Не ошибается тот, кто ничего не делает=) (хорошая отмазка, кстати)
А в ПО много косяков из-за нежелания людей писать тесты. Я сам никогда не писал и пока не планирую, к тому же не знаю ни одного человека, который действительно уделял бы тестам хоть какое-то внимание. А ведь в умных книжках советуют писать код и тесты к нему одновременно, а не сначала закончить какой-то продукт, а потом набросать простенькие тестики. Но это очень трудозатратно, время на написание проекта увеличится раза в два как минимум, плюс частенько квалификация тестировщика должна быть выше, чем разработчика. Все упирается как обычно в ресурсы, время/деньги. Читал, что достаточно хороший процент софта – это доделанные прототипы. Т.е. пишется прототип, его там показывают заказчику, тестируют, и по логике после утверждения всего и вся должна начаться разработка ПО с нуля, но на деле просто допиливается прототип и выдается за конечный продукт, а т.к. при разработке прототипа писать правильный код задача не стояла, а надо было только как можно быстрее показать наброски планируемой функциональности, проблемы и ошибки начинают вылезать очень быстро. И идет бесконечная череда выпуска заплаток=)
И еще один зонд потеряли из-за того, что в одной менюшке не было указания единиц измерения, и оператор думал, что вводит растояние в футах (или что-то типа того), а там по умолчанию считалось в метрах. И спутник улетел в бескрайние дали=)
«и по логике после утверждения всего и вся должна начаться разработка ПО с нуля»
Нет не должна. Прототип для этого и создается, чтобы на его основе писать продукт дальше. Допиливать функции. Иначе получается что практически пишется один и тот же код по два раза. В нормальных компаниях прототип – вполне рабочая программа, конечно совершенно не оттестирована и не допилена.
Tarantul, не, ты не прав, всё же прототипы чаще всего являются именно болванками, макетами приложения. К проектированию есть разные подходы, потому и в значении термина «прототип» в данном случае нет однозначности.
А в том, что код пишется дважды нет ничего плохого — чем больше итераций, тем лучше понимание задачи и способы её решения.
tarantul, после разработки и показа прототип должен быть выброшен и код проекта должен писаться с нуля используя полученные при разработке прототипа знания. Т.е. прототип это первый шаг решения грязной проблемы, но вот если на его основе разрабатывать дальше, то это зачастую получается не разработка, а костылирование. У меня был опыт участия в паре таких проектов.
Одна из главных проблем прототипа – он пишется без учета расширения функциональности. Если прототип пишется с учетом расширяемости – это плохой прототип.
Так что прототип пишется не для того чтобы на его основе писать что-то дальше, а для того чтобы понять чего именно хочет заказчик, какие проблемы могут возникнуть при реализации его желаний и каким образом их обходить.
Я бы сказал так: идеальное состояние недостижимо. Пока слабо представляю как можно достичь идеального состояния. Приблизиться да…
Не зря говорят: нет предела совершенству.
Может быть не ошибка, а выполнение функции по другому. Может быть реализация решения, не как захотел заказчик, вроде всё работает, а заказчик заявляет об ошибке…
Соглашусь, что лучший вариант получается после доделки прототипа… причем в «боевых» условиях!
Вот ещё в тему интересная подборка фатальных багов — www.webzona.ru/txt/f…
Впрочем, не всем перечисленным по ссылке выше фактам стоит доверять, я так думаю. Часть явно байки.
В том же Совершенном коде, на последних страницах также затронута тема ошибок и почему всегда будут программисты ;)
Нет ИИ, а без него все автоматическое также будет зависеть от ошибок человека, замкнутый круг.
Чаще всего ошибки возникают после просьбы улучшить проект – добавить новые возможности. И когда вроде бы все уже учтено, обязательно что-нибудь да забудется. Хотя изначально все работало вполне прекрасно.
В таких случаях здорово помогает подписанное ранее ТЗ и фраза – «Хорошо, мы подсчитаем стоимость данных изменений».