What do you think?
Rate this book
Facts and Fallacies of Software Engineering
The practice of building software is a “new kid on the block� technology. Though it may not seem this way for those who have been in the field for most of their careers, in the overall scheme of professions, software builders are relative “newbies.� In the short history of the software field, a lot of facts have been identified, and a lot of fallacies promulgated. Those facts and fallacies are what this book is about. There’s a problem with those facts–and, as you might imagine, those fallacies. Many of these fundamentally important facts are learned by a software engineer, but over the short lifespan of the software field, all too many of them have been forgotten. While reading Facts and Fallacies of Software Engineering , you may experience moments of “Oh, yes, I had forgotten that,� alongside some “Is that really true?� thoughts. The author of this book doesn’t shy away from controversy. In fact, each of the facts and fallacies is accompanied by a discussion of whatever controversy envelops it. You may find yourself agreeing with a lot of the facts and fallacies, yet emotionally disturbed by a few of them! Whether you agree or disagree, you will learn why the author has been called “the premier curmudgeon of software practice.� These facts and fallacies are fundamental to the software building field–forget or neglect them at your peril!
216 pages, Paperback
First published October 1, 2002
22 people are currently reading
976 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 48 reviews
June 15, 2012
"Факты и заблуждения профессионального программирования" Роберта Гласса это ещё одна книга о том как успешно делать проекты, особенно SW проекты.
В книге вы не найдете готовые рецепты, но найдете много правильных вопросов. В этом собственно, как мне показалось, и ценность этой книги. Сильная сторона книги ещё в том, что автор чётко аргументирует/подтверждает свои мысли, даёт ссылки на книги, статьи и т.д.
Для себя я определил, что основная мысль автора: "Проектирование программного продукта это эвристическая, изнурительная и напряженная интеллектуальная/умственная работа, с плохо предсказуемыми результатами".
Книга начинается сприкольных букв F: frequently forgotten fundamental facts (and) few fallacies.
Вот для начала пару цитат из книги:
� " ... среди нас стало намного больше шарлатанов, продающих всяческие зелья и предсказывающих судьбу, чем нормальных людей, которые занимаются настоящим делом и несут знание в массы"
� "«великим разработчикам» надо платить «столько, сколько они заслуживают»"
� "Хороший менеджмент важнее хорошей технологии"
Автор, определяет проблемы отрасли, представляя факты.
55 фактов объеденные в несколько категорий:
� О менеджменте
� О жизненном цикле
� О качестве
� Об исследованиях
Заблуждения объединены аналогичным образом:
� О менеджменте
� О жизненном цикле
� Об обучении
Оглавление это просто нумерация Фактов. Факт 1, Факт 2, и т.д. Понять что-то из этого невозможно, как прочитать определенную главу непонятно. Выход только один читать все подряд.
По мере чтения глав я выписывал/делал заметки, чтобы ориентироваться было легче. Дальше очень сжато смысл фактов. Это позволит вам создать четкое представление по этим фактам, даже не читая книгу))):
Факт 01 - Самый важный фактор в разработке ПО � это не методы и средства, применяемые программистами, а сами программисты.
Факт 02 - По результатам исследования персональных отличий лучшие программисты до 28 раз превосходят слабейших. Если учесть, что оплата их труда когда не бывает соразмерной, то лучший программист и есть самое выгодное приобретение в индустрии ПО.
Факт 03 - Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше.
Факт 04 - Условия труда оказывают сильное влияние на продуктивность и качество результата.
Факт 05 - Рекламный звон вокруг инструментов и методов это чума индустрии ПО. Большая часть усовершенствований средств и методов приводит к увеличению производительности и качества примерно на 5 � 35%. Но многие из этих усовершенствований были заявлены как дающие преимущество «на порядок».
Факт 06 - Изучение нового метода или средства сначала понижает производительность программистов и качество продукта. Пользу из обучения можно извлечь только после того, как пройдена кривая обучения. Поэтому вводить новые методы и средства имеет смысл, только если а) видеть их реальную ценность и б) проявлять терпение в ожидании выигрыша.
Факт 07 - Разработчики много говорят об инструментальных средствах. Они пробуют довольно многие, приобретают их в достаточном количестве, но практически не работают с ними.
Факт 08 - Чаще всего одной из причин неуправляемости проекта является плохая оценка.
Факт 09 - Большинство оценок в проектах ПО делается в начале жизненного цикла.И это не смущает нас, пока мы не понимаем, что оценки получены раньше, чем определены требования, и соответственно раньше, чем задача изучена. Следовательно, оценка обычно делается не вовремя.
Факт 10 - Большинство оценок в проектах ПО делают либо топ менеджеры, либо сотрудники, занимающиеся маркетингом, а вовсе не те, кто будет создавать ПО, или их руководители. Таким образом, оценку делают не те люди.
Факт 11 - Оценки в проектах ПО редко уточняются впоследствии. Другими словами, оценки, сделанные не теми людьми и не в то время, как правило, не корректируются.
Факт 12 - Раз оценки настолько неправильны, то не так уж много причин беспокоиться о том, что программные проекты не завершаются в сроки, задаваемые оценками. Однако всех это беспокоит.
Факт 13 - Между менеджерами и программистами нет контакта. В одном исследовании, посвященном проекту, в котором не были соблюдены параметры, за данные на основании оценки, и который рассматривался руководством как неудачный, говорится, что технические исполнители отозвались о нем как о самом удачном проекте, над которым они когда либо работали.
Факт 14 - Анализ осуществимости проекта почти всегда дает ответ «да».
Факт 15 - Повторное использование «в миниатюре» (в библиотеках подпрограмм) появилось почти 50 лет назад, и решение этой задачи отработано хорошо.
Факт 16 - Задача повторного использования «в крупном масштабе» (в компонентах) остается по большей части нерешенной, хотя все согласны с тем, что сделать это очень важно.
Факт 17 - Успех повторного использования в крупном масштабе бывает максимальным в семействах родственных систем и потому зависит от предметной области. Это сужает потенциальную применимость повторного использования в крупном масштабе.
Факт 18 - В практике повторного использования есть два «правила трех»: а) многократно используемые компоненты в три раза более трудоемки, чем одноразовые компоненты; и б) многократно используемый компонент должен быть испробован в трех различных приложениях, прежде чем его можно будет считать достаточно общим, чтобы допустить в библиотеку компонентов.
Факт 19 - Модификация повторно используемого кода крайне чревата ошибками. Если надо изменить более 20 25% кода компонента, то лучше переписать его с самого начала.
Факт 20 - Повторное использование паттернов проектирования � это решение проблем, сопутствующих повторному использованию кода.
Факт 21 - Увеличение сложности задачи на 25% приводит к усложнению программного решения на 100%. Это не условие, которое можно попытаться изменить (хотя сложность всегда желательно свести минимуму), это реальное положение дел.
Факт 22 - Восемьдесят процентов работ по созданию ПО приходится на интеллектуальную деятельность. Изрядную долю последней можно смело отнести к креативной. И лишь небольшую часть � к технической.
Факт 23 - Одной из двух самых распространенных причин неуправляемости проектов являются изменчивые требования.
Факт 24 - Исправление ошибок в требованиях обходится дороже всего, если они обнаружены на этапе эксплуатации, и дешевле всего, если это происходит на ранних этапах разработки.
Факт 25 - Требования, которых нет, � это такая ошибка, исправить которую труднее всего.
Факт 26 - По мере продвижения от начальных требований к архитектуре на нас обрушивается шквал «производных требований» (требований к конкретному проектному решению), вызванный сложностью процесса. Список этих производных требований часто в 50 раз длиннее изначального.
Факт 27 - Лучшее проектное решение задачи программирования редко бывает единственным.
Факт 28 - Проектирование � это сложный итеративный процесс. Первоначальное проектное решение, скорее, всего окажется неверным и, безусловно, не оптимальным.
Факт 29 - Программисты переходят от проектирования к кодированию тогда, когда задача разобрана до уровня «примитивов», которыми владеет проектировщик. Если кодировщик и проектировщик � это разные люди, то примитивы проектировщика, вероятно, не будут совпадать с примитивами кодировщика и это приведет к неприятностям.
Факт 30 - COBOL � это очень плохой язык, но все остальные (для обработки бизнес данных) гораздо хуже.
Факт 31 - Фаза устранения ошибок � самая трудоемкая в жизненном цикле.
Факт 32 - Оказывается, что в ПО, о котором типичный программист думает, что оно тщательно протестированно, нередко проверено выполнение лишь 55�60% логических путей. Применение автоматизированных средств, таких как анализаторы покрытия, позволяет повысить эту долю примерно до 85�90%. Протестировать 100% логических путей ПО практически невозможно.
Факт 33 - Даже если бы 100%%тестовое покрытие было возможно, оно не годилось бы на роль критерия достаточности тестирования. Примерно 35% дефектов ПО вызвано пропущенными логическими путями и еще 40% связаны с выполнением уникальной комбинации логических путей. Их не выявить при 100% покрытии тестами.
Факт 34 - Без инструментальных средств почти невозможно качественно проделать работу по устранению ошибок. Широко применяются отладчики � в отличие от других инструментов, например анализаторов тестового покрытия.
Факт 35 - Тесты редко автоматизируются. То есть определенные процессы тестирования могут и должны быть автоматизированы. Но значительную часть работы, связанной с тестированием, автоматизировать нельзя.
Факт 36 - Важным дополнением к инструментам тестирования является созданный программистом встроенный отладочный код, желательно, включаемый в объектный код в зависимости от директив компиляции.
Факт 37 - Тщательные инспекции позволяют устранить до 90% ошибок из программного продукта до того, как будет зап��щен первый эталонный тест.
Факт 38 - Тщательные инспекции дают множество выгод, но они не могут заменить тестирование.
Факт 39 - Общепризнано, что обзоры, сделанные постфактум (их также называют ретроспективными), важны как с точки зрения интересов потребителя (пользователя ПО), так и с точки зрения совершенствования процесса. Однако в большинстве организаций ретроспективные обзоры не делаются.
Факт 40 - В инспекциях наряду с техническими факторами присутствует и социальный. Уделять большее внимание чему то одному в ущерб другому � прямой путь к катастрофе.
Факт 41 - Стоимость сопровождения обычно составляет от 40 до 80% (в среднем 60%) стоимости ПО. Следовательно, эта фаза его жизненного цикла, возможно, самая важная.
Факт 42 - Примерно 60% расходов на сопровождение приходится на улучшение кода и около 17% � на исправление ошибок. Таким образом, в основном сопровождение и поддержка ПО заключается в добавлении в него новых возможностей, а не в его исправлении.
Факт 43 - Сопровождение � это решение, а не проблема.
Факт 44 - Если сравнивать задачи разработки и сопровождения ПО, то они по большей части одинаковы, � за исключением дополнительной задачи сопровождения, формулируемой как «изучение сопровождаемого продукта». Она занимает примерно 30% времени, уходящего на сопровождение в целом, и этот вид деятельности преобладает в сопровождении. Таким образом, можно сказать, что сопровождение более трудоемко, чем разработка.
Факт 45 - Улучшение качества разработки ПО приводит к тому, что сопровождения становится больше, а не меньше.
Факт 46 - Качество есть совокупность свойств.
Факт 47 - Качество не определяется удовлетворением пользователя, соответствием требованиям заказчика, приемлемостью цены и соблюдением сроков сдачи продукта или надежностью.
Факт 48 - Есть такие ошибки, к которым предрасположено большинство программистов.
Факт 49 - Ошибки имеют тенденцию образовывать скопления.
Факт 50 - Для устранения ошибок еще не выработан какой то один, лучший подход.
Продолжение рецензии в комментарии к этой рецензии (оказывается на GR есть ограничение в 20К chars)))
В книге вы не найдете готовые рецепты, но найдете много правильных вопросов. В этом собственно, как мне показалось, и ценность этой книги. Сильная сторона книги ещё в том, что автор чётко аргументирует/подтверждает свои мысли, даёт ссылки на книги, статьи и т.д.
Для себя я определил, что основная мысль автора: "Проектирование программного продукта это эвристическая, изнурительная и напряженная интеллектуальная/умственная работа, с плохо предсказуемыми результатами".
Книга начинается с
Вот для начала пару цитат из книги:
� " ... среди нас стало намного больше шарлатанов, продающих всяческие зелья и предсказывающих судьбу, чем нормальных людей, которые занимаются настоящим делом и несут знание в массы"
� "«великим разработчикам» надо платить «столько, сколько они заслуживают»"
� "Хороший менеджмент важнее хорошей технологии"
Автор, определяет проблемы отрасли, представляя факты.
55 фактов объеденные в несколько категорий:
� О менеджменте
� О жизненном цикле
� О качестве
� Об исследованиях
Заблуждения объединены аналогичным образом:
� О менеджменте
� О жизненном цикле
� Об обучении
Оглавление это просто нумерация Фактов. Факт 1, Факт 2, и т.д. Понять что-то из этого невозможно, как прочитать определенную главу непонятно. Выход только один читать все подряд.
По мере чтения глав я выписывал/делал заметки, чтобы ориентироваться было легче. Дальше очень сжато смысл фактов. Это позволит вам создать четкое представление по этим фактам, даже не читая книгу))):
Факт 01 - Самый важный фактор в разработке ПО � это не методы и средства, применяемые программистами, а сами программисты.
Факт 02 - По результатам исследования персональных отличий лучшие программисты до 28 раз превосходят слабейших. Если учесть, что оплата их труда когда не бывает соразмерной, то лучший программист и есть самое выгодное приобретение в индустрии ПО.
Факт 03 - Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше.
Факт 04 - Условия труда оказывают сильное влияние на продуктивность и качество результата.
Факт 05 - Рекламный звон вокруг инструментов и методов это чума индустрии ПО. Большая часть усовершенствований средств и методов приводит к увеличению производительности и качества примерно на 5 � 35%. Но многие из этих усовершенствований были заявлены как дающие преимущество «на порядок».
Факт 06 - Изучение нового метода или средства сначала понижает производительность программистов и качество продукта. Пользу из обучения можно извлечь только после того, как пройдена кривая обучения. Поэтому вводить новые методы и средства имеет смысл, только если а) видеть их реальную ценность и б) проявлять терпение в ожидании выигрыша.
Факт 07 - Разработчики много говорят об инструментальных средствах. Они пробуют довольно многие, приобретают их в достаточном количестве, но практически не работают с ними.
Факт 08 - Чаще всего одной из причин неуправляемости проекта является плохая оценка.
Факт 09 - Большинство оценок в проектах ПО делается в начале жизненного цикла.И это не смущает нас, пока мы не понимаем, что оценки получены раньше, чем определены требования, и соответственно раньше, чем задача изучена. Следовательно, оценка обычно делается не вовремя.
Факт 10 - Большинство оценок в проектах ПО делают либо топ менеджеры, либо сотрудники, занимающиеся маркетингом, а вовсе не те, кто будет создавать ПО, или их руководители. Таким образом, оценку делают не те люди.
Факт 11 - Оценки в проектах ПО редко уточняются впоследствии. Другими словами, оценки, сделанные не теми людьми и не в то время, как правило, не корректируются.
Факт 12 - Раз оценки настолько неправильны, то не так уж много причин беспокоиться о том, что программные проекты не завершаются в сроки, задаваемые оценками. Однако всех это беспокоит.
Факт 13 - Между менеджерами и программистами нет контакта. В одном исследовании, посвященном проекту, в котором не были соблюдены параметры, за данные на основании оценки, и который рассматривался руководством как неудачный, говорится, что технические исполнители отозвались о нем как о самом удачном проекте, над которым они когда либо работали.
Факт 14 - Анализ осуществимости проекта почти всегда дает ответ «да».
Факт 15 - Повторное использование «в миниатюре» (в библиотеках подпрограмм) появилось почти 50 лет назад, и решение этой задачи отработано хорошо.
Факт 16 - Задача повторного использования «в крупном масштабе» (в компонентах) остается по большей части нерешенной, хотя все согласны с тем, что сделать это очень важно.
Факт 17 - Успех повторного использования в крупном масштабе бывает максимальным в семействах родственных систем и потому зависит от предметной области. Это сужает потенциальную применимость повторного использования в крупном масштабе.
Факт 18 - В практике повторного использования есть два «правила трех»: а) многократно используемые компоненты в три раза более трудоемки, чем одноразовые компоненты; и б) многократно используемый компонент должен быть испробован в трех различных приложениях, прежде чем его можно будет считать достаточно общим, чтобы допустить в библиотеку компонентов.
Факт 19 - Модификация повторно используемого кода крайне чревата ошибками. Если надо изменить более 20 25% кода компонента, то лучше переписать его с самого начала.
Факт 20 - Повторное использование паттернов проектирования � это решение проблем, сопутствующих повторному использованию кода.
Факт 21 - Увеличение сложности задачи на 25% приводит к усложнению программного решения на 100%. Это не условие, которое можно попытаться изменить (хотя сложность всегда желательно свести минимуму), это реальное положение дел.
Факт 22 - Восемьдесят процентов работ по созданию ПО приходится на интеллектуальную деятельность. Изрядную долю последней можно смело отнести к креативной. И лишь небольшую часть � к технической.
Факт 23 - Одной из двух самых распространенных причин неуправляемости проектов являются изменчивые требования.
Факт 24 - Исправление ошибок в требованиях обходится дороже всего, если они обнаружены на этапе эксплуатации, и дешевле всего, если это происходит на ранних этапах разработки.
Факт 25 - Требования, которых нет, � это такая ошибка, исправить которую труднее всего.
Факт 26 - По мере продвижения от начальных требований к архитектуре на нас обрушивается шквал «производных требований» (требований к конкретному проектному решению), вызванный сложностью процесса. Список этих производных требований часто в 50 раз длиннее изначального.
Факт 27 - Лучшее проектное решение задачи программирования редко бывает единственным.
Факт 28 - Проектирование � это сложный итеративный процесс. Первоначальное проектное решение, скорее, всего окажется неверным и, безусловно, не оптимальным.
Факт 29 - Программисты переходят от проектирования к кодированию тогда, когда задача разобрана до уровня «примитивов», которыми владеет проектировщик. Если кодировщик и проектировщик � это разные люди, то примитивы проектировщика, вероятно, не будут совпадать с примитивами кодировщика и это приведет к неприятностям.
Факт 30 - COBOL � это очень плохой язык, но все остальные (для обработки бизнес данных) гораздо хуже.
Факт 31 - Фаза устранения ошибок � самая трудоемкая в жизненном цикле.
Факт 32 - Оказывается, что в ПО, о котором типичный программист думает, что оно тщательно протестированно, нередко проверено выполнение лишь 55�60% логических путей. Применение автоматизированных средств, таких как анализаторы покрытия, позволяет повысить эту долю примерно до 85�90%. Протестировать 100% логических путей ПО практически невозможно.
Факт 33 - Даже если бы 100%%тестовое покрытие было возможно, оно не годилось бы на роль критерия достаточности тестирования. Примерно 35% дефектов ПО вызвано пропущенными логическими путями и еще 40% связаны с выполнением уникальной комбинации логических путей. Их не выявить при 100% покрытии тестами.
Факт 34 - Без инструментальных средств почти невозможно качественно проделать работу по устранению ошибок. Широко применяются отладчики � в отличие от других инструментов, например анализаторов тестового покрытия.
Факт 35 - Тесты редко автоматизируются. То есть определенные процессы тестирования могут и должны быть автоматизированы. Но значительную часть работы, связанной с тестированием, автоматизировать нельзя.
Факт 36 - Важным дополнением к инструментам тестирования является созданный программистом встроенный отладочный код, желательно, включаемый в объектный код в зависимости от директив компиляции.
Факт 37 - Тщательные инспекции позволяют устранить до 90% ошибок из программного продукта до того, как будет зап��щен первый эталонный тест.
Факт 38 - Тщательные инспекции дают множество выгод, но они не могут заменить тестирование.
Факт 39 - Общепризнано, что обзоры, сделанные постфактум (их также называют ретроспективными), важны как с точки зрения интересов потребителя (пользователя ПО), так и с точки зрения совершенствования процесса. Однако в большинстве организаций ретроспективные обзоры не делаются.
Факт 40 - В инспекциях наряду с техническими факторами присутствует и социальный. Уделять большее внимание чему то одному в ущерб другому � прямой путь к катастрофе.
Факт 41 - Стоимость сопровождения обычно составляет от 40 до 80% (в среднем 60%) стоимости ПО. Следовательно, эта фаза его жизненного цикла, возможно, самая важная.
Факт 42 - Примерно 60% расходов на сопровождение приходится на улучшение кода и около 17% � на исправление ошибок. Таким образом, в основном сопровождение и поддержка ПО заключается в добавлении в него новых возможностей, а не в его исправлении.
Факт 43 - Сопровождение � это решение, а не проблема.
Факт 44 - Если сравнивать задачи разработки и сопровождения ПО, то они по большей части одинаковы, � за исключением дополнительной задачи сопровождения, формулируемой как «изучение сопровождаемого продукта». Она занимает примерно 30% времени, уходящего на сопровождение в целом, и этот вид деятельности преобладает в сопровождении. Таким образом, можно сказать, что сопровождение более трудоемко, чем разработка.
Факт 45 - Улучшение качества разработки ПО приводит к тому, что сопровождения становится больше, а не меньше.
Факт 46 - Качество есть совокупность свойств.
Факт 47 - Качество не определяется удовлетворением пользователя, соответствием требованиям заказчика, приемлемостью цены и соблюдением сроков сдачи продукта или надежностью.
Факт 48 - Есть такие ошибки, к которым предрасположено большинство программистов.
Факт 49 - Ошибки имеют тенденцию образовывать скопления.
Факт 50 - Для устранения ошибок еще не выработан какой то один, лучший подход.
Продолжение рецензии в комментарии к этой рецензии (оказывается на GR есть ограничение в 20К chars)))
October 15, 2018
There are two main lessons I gleaned from this book. The first is that the easiest way to produce successful software is to hire the best software developers you can acquire. Based on several studies listed in the book, the best developers are up to 30 times more productive than the worst developers. This make procuring quality developers the most effective decision in managing a software project. The second important lesson is the benefit of code being looked at by multiple people. This is not to be interpreted as one large code review with all developers once per quarter. Instead code reviews seem to be more beneficial with only a few developers, and done as frequently as possible.
December 8, 2017
Full disclosure: I did more skimming of this book than focused reading. Still, I think it had some good lessons to take away, and can have its main points be digested rather quickly.
How I read it was I read the author's introduction, which discusses his methodology of putting together this book, and then went through each of the facts and fallacies listed by the author and thought about how that may or may not apply to my software development team. I took notes on each one that I thought would have pretty good applicability to my team, and read those entries thoroughly.
Because it's an older book, there are certainly some things that are a little outdated now on the cusp of 2018, but there's plenty here that is still just as true now as it was 10, 20, or 30 years ago.
A few of my favorites, which could be considered controversial to some:
* Errors tend to cluster. "Half the errors are found in 15% of the modules."
* Maintenance is a solution, not a problem.
* "Understanding the existing product" consumes 30% of the total maintenance time and is the dominenant maintenance activity. So maintenance is more difficult than initial development.
* For every 25% increase in problem complexity, 100% increase in complexity of the software solution.
The answer to a feasibility study is almost always "yes" - be wary of doing them on your team if you already have a desired outcome in mind, and always welcome the answer of "no." (I felt really good about this, because our team did a feasibility study recently and rejected the feasibility of doing something!)
How I read it was I read the author's introduction, which discusses his methodology of putting together this book, and then went through each of the facts and fallacies listed by the author and thought about how that may or may not apply to my software development team. I took notes on each one that I thought would have pretty good applicability to my team, and read those entries thoroughly.
Because it's an older book, there are certainly some things that are a little outdated now on the cusp of 2018, but there's plenty here that is still just as true now as it was 10, 20, or 30 years ago.
A few of my favorites, which could be considered controversial to some:
* Errors tend to cluster. "Half the errors are found in 15% of the modules."
* Maintenance is a solution, not a problem.
* "Understanding the existing product" consumes 30% of the total maintenance time and is the dominenant maintenance activity. So maintenance is more difficult than initial development.
* For every 25% increase in problem complexity, 100% increase in complexity of the software solution.
The answer to a feasibility study is almost always "yes" - be wary of doing them on your team if you already have a desired outcome in mind, and always welcome the answer of "no." (I felt really good about this, because our team did a feasibility study recently and rejected the feasibility of doing something!)
January 5, 2020
I have read a fair number of software engineering books, and this is one of the more enjoyable books that I have read. When I first heard about it, I thought the concept of a sort of summary of the state of the art sounded really interesting. Although I haven't read any of the author's previous books, I have read and enjoyed his columns in IEEE Software and Communications of the ACM, so I had high hopes about this book. And I wasn't disappointed.
Facts and Fallacies of Software Engineering is divided into 55 facts and 10 fallacies. Each fact and fallacy is presented in the same way. There is a headline/slogan that summarizes it, usually one or two pages of Discussion giving more details, then a Controversy section describing what (if anything) people disagree about and finally Sources and References.
The 55 Facts are divided into the following sections and sub-sections: Management (People, Tools and Techniques, Estimation, Reuse, Complexity), Life Cycle (Requirements, Design, Coding, Error Removal, Testing, Reviews and Inspections, Maintenance), Quality (Quality, Reliability, Efficiency) and Research.
The 10 Fallacies are divided into Management, Life Cycle and Education.
This way of organizing the material works really well, and makes the book very accessible and easy to read. It also allows you to jump around and read what interests you the most first (which is what I did, although I eventually read all of it).
Many of the facts are well known (for example Fact 3 "Adding people to a late project makes it later", Fact 16 "Reuse-in-the-large remains a mostly unsolved problem" and Fact 24 "Requirement errors are the most expensive to fix during production"), but that doesn't matter. It is actually good to be reminded of these facts even if you already know them, and the author does a very good job of summarizing them.
Another thing I like about the book is the Sources and Reference parts (although I think they might as well have been combined into just one Reference section). Often there are references to research papers where the original fact was presented. It is nice to know that what is presented as a fact is indeed a fact that has been validated by research, and not just the opinion of the author (although there is certainly room for opinions in a lot of places as well).
There are also lots of references to other books on software engineering, and a lot of the classic books (like The Mythical Man-Month, Peopleware and Design Patterns) are referenced. So there is plenty of leads in case you want to find out more about a certain fact.
Among the facts I liked the most were Fact 12, Fact 21 and Fact 26.
Fact 12: "Since estimates are so faulty, there is little reason to be concerned when software projects do not meet estimated targets. But everyone is concerned anyway". This fact and the related ones simply state that when a project is late, it is very likely because the estimated time to complete it was unrealistic. Very true.
Fact 21: "For every 25 percent increase in problem complexity, there is a 100 percent increase in complexity of the software solution." I had never seen this fact before, but it does ring true to me. And as the author writes, it explains a lot of the other facts in the book as well.
Fact 26: "Explicit requirements 'explode' as implicit (design) requirements for a solution evolve". In other words, each explicit requirement leads to many more implicit requirements (by a factor of up to 50). This too I had never seen stated, but I definitely recognize this from my own experience.
The Fallacies section list ten common misunderstandings in software engineering, and this is where I disagree on a couple of points. Fallacy 7 states "Random test input is a good way to optimize testing". I agree that it can not be the only test approach, but since he also writes "It may or may not survive as a test approach", he is skeptical to it in general. My own experience is that it is an invaluable complement that helps flush out numerous what I call "timing dependent" bugs caused by the nature of asynchronous events.
I also don't think all his arguments in Fallacy 8 are valid. I agree that since there is no data demonstrating the truth of "Given enough eyeballs, all bugs are shallow", we should not just accept it as truth. But I think he misses the point when he refers to research showing that inspections don't get much extra benefit beyond 2 to 4 participants. My interpretation is that the "enough eyeballs" are not so much inspecting the software in question as running it and debugging it when there is a problem. And the "all bugs are shallow" should not be interpreted too literally. Of course the bugs may still be difficult, but if many people look at it, the chances of someone solving it fairly quickly increases.
Those two examples notwithstanding, I did find myself nodding my head and saying "yes, I agree with that" almost all of the time reading this book.
There are many more interesting facts that I have not commented on, and if you are interested in software engineering I highly recommend this book.
Facts and Fallacies of Software Engineering is divided into 55 facts and 10 fallacies. Each fact and fallacy is presented in the same way. There is a headline/slogan that summarizes it, usually one or two pages of Discussion giving more details, then a Controversy section describing what (if anything) people disagree about and finally Sources and References.
The 55 Facts are divided into the following sections and sub-sections: Management (People, Tools and Techniques, Estimation, Reuse, Complexity), Life Cycle (Requirements, Design, Coding, Error Removal, Testing, Reviews and Inspections, Maintenance), Quality (Quality, Reliability, Efficiency) and Research.
The 10 Fallacies are divided into Management, Life Cycle and Education.
This way of organizing the material works really well, and makes the book very accessible and easy to read. It also allows you to jump around and read what interests you the most first (which is what I did, although I eventually read all of it).
Many of the facts are well known (for example Fact 3 "Adding people to a late project makes it later", Fact 16 "Reuse-in-the-large remains a mostly unsolved problem" and Fact 24 "Requirement errors are the most expensive to fix during production"), but that doesn't matter. It is actually good to be reminded of these facts even if you already know them, and the author does a very good job of summarizing them.
Another thing I like about the book is the Sources and Reference parts (although I think they might as well have been combined into just one Reference section). Often there are references to research papers where the original fact was presented. It is nice to know that what is presented as a fact is indeed a fact that has been validated by research, and not just the opinion of the author (although there is certainly room for opinions in a lot of places as well).
There are also lots of references to other books on software engineering, and a lot of the classic books (like The Mythical Man-Month, Peopleware and Design Patterns) are referenced. So there is plenty of leads in case you want to find out more about a certain fact.
Among the facts I liked the most were Fact 12, Fact 21 and Fact 26.
Fact 12: "Since estimates are so faulty, there is little reason to be concerned when software projects do not meet estimated targets. But everyone is concerned anyway". This fact and the related ones simply state that when a project is late, it is very likely because the estimated time to complete it was unrealistic. Very true.
Fact 21: "For every 25 percent increase in problem complexity, there is a 100 percent increase in complexity of the software solution." I had never seen this fact before, but it does ring true to me. And as the author writes, it explains a lot of the other facts in the book as well.
Fact 26: "Explicit requirements 'explode' as implicit (design) requirements for a solution evolve". In other words, each explicit requirement leads to many more implicit requirements (by a factor of up to 50). This too I had never seen stated, but I definitely recognize this from my own experience.
The Fallacies section list ten common misunderstandings in software engineering, and this is where I disagree on a couple of points. Fallacy 7 states "Random test input is a good way to optimize testing". I agree that it can not be the only test approach, but since he also writes "It may or may not survive as a test approach", he is skeptical to it in general. My own experience is that it is an invaluable complement that helps flush out numerous what I call "timing dependent" bugs caused by the nature of asynchronous events.
I also don't think all his arguments in Fallacy 8 are valid. I agree that since there is no data demonstrating the truth of "Given enough eyeballs, all bugs are shallow", we should not just accept it as truth. But I think he misses the point when he refers to research showing that inspections don't get much extra benefit beyond 2 to 4 participants. My interpretation is that the "enough eyeballs" are not so much inspecting the software in question as running it and debugging it when there is a problem. And the "all bugs are shallow" should not be interpreted too literally. Of course the bugs may still be difficult, but if many people look at it, the chances of someone solving it fairly quickly increases.
Those two examples notwithstanding, I did find myself nodding my head and saying "yes, I agree with that" almost all of the time reading this book.
There are many more interesting facts that I have not commented on, and if you are interested in software engineering I highly recommend this book.
May 29, 2022
Note: You could get a pretty good idea about the facts from the table of contents
A light reading � the author draws from his long experience as a practitioner and a researcher. The book is neither academically dry nor rockie trivial. The author categorized the facts in parts and sections, where each part and section has a kind of an argument that loosely connects them all. He draws from his research and others to back up his arguments, but he doesn’t go down much into discussing the papers.
This book did age well. It may not be the most famous out there, but it’s known okay. If you have some experience and you read this, you will have probably read most of them in other sources. But it’s still a good refresher; it offers a good discussion and, throughout the facts, it challenges some of the prevalent ideas in the industry. And it’s a light read!
Some of the opinions that contribute and are connected to many of the facts and that you could discern clearly (and Glass did affirm them in the conclusion):
People are more important to the success of a software product than tools or processes. Studies even found that the ratio of a good programmer’s performance to mediocre one could reach 28 to 1.
Software is complex; and many management decisions and software research trends tend to employ simplistic approaches that ignore or fail to meet such complexity. This is connected to the first point, because good software developers are much more capable to tackle that complexity, and it’s connected to many of what the author discussed about runaway projects and difficulties of software delivery and maintenance.
Schedule pressures are the biggest hurdle put by management against success of software projects. Bob Glass really has an ax to grind about this one!
December 5, 2017
This book gets 4 stars for being pleasant to read, well-structured, and efficiently impactful. I would have liked to see more studies supporting the facts and fallacies. A more accurate title for this book might be �55 Opinions and Fallacies Which are Probably Mostly Supported by Evidence�. Since Glass has a ton of industry experience, academic experience, and he’s written 25+ books it’s probably safe to accept his opinions for facts. He is very aware that some facts and fallacies will be controversial and addresses those dissenting opinions. The book also feels a little naive at times as it seems to argue that a lot of problems in software engineering are the result of management just not understanding engineering. I agree management could benefit by being more understanding of engineers, but it goes both ways and I think engineers need to be much more understanding of the realities of running a business. The number one takeaway from this book is how valuable it is to be able to bridge the gap between engineering and management. If you are able to do that, and do it well, you will be extremely impactful in an organization.
Pleasant to Read
Glass’s personality comes through in his writing which makes the book feel less academic and more fun to read (he is known as the “premier curmudgeon� of software practice). The writing is informal, but gets right to the point. Also, the book is succinct and moves along pretty quickly � each fact or fallacy only covers a couple of pages.
Well-Structured
Think of this book more like a table of contents. Each fact or fallacy is quickly summarized with a discussion and controversy. Then Glass provides references and sources if you want to look further. A lot of the sources are his own books. A lot of the sources are well-regarded books like the Mythical Man Month, Peopleware, and Refactoring.
Efficiently Impactful
This book gets right to the point which means you can read it fast, and still get a lot out of it. I found myself agreeing with most of the facts and fallacies, disagreeing with a few, and being surprised by a few new ideas. I learned the most from the sections about estimation and maintenance. I also loved his opinion that we should teach new programmers to program by having them read programs (not write them).
More Opinion than Fact
A lot of the so-called “facts� feel more like opinions. But they are probably right, so it doesn’t matter much. Regardless, it would be nice to see more studies backing up the facts. For example, the fact that “For every 25 percent increase in problem complexity, there is a 100 percent increase in solution complexity� is a pretty extraordinary claim. It seems like it’s probably true-ish, but it seems too clean-cut to be true. How can this be true in every setting? Another one is “Enhancements represent roughly 60 percent of maintenance costs.� Is this really true? And how many studies have replicated these results? You’d need to go and do the due diligence to be sure.
Conclusion
Overall, I highly recommend this book for software engineers and managers of software engineers. It is a quick read and will have an immediate pay-off. If you learn one thing from this book it is the importance of being able to explain to management why things should be done a certain way. If you can explain the why and explain it well you will have happy managers and happy engineers.
Pleasant to Read
Glass’s personality comes through in his writing which makes the book feel less academic and more fun to read (he is known as the “premier curmudgeon� of software practice). The writing is informal, but gets right to the point. Also, the book is succinct and moves along pretty quickly � each fact or fallacy only covers a couple of pages.
Well-Structured
Think of this book more like a table of contents. Each fact or fallacy is quickly summarized with a discussion and controversy. Then Glass provides references and sources if you want to look further. A lot of the sources are his own books. A lot of the sources are well-regarded books like the Mythical Man Month, Peopleware, and Refactoring.
Efficiently Impactful
This book gets right to the point which means you can read it fast, and still get a lot out of it. I found myself agreeing with most of the facts and fallacies, disagreeing with a few, and being surprised by a few new ideas. I learned the most from the sections about estimation and maintenance. I also loved his opinion that we should teach new programmers to program by having them read programs (not write them).
More Opinion than Fact
A lot of the so-called “facts� feel more like opinions. But they are probably right, so it doesn’t matter much. Regardless, it would be nice to see more studies backing up the facts. For example, the fact that “For every 25 percent increase in problem complexity, there is a 100 percent increase in solution complexity� is a pretty extraordinary claim. It seems like it’s probably true-ish, but it seems too clean-cut to be true. How can this be true in every setting? Another one is “Enhancements represent roughly 60 percent of maintenance costs.� Is this really true? And how many studies have replicated these results? You’d need to go and do the due diligence to be sure.
Conclusion
Overall, I highly recommend this book for software engineers and managers of software engineers. It is a quick read and will have an immediate pay-off. If you learn one thing from this book it is the importance of being able to explain to management why things should be done a certain way. If you can explain the why and explain it well you will have happy managers and happy engineers.
October 12, 2020
This books contains 55 facts and a few fallacies about management, software life cycle, quality and research. It's an old book, but most of its content is still relevant today (and most likely it will be in the future).
Here are the facts that I liked the most:
- Fact 1: tools and techniques matter much less than the quality of the individual software developers.
- Fact 2: good programmers are ~30x better than the bad programmers.
- Fact 5: even when new tools & techniques are good, they hardly introduce improvements in the range of 5-35%. They are mostly hype.
- Fact 7: good programmers use less tools.
- Fact 9-10-11: most software estimates are performed at the wrong time, by the wrong people, without any correction during the development cycle.
- Fact 12: manage a project by schedule does NOT work. Instead, manage it by product, issue, risk, business objectives, or by quality.
- Fact 20: design patterns emerged from practice, not theory.
- Fact 37: rigorous inspections can remove up to 90 percent of errors from a software product before the first test case is run. I view this fact as a critique against TDD zealots.
- Fact 40: peer reviews are both technical and sociological. Paying attention to one without the other is a recipe for disaster.
- Fact 45: better software engineering development leads to more maintenance, not less.
- Fact 52: efficiency stems more from good design than from good coding.
And my favorite fallacy is the education fallacy (number 10): you teach people how to program by showing them how to write programs. This is wrong because we first read a program. But unfortunately there are no books that teach how to read code before knowing how to write it.
Here are the facts that I liked the most:
- Fact 1: tools and techniques matter much less than the quality of the individual software developers.
- Fact 2: good programmers are ~30x better than the bad programmers.
- Fact 5: even when new tools & techniques are good, they hardly introduce improvements in the range of 5-35%. They are mostly hype.
- Fact 7: good programmers use less tools.
- Fact 9-10-11: most software estimates are performed at the wrong time, by the wrong people, without any correction during the development cycle.
- Fact 12: manage a project by schedule does NOT work. Instead, manage it by product, issue, risk, business objectives, or by quality.
- Fact 20: design patterns emerged from practice, not theory.
- Fact 37: rigorous inspections can remove up to 90 percent of errors from a software product before the first test case is run. I view this fact as a critique against TDD zealots.
- Fact 40: peer reviews are both technical and sociological. Paying attention to one without the other is a recipe for disaster.
- Fact 45: better software engineering development leads to more maintenance, not less.
- Fact 52: efficiency stems more from good design than from good coding.
And my favorite fallacy is the education fallacy (number 10): you teach people how to program by showing them how to write programs. This is wrong because we first read a program. But unfortunately there are no books that teach how to read code before knowing how to write it.
June 26, 2019
Ok, Robert L. Glass is the Nassim Taleb of Software Engineering. Arrogant, confident, hate towards academicians, extremely smart and savvy in his field, not humble at all. (You can see Fallacy 9 as an example).
Besides his arrogance throughout the book and the facts/fallacies I strongly disagreed with (especially the last fallacy, one has to be CLUELESSLY STUPID to think that reading code is a better way of learning than writing code), what bothered me the most was that Glass made way too many stretches to find all those 55 facts and �5+5� (10) fallacies. He even admits that at some points in the book, he had to search where there was nothing to make the book in the format he wished, so it led to an obvious loss of quality overall.
Nevertheless, his objective with the book was to bring some thought-provoking ideas and whether you agreed or not, you should at least take some time to reflect upon them and consider alternative ways of thinking about Software Engineering. And that he successfully achieved.
Besides his arrogance throughout the book and the facts/fallacies I strongly disagreed with (especially the last fallacy, one has to be CLUELESSLY STUPID to think that reading code is a better way of learning than writing code), what bothered me the most was that Glass made way too many stretches to find all those 55 facts and �5+5� (10) fallacies. He even admits that at some points in the book, he had to search where there was nothing to make the book in the format he wished, so it led to an obvious loss of quality overall.
Nevertheless, his objective with the book was to bring some thought-provoking ideas and whether you agreed or not, you should at least take some time to reflect upon them and consider alternative ways of thinking about Software Engineering. And that he successfully achieved.
August 24, 2017
I liked some of the facts and their presentation but most is just a repetition of the author's previous work. I give him credit for all the work he has done! It's a great legacy.
Just this type of a recipe book with a general attitude 'that's how this is, learn from me' does not resonate well with me. Some facts I liked and the references are helpful, if I need to look up a specific number.
Just this type of a recipe book with a general attitude 'that's how this is, learn from me' does not resonate well with me. Some facts I liked and the references are helpful, if I need to look up a specific number.
October 2, 2022
There are a lot of anecdotes and author� ego, but I did not find a lot of new things to learn. The overall message was perfectly and much more concisely formulated by Brooks: � there is no silver bullet�.
What I didn’t like most is his cherry-picking of what he considers proofs of his “facts�. Basically, if a study confirms his bias it’s good, otherwise-garbage
What I didn’t like most is his cherry-picking of what he considers proofs of his “facts�. Basically, if a study confirms his bias it’s good, otherwise-garbage
November 14, 2017
Contiene algunos de la aforismos conocidos. Pero no hay mucho más de lo que ya han dicho otros autores, como Brooks. Es entretenido y fácil de leer, pero no se si sea de gran aporte. Las 3 estrellas porque algunos de los dichos de Glass son muy ciertos.
May 18, 2018
It was a fantastic book.
A great summary of real world software engineering principles, form a practitioner's approach.
It rebuts many long-time myths of software engineering, and makes emphasis practices that really work (facts).
A great summary of real world software engineering principles, form a practitioner's approach.
It rebuts many long-time myths of software engineering, and makes emphasis practices that really work (facts).
March 16, 2019
Clearly written, contains some information never read elsewhere. I appreciated the Fact/Discussion/Controversy structure. It may be worth to check all the books mentioned in the "References" sections.
June 14, 2021
This was one of the first Software Engineering books I ever read and I really liked it. There’s a lot I don’t understand from it because of my lack of experience working in the industry, but it’s nice to learn a lot of these things so early in my career.
July 23, 2018
The book is somewhat old. I do not agree with every fact discussed in this book. decent reads.
Full review:
Full review:
November 18, 2018
Collection of evergreen information.
January 10, 2019
In many cases it is hard to accept that some things which seem automatable to us won't be in the near future. Everyone in the field should read this.
February 20, 2019
Solid book. The 65 points he mentioned are worthwhile enough for me to add to my Anki.
August 28, 2019
Opinions, reasons, and anti-opinions from a highly respected software engineer.
September 1, 2019
Дуже круто пішла, хороша книжка для професійного розвитку.
June 6, 2020
Really interesting book. Good to re-read from time to time. Most of the conclusions I've internalized at this point, except the part about deadlines, and that was good to go over again.
August 15, 2020
Counter intuitive truths about software engineering and software development activities. Full of wiseness and immutable lessons to learn.
July 8, 2021
A sadly dated view of software development at the turn of the millennium, when extreme programming was the hit new thing and nobody was talking about automated CI.
January 2, 2018
I'm a bit torn on this book. On the one hand, it's a wonderful collection of wisdom from many years in the software industry, backed with lots of sources, studies, and research. On the other hand, this wisdom is presented as a list of problems, with no attempt at offering any solutions to these problems. And it's a long list. You can only listen to someone rant about everything that's wrong with the software industry for so long before you tune out.
Within this laundry list of gripes, there are a few wonderful gems. This book would've been much more valuable if it had focused on just handful of these "facts", going deeper on each one, and exploring solutions in addition to the problems. Alas, you have to skim the book quickly, and put in your own effort to hone in on the interesting tidbits, and skip over the rest.
As always, I've saved a few of my favorite quotes from the book:
"The most important factor in software work is not the tools and techniques used by the programmers, but rather the quality of the programmers themselves."
"The issue was, “If your life depended on a particular piece of software, what would you want to know about it?� Bollinger responded, “More than anything else, I would want to know that the person who wrote the software was both highly intelligent, and possessed by an extremely rigorous, almost fanatical desire to make their program work the way it should. Everything else to me is secondary. . . .�"
"Most software tool and technique improvements account for about a 5 to 35 percent increase in productivity and quality. But at one time or another, most of those same improvements have been claimed by someone to have “order of magnitude� benefits."
"Learning a new tool or technique actually lowers programmer productivity and product quality initially. The eventual benefit is achieved only after this learning curve is overcome."
"The answer to a feasibility study is almost always “yes.�"
"For every 25 percent increase in problem complexity, there is a 100 percent increase in complexity of the software solution. That’s not a condition to try to change (even though reducing complexity is always a desirable thing to do); that’s just the way it is."
"When moving from requirements to design, there is an explosion of “derived requirements� (the requirements for a particular design solution) caused by the complexity of the solution process. The list of these design requirements is often 50 times longer than the list of original requirements."
"Fact 33: Even if 100 percent test coverage were possible, that is not a sufficient criterion for testing. Roughly 35 percent of software defects emerge from missing logic paths, and another 40 percent from the execution of a unique combination of logic paths. They will not be caught by 100 percent coverage."
"The concentration needed to do a good technical review job tends to diminish the amount of attention we pay to the social aspects of the review. During most of our social activities, a certain percentage of our being is devoted to the topic in question, and the remainder is devoted to making the social relationship work. At a software review, that becomes difficult. The focus needed to achieve rigor eats away at the energy we have left to work the social issues. And the social issues during a review can be profound."
"Fact 41: Maintenance typically consumes 40 to 80 percent (average, 60 percent) of software costs. Therefore, it is probably the most important life cycle phase of software."
"Fact 44: In examining the tasks of software development versus software maintenance, most of the tasks are the same—except for the additional maintenance task of “understanding the existing product.� This task consumes roughly 30 percent of the total maintenance time and is the dominant maintenance activity. Thus it is possible to claim that maintenance is a more difficult task than development."
Within this laundry list of gripes, there are a few wonderful gems. This book would've been much more valuable if it had focused on just handful of these "facts", going deeper on each one, and exploring solutions in addition to the problems. Alas, you have to skim the book quickly, and put in your own effort to hone in on the interesting tidbits, and skip over the rest.
As always, I've saved a few of my favorite quotes from the book:
"The most important factor in software work is not the tools and techniques used by the programmers, but rather the quality of the programmers themselves."
"The issue was, “If your life depended on a particular piece of software, what would you want to know about it?� Bollinger responded, “More than anything else, I would want to know that the person who wrote the software was both highly intelligent, and possessed by an extremely rigorous, almost fanatical desire to make their program work the way it should. Everything else to me is secondary. . . .�"
"Most software tool and technique improvements account for about a 5 to 35 percent increase in productivity and quality. But at one time or another, most of those same improvements have been claimed by someone to have “order of magnitude� benefits."
"Learning a new tool or technique actually lowers programmer productivity and product quality initially. The eventual benefit is achieved only after this learning curve is overcome."
"The answer to a feasibility study is almost always “yes.�"
"For every 25 percent increase in problem complexity, there is a 100 percent increase in complexity of the software solution. That’s not a condition to try to change (even though reducing complexity is always a desirable thing to do); that’s just the way it is."
"When moving from requirements to design, there is an explosion of “derived requirements� (the requirements for a particular design solution) caused by the complexity of the solution process. The list of these design requirements is often 50 times longer than the list of original requirements."
"Fact 33: Even if 100 percent test coverage were possible, that is not a sufficient criterion for testing. Roughly 35 percent of software defects emerge from missing logic paths, and another 40 percent from the execution of a unique combination of logic paths. They will not be caught by 100 percent coverage."
"The concentration needed to do a good technical review job tends to diminish the amount of attention we pay to the social aspects of the review. During most of our social activities, a certain percentage of our being is devoted to the topic in question, and the remainder is devoted to making the social relationship work. At a software review, that becomes difficult. The focus needed to achieve rigor eats away at the energy we have left to work the social issues. And the social issues during a review can be profound."
"Fact 41: Maintenance typically consumes 40 to 80 percent (average, 60 percent) of software costs. Therefore, it is probably the most important life cycle phase of software."
"Fact 44: In examining the tasks of software development versus software maintenance, most of the tasks are the same—except for the additional maintenance task of “understanding the existing product.� This task consumes roughly 30 percent of the total maintenance time and is the dominant maintenance activity. Thus it is possible to claim that maintenance is a more difficult task than development."
April 28, 2014
55 'facts' and 10 'fallacies' on the practice of software engineering: from managing, to planning, to programming etc. The structure is always the same, first the fact in one or two sentences, then one or two pages discussing the fact, then a page of the controversy (criticisms, or opponents of the 'fact'), then some sources. As such, the book is quick reading, you can read one or two 'facts' on the bus.
Of course, the author's opinions shine through - he really doesn't like vendor salespeople (they hype too much), managers should stay out of the way of programmers since managers don't know what programming is about, etc.
Some of these facts I've heard by now (the book is, after all, 12 years old), some of them overlap with The Mythical Man Month, some I hadn't heard before, some don't apply to me (bioinformatics programming: where neither plan nor design prevail).
Just a taste for a couple of interesting facts and fallacies:
- projects run late mostly because of faulty schedules and estimates
- most errors are errors of omitted coding logic (hard to test for)
- 100% test coverage is impossible (this is now widely accepted) and useless anyway
- the (average) wisdom of the software field is not increasing (what experienced programmers learn is evened out by newbies arriving, and for a long time the number of newbies is growing)
- programming should be taught by reading code instead of writing it (I don't agree with that one - too frustrating to read code if you've never before seen it)
- better software engineering development leads to more maintenance, not less (possibly because it's easier to add new features and change old ones)
- my favourite 'fallacy': 'software needs more methodologies' - nicely summarized here: (NSFW language)
Recommended for: All programmers.
Bonus best quote (in itself a quote):
Of course, the author's opinions shine through - he really doesn't like vendor salespeople (they hype too much), managers should stay out of the way of programmers since managers don't know what programming is about, etc.
Some of these facts I've heard by now (the book is, after all, 12 years old), some of them overlap with The Mythical Man Month, some I hadn't heard before, some don't apply to me (bioinformatics programming: where neither plan nor design prevail).
Just a taste for a couple of interesting facts and fallacies:
- projects run late mostly because of faulty schedules and estimates
- most errors are errors of omitted coding logic (hard to test for)
- 100% test coverage is impossible (this is now widely accepted) and useless anyway
- the (average) wisdom of the software field is not increasing (what experienced programmers learn is evened out by newbies arriving, and for a long time the number of newbies is growing)
- programming should be taught by reading code instead of writing it (I don't agree with that one - too frustrating to read code if you've never before seen it)
- better software engineering development leads to more maintenance, not less (possibly because it's easier to add new features and change old ones)
- my favourite 'fallacy': 'software needs more methodologies' - nicely summarized here: (NSFW language)
Recommended for: All programmers.
Bonus best quote (in itself a quote):
Reality is the murder of a beautiful theory by a gang of ugly facts.
December 31, 2013
What I liked: The author has decades of personal experience in software development, and the wisdom he's gathered over the years is absolutely apparent. This book was littered with valuable anecdotal gems that all software developers should hear.
What I didn't like: So much of this book was anecdotal. Don't get me wrong, I'm can appreciate anecdotes from a wise individual, but it's hard for me to accept "facts", especially with specific numbers attached to them, with nothing but anecdotal evidence provided.
Several times while reading this book I was astounded by what I read; in one section where he was citing his sources, he refused to cite the source for a fact because "I prefer not to provide sources for these alternate and erroneous views of sotware quality [...]". Many of the sources cited in this book are in references to books written by the author himself, which is a red flag in my world of reference integrity.
I've read several software development books, and writing quality matters in topics like these. The author's writing quality was fair, but this book could benefit from another revision by an editor.
What I didn't like: So much of this book was anecdotal. Don't get me wrong, I'm can appreciate anecdotes from a wise individual, but it's hard for me to accept "facts", especially with specific numbers attached to them, with nothing but anecdotal evidence provided.
Several times while reading this book I was astounded by what I read; in one section where he was citing his sources, he refused to cite the source for a fact because "I prefer not to provide sources for these alternate and erroneous views of sotware quality [...]". Many of the sources cited in this book are in references to books written by the author himself, which is a red flag in my world of reference integrity.
I've read several software development books, and writing quality matters in topics like these. The author's writing quality was fair, but this book could benefit from another revision by an editor.
October 28, 2016
Книга толковая. Читается довольно легко - как художественная, но с айтишным сюжетом. Ее вполне можно читать параллельно с чтением например какой-нибудь сугубо технический литературы типа Рихтера, Албахари, Эспозито и т.п. В голове оно не должно перемешаться. Читаю эту книгу уже не первый раз. Первый раз еще начинающим разработчиком - интересно, но тогда за живое не задело. И теперь перечитал уже имея за плечами боевой опыт разработчика ПО. Структурировал в голове мысли по теме. С фактами и заблуждениями трудно не согласиться. В основе них здравый смысл, а это пожалуй главный критерий. Большинство фактов и заблуждений актуальны и сейчас несмотря на возраст книги. Да и сам автор мне в дедушки годится, много повидал, опыта у него вагон и маленькая тележка. При всей кажущейся динамичности нашей айтишной сферы со всеми ее новыми технологиями, проблемы и нюансы описанные еще в прошлом веке не изменились. Мой вердикт - читать стоит!
April 30, 2016
The facts and fallacies presented in this book are very interesting in the sense that we are aware of many of them and no one does anything about it.
I really liked how the author focus a lot on maintenance; something that programmers spent most of their time doing, but very few realize of its difficulties and time-span.
One thing that bugs me is related to the book references for some of the facts/fallacies. Most of them have really good resources (from NASA for example); however, many other resources come from his own work. I would've had more confidence if there were less citations from his own work. Not saying that having own work citations is bad, but having many of them seem suspicious.
I do recommend the book to any software developer of any level of expertise. Even managers can get a huge benefit from reading it.
I really liked how the author focus a lot on maintenance; something that programmers spent most of their time doing, but very few realize of its difficulties and time-span.
One thing that bugs me is related to the book references for some of the facts/fallacies. Most of them have really good resources (from NASA for example); however, many other resources come from his own work. I would've had more confidence if there were less citations from his own work. Not saying that having own work citations is bad, but having many of them seem suspicious.
I do recommend the book to any software developer of any level of expertise. Even managers can get a huge benefit from reading it.
October 26, 2016
Some facts I used to be believe become fallacies in the author point of view.
Some of author's opinions agreed with mine.
This book is good for introducing to the Software Engineering field.
The maintainance part is one of the best I think.
Cause he pointed out many of the problems when running a maintainance project.
His definition about quality really impressed me.
Quality should be measured base on multiple perspective instead of Customer satisfaction + On Schedule and on Budget. They are some (from the management point of view maybe enough) but not all. Technologist expectations are also important. That's why we should reduce the distance and make our communication clear between Tech guys and Manage guys.
Nice book and worth thinking after read it.
Some of author's opinions agreed with mine.
This book is good for introducing to the Software Engineering field.
The maintainance part is one of the best I think.
Cause he pointed out many of the problems when running a maintainance project.
His definition about quality really impressed me.
Quality should be measured base on multiple perspective instead of Customer satisfaction + On Schedule and on Budget. They are some (from the management point of view maybe enough) but not all. Technologist expectations are also important. That's why we should reduce the distance and make our communication clear between Tech guys and Manage guys.
Nice book and worth thinking after read it.
Displaying 1 - 30 of 48 reviews
Can't find what you're looking for?
Get help and learn more about the design.