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

Первая часть книжки построена на дихотомиях (забавный в вики пример дихотомии: мужчины и не мужчины, можно предположить, что есть еще дети, но все-таки навевает мысли о третьем поле).

Приведен пример, который был или мог случиться, о том, как две подобных команды поспорили в баре, кто быстрее разработает небольшую программу — результат, описанный в книге — ничья. Вообще возникает сомнение: будет ли дисциплинированная команда спорить в баре и тратить свое время на такую «ерунду» — но это на совести автора. В этом разделе есть интересная статья об индексе сложности, который применяется ко всему: к задаче, к методам ее решения, к людям и высказывается интересная мысль, что проект можно завалить, если индексы не совпадают — типа сложные люди сложными методами решают простую задачу (будьте проще и люди к вам потянутся) или наоборот. Ну и апофеоз всего, что бы вы думали — новейшее веяние Agile! О нем кстати в книге не очень много, ну это и понятно, книга в принципе не о нем.

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

Второй пример — известный в узких кругах проект А7 (софт для самолета ВМС США). Как всегда для него было наколбашено много кода без всяких формальных методов, как всегда этот код никому не нравился и как это все-таки бывает во многих случая — он работал! Товарищ Дэвид Парнас решил все переделать «по-уму» (почему бы и нет, если это хорошо спонсируют) — в итоге пока он собирал данные, необходимые для реализации формальных методов, появлялись все новые требования, и новая разработка не догоняла старую, а отставала от нее.

В этом же разделе поднята проблема — программирования без комплекса вины — не надо бояться экспериментировать и допускать ошибки. «Что не убивает меня, то делает меня сильнее» (с) Ницше.

Есть статья об «ad hoc» — применение универсальных методов хорошо, но работает до определенного этапа, а дальше спасают только специальные вещи. Высказывается мысль, что возможен обратный откат к специализированным методам, программам и компьютерам.

В разделе много цифр и многА бакАв — исследование о проценте интеллектуальных и творческих задач в программировании.

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

Деятели науки пафосны и далеки от простого народа (программистов-практиков). Интересная мысль — о понимании и согласии, часто объединяют эти понятия — человек со мной не согласен — значит не понимает — значит надо объяснить еще раз.

Раньше все программисты были ковбоями и работали совсем не за деньги, не то, что сейчас. Хотя есть свет в конце туннеля — OpenSource!

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

Интересная метафора, про греков, римлян и варваров в программировании, типа:

Себя автор видимо относит к грекам.

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