В далеком 1986 году, мистер Брукс написал статью «No silver bullet”. Эта статья в последствие стала классикой жанра. И хотя многие не читали оригинальную статью, тем не менее термин «серебряная пуля» очень прижился.
После этого статья вошла в книгу Брукса «мифический человеко-месяц». Тут эта книга есть на русском (похоже издание 95 года).
Для тех, кому лень читать много букв, там говорится о том, что в программировании не будет изобретено никаких методов или технологий, которые позволят существенно (скажем в 10 раз) улучшить эффективность разработки. Идея обосновывается тем, что вся разработка состоит из двух частей – сущности и побочных сложностей. И что сущность нельзя сделать проще, а основные побочные сложности (такие как, например, написание программ на assembler’е) уже упрощены.
Serg Kond в своем блоге сделал интересную заметку насчет статьи о программистском синхрофазотроне. Что по большему счету, я пытаюсь найти серебренную пулю. Я бы сказал, что действительно методика, которая повысит мотивацию хороших программистов может стать серебренной пулей XXI века. Отличие нынешней ситуации от 86 года в том, что разрыв у хороших и плохих программистов в соотношении эффективность/оплата очень уменьшился за последние двадцать лет. Проще говоря, выросло количество плохих программистов получающих достаточно высокие зарплаты и хороших программистов упершихся в зарплатный потолок (который не слишком далек от зарплат плохих программистов). Но, речь впрочем не об этом.
Просто, хочу внести свою небольшую лепту в обсуждение статьи Брукса.
Взглянем, что же произошло за последние 20+ лет, с тех пор пока была написана его статья. Я специально не хочу давать оценку каждому пункту, насколько он убыстрил программирование, чтобы не возникли споры именно вокруг этих цифр. Но, я хочу показать то, что ускорило написание программ.
Итак, к фактам:
А) Каждый программист получил в свое пользование персональный компьютер (а иногда и несколько).
Б) Компьютеры стали быстрее, что позволяет вести быстрее разработку (более быстрая компиляция и т.п. вещи)
В) Языке стали еще более высокоуровневыми (например, C# vs C).
Г) Операционные системы предоставляют API с функциональностью, которая гораздо богаче, чем в 86 году.
Д) Множество утилит теперь доступны для разработчиков – система контроля версий, трекинга багов, wiki и т.п.
Е) Ну и естественно, появился доступ к дичайшему количеству документации, обсуждений в интернете особенностей написания кода и т.п..
Я думаю, сюда можно прибавить еще несколько пунктов, если покопаться еще в голову. И ясно, что все эти пункты, хотя и ускорили разработку, но, пожалуй, если собрать их всех вместе то наверно они дадут один порядок в улучшение эффективности (вряд ли больше).
Однако, я напоследок оставил то, что действительно является «серебряной пулей».
Это – библиотеки. Точнее не только библиотеки, но и разнообразные платформы. За последние двадцать лет появилось гигантское количество открытого доступного кода или хотя бы платформ с открытыми интерфейсами. Казалось бы, ну и что? Ну есть библиотеки, и чем это поможет?
Приведу пример. Возьмем автоматизацию склада в 1986 и в 2008 году.
1986 год: Небольшая программка в текстовом режиме написанная на С (не на C++). Возможности – ввод пришедших товаров, удаление ушедших и показ текущих. База данных хранится в текстовом файлике.
2008 год: RFID ворота на складе, подключенные к машинам на которых установлен Ubuntu с программой, которая выгребает данных с RFID считыватели и по сети закатывает в БД. На сервере крутится программа, которая выгребает данные из БД и через SOAP загружает их в Sales Force Automation (я правда не уверен, что они работаю с складскими данными).
Итого, в первом случае мы имеем программку и человека, считающий ящики на входе и выходе, вводящий постоянно это в программу. Фактически полное отсутствие report’ов и невозможность получения данных на другом компьютере (интернета еще нет)
Во втором случае, мы получаем автоматическую систему, в которой не надо считать ящики, к которой можно иметь доступ из любой точки мира в любой момент, которая может построить два десятка разнообразных отчетов, графиков, статистики и т.п. Да, кстати, все это в красивом графическом оформление, которое можно напечатать и показать шефу.
Дай бог 0.01% второй системы написано программистом, а остальные (сайт sales force, библиотеки по работе с RFID, база данных, tcp/ip, xml, soap, графический интерфейс, броузер и т.п.) досталось ему фактически забесплатно. Если бы он пытался написать все сам (даже «срезая углы») у него это заняло бы всю жизнь.
Опять же не хочу выдавать конкретную цифру, во сколько раз ускорило ему написание, то что уже большинство технологий было готово для него.
Заметили, что в втором случае количество возможностей (и требований к системе) гораздо больше чем в первом? Именно, из-за этого мы и не заметили серебрянной пули, хотя она находится у нас под носом.
Вместе с эффективность разработки росли и размеры/требования задач. И если вчера всех удовлетворял интерфейс стиля «Нажмите 1, чтобы добавить товар. Нажмите 2, чтобы удалить товар», то сегодня все должно быть интерактивным, красивым, поддерживающим тысячи транзакций в секунду, совместимым с другими системами и т.п.
Я думаю, индустрия в целом продложит развиваться в туже самую сторону. Вряд ли изобретут что-то супер новое, что позволит серьезно улучшить эффективность. Единственно, что действительно ее будет увеличивать – имеющиеся наработки (библиотеки и платформы) и возможности их использования. С другой стороны задачи тоже продолжат рости (причем судя по всему быстрее, чем будут улучшаться наработки). Так что вероятнее всего разработки проектов постепенно будут становится все более долгосрочными.
P.S. Только дописав статью я понял, за что собственно говоря борется opensource communit. Ведь собственно во многом именно благодаря им мы получили улучшение в эффективности.
P.P.S. И, кстати, тот же самый WordPress, который я сейчас использую результат этого самого движения.
Вы плохо читали Брукса. Он же там в конце книги давал комментарии по поводу того, что изменилось. К сожалению, серебряной пули так и не нашлось — есть медная пуля в виде ООП, есть рост производительности ПК… но это все действительно акциденции, упрощения в сути разработки мы так и не получили.
Зато, действительно, получили диссонанс в качестве. Хороший программист в огромной степени самоучка, имеющий устоявшиеся взгляды на инструменты, методику разработки и способы решения задач. Когда набирается толпа таких «гениев» … правильно, они вынуждены притираться друг к другу похлеще чем молодожены в первый год совместной жизни. И очень вероятно, что получится как в той басне Крылова.
Да, кстати, сама книга написана аж в 75 году. С того момента категорически ничего не поменялось.
Что вы скажите по поводу наработок и open source и того примера, который я приводил?
Я и не спорил, что все вещи типа ООП и быстродействия — медные пули и дай бог вместе тянут на что-то большее чем медность.
Вот одна из попыток отыскать серебрянную пулю.
Фергус О`Коннэл. Как успешно руководить проектами. Серебряная пуля(через партнёра)
Мое мнение что серебряная пуля не в библиотеках и не в коде вообще, все это лишь инструменты для решения определённых задач, достижения определеных целей. А вот как использовать эти инструменты, как эффективно решать задачи — вот это главное, вот это то что всегда было и будет. То есть в треугольнике главное люди, подбор и управление людьми, так как они используют эти инструменты, и без мастера любой инструмент ничего не стоит. И не важно используешь ты дубинку или атомную бомбу, хотя эффективность последней увеличилась в миллионы раз, но смысла это не меняет. Смысл остается тот же самый, просто ты решаешь задачу на более высоком уровне, используя более высокоуровневые инструменты для ее решения.
«Невозможно решить проблему на том же уровне, на котором она возникла. Нужно стать выше этой проблемы, поднявшись на следующий уровень.» А. Энштейн
Я и не спорю, достаточно странно было бы если бы библиотеки пользовали сами себя. 🙂
Я написал, что увеличение мотивации людей работать хорошо — является серебряной пулей. Но задача мотивации толком не решена.
Но, хочу заметить, что даже если гениального программиста сейчас закинуть в 86 год, то его эффективность (в отсутствии тех же библиотек) упадет в сотни раз.
«увеличение мотивации людей работать хорошо» — я не понимаю при чем тут библиотеки? Мотивация и не зависит от библиотек. Я тебе об этом и говорю, технические достижения и психология вещи разные!
А что касается «гениального программиста», тут уже комментировали что время и затраты на разработку увеличились даже с использованием библиотек и тд. Тоесть решаются уже не те задачи которые были в 86, эти задачи уже в библиотеках решены 🙂 Решаются новые задачи, так что мы вернулись с того с чего начинали.
И в конце добавлю что после того когда вышла спецификация высокоуровневого языка С# 3.0 специалисты сказали что он стал сложнее уже чем С++ 🙂
Мотивация и библиотеки не причем.
Просто, библиотеки, как по мне — серебряная пуля.
Правильная мотивация — тоже может быть серебряной пулей.
Только из-за этого я и сделал в статье связку.
Насчет увеличение времени на разработку. Если задачи стали больше, это не значит что эффективность у программистов стала меньше. Все же считать увеличение и уменьшение эффективность нужно на равных задачах.
И еще насчет 86 года вспомнил. Если ты следишь за последними новостями в области программирования то сейчас все движется к функциональному программированию, и уже полным ходом идет работа над F# в той же микрософт. То есть спираль возвращается назад, только на уровне выше. 🙂
Да в общем, объектное vs функциональная программирование — одна малина в разных обертках.
Как я и писал, все это мелочи, которые дают сейчас очень небольшое ускорение каждая по отдельности.
А API операционных систем изменился как-то за последние 20 лет? Я как-то не заметил ничего, кроме косметических изменений. Библиотек хороших понаписали, да.
Ну, начнем с того, что 20 лет назад был DOS.
В тот момент он предоставлял достаточно немного возможностей
— работа с жестким диском
— работа с текстовым экраном
— работа с портами
Сейчас найдутся 10 человек, которые мне пришлют полный список возможностей DOS 😉 Включая встроенные возможности командной строки :))
Все таки, Windows сейчас на три головы выше по количеству предоставляемых возможностей.
Вот примеры того, что оно начало предоставлять (я копирую некоторые пункты отсюда Windows API http://msdn2.microsoft.com/en-us/library/aa383686(VS.85).aspx)
— Dynamic Data Exchange
— Debugging
— Input Method Editor (это ввод разных иероглифов и т.п.)
— Network Management
— Registry
— Synchronization
— Device Management
И т.п.
На самом деле, мы (программисты) ведь даже не задумываемся, что за каждой строчкой
«SELECT * FROM X» исполняется не только код БД, но еще исполняется работа с сетью, какой-нибудь DCOM, работа с оборудованием, распределение времени процессам и кучу другой базовой архитектурной фигни.
ну в общем то open source — это тоже бизнес.. Red Hat например очень активно скупает компании и пытается занять нишу которую не занял Microsoft, то есть малобюджетный рынок.
и я думаю что open source — это как раз те компании которые давят на гигантов-монополистов не давая им совсем зажиреть 🙂
начинают они со своих бесплатных и удобных продуктов, а потом наработав базу потенциальных клиентов думают как собрать деньги, в случае с Red Hat это тренинги и саппорт. Софт то бесплатный, но банк не может ждать пофикса какого-то бага от open source community, вот тут и начинает работтьплатный саппорт Red Hat.
и за 2007 год у них $400 000 000 доход и $ 59 000 000 чистая прибыль. неплохо 🙂
вот, если интересно можно пробежать глазами по их отчетности за 2007 год:
http://media.corporate-ir.net/media_files/IROL/67/67156/RHAT2007AR.pdf
Ну, это не совсем в тему статьи конечно.
Собственно open source состоит из многих частей. То, что я затронул — это наработки. Кстати, наработки даже не должны быть open source. Если я могу купить DLL, которая работает с RFID, это вполне ускорит эффективность.
Ну и соответственно open source, как ты заметил — это еще и бизнес, а еще хороший пункт давления одних крупных компаний на другие.
Тоже могу подчеркнуть, что вы плохо читали Брукса, иначе бы не стали это все писать.
Это все было за вас написано Бруксом.
Серьезно, прочтите еще раз его 16ю и 17ю главу последнего издания.
В частности, вы произвели «мысленный эксперимент Харелла».
Также вы не разделили сущности и акциденции, присущее программированию.
Ваше утверждение про библиотеки и open source также приведено у Брукса.
К тому же, не во всех компаниях, разработка ведется на персоналках, и уж тем более на C#.
Я работаю в такой компании, когда действительно приходиться работать по ночам, чтобы получить доступ к необходимой «машине», и выбивать это время у других команд. В моем случае, это суперкомпьютер, который заменяет еще не созданный GPU.
Книгу Брукса я читал пару лет назад. Так, что я ее действительно помню не идеально. Статью no silver bulllet я перечитал перед наисанием.
Не могли бы вы напомнить, что такое мысленный эксперимент Харелла?
Насчет разделения сущности и акциденций. Возможно это надо было сделать более подробно. Но, например в примерах все что я описал — это была сущность. Пользование RFID, report’ы и доступ через сеть никак не опишешь как акциденцию.
Да, не во всех компаниях разработка ведется на персоналках. Пусть скажем 10% компаний занимаются такими проектами. Я думаю всегда будут 10%, которые не вписываются в стандартные рамки и в которых естественно все сложнее, чем в накатанной колее. Однако, если кто-то покоряет Эверест, это не значит, что вся земля лезет вверх.
Кстати, я кручуть в mobile/wireless бизнесе и тоже вполне понимаю, что не все дорожки хорошо протоптаны.
Тоже могу подчеркнуть, что вы плохо читали Брукса, иначе бы не стали это все писать.
Это все было за вас написано Бруксом.
Серьезно, прочтите еще раз его 16ю и 17ю главу последнего издания.
В частности, вы произвели “мысленный эксперимент Харелла”.
Также вы не разделили сущности и акциденции, присущее программированию.
Ваше утверждение про библиотеки и open source также приведено у Брукса.
К тому же, не во всех компаниях, разработка ведется на персоналках, и уж тем более на C#.
Я работаю в такой компании, когда действительно приходиться работать по ночам, чтобы получить доступ к необходимой “машине”, и выбивать это время у других команд. В моем случае, это суперкомпьютер, который заменяет еще не созданный GPU
Про мои комментарии.
Прежде чем оставить комментарии, я достал Брукса и пролистал, чтобы быть менее голословным.
Мысленный эксперимент Харелла, это как раз, то что вы описали.
«Харел предлагает мысленный эксперимент, в котором «СПН» (no silver bullet, NSB), была бы написана в 1952 году, а не в 1986г, но содержала бы те же утверждения.»
Дело в том, что запросы компаний растут от года в год, также как и возможности программистов — больше стандартных компонентов.
Но сущность от этого не меняется. Все также нужно грамотно подходить к вопросу построения архитектуры, дизайна, тестирования.
Если мощности компьютеров возросли в 100 раз по проведению автоматизированного тестирования, то также возросли и запросы на количество этих тестов. и т.д.
Итак, все сводится к следующей идее:
а) Программисты стали в 90 раз быстрее
б) Требования стали в 100 раз больше
Итого, значит программисты стали медленнее.
Я считаю, что это неправильный подход.
С таким же успехом можно сказать, что раньше самолеты мог перелететь океан за 12 часов, а люди хотели перелететь за 11 часов. А теперь самолет перелетает за 7 часов океан, а люди хотят за 6 часов. Странно было бы делать вывод, что самолеты не стали быстрее.
Пожалуй я соглашусь с Бруксом, относительно того, что эффективность программирования никогда не уйдет в отрыв на порядок от требований. Но, эту формулировку можно применить к чему угодно, так как я вообще видел очень мало рынков, где производство превосходит на порядок потребление 🙂
Итого, нужно выяснить коэффициент с которым растут и требования и скорость написания программ.
И в общем-то в этом смысле будущее IT выглядее гораздо более красочно, чем если предсказывать, что требования будут расти, а вот скорость написания программ останется та же или вырастет незначительно.
А почему не получается комментарии в деревьях оставлять? 🙁
Для того, чтобы оставить иерархические комментарии, нужно нажать Reply to this comment под тем комментарием на который вы хотите ответить.
По умолчанию в самом низу показано окно добавления комментария на пост.
Еще одно (наиболее вероятное предположение), что используется какой-то броузер на котором не сработали скрипты, которые все это делают.
Вот та 17я глава.
http://webkomora.com.ua/ru/articles/web/management/man-month/17.html
Вы безусловно правы в том, что написали, но разделение Брукс делал другое.
opensource community как и все борется за прибыли 🙂
они просто отгрызают кусок рынка который не особо интересен титанам типа Microsoft, это я вижу работая в такой opensource компании 🙂
Я бы все таки, так бы не говорил.
Зачастую opensource равно титанам. За множеством продуктов стоят компании типа IBM, да даже тот же самый Microsoft.
И пожалуй, после того, как ранок отгрызен opensource он становится не интересен гигантам (и то не всегда).
A.Stelmakh
Созвучно вот с этим
http://www.kip.ru/realtime/2008/04/post-3.html
Современный успешный бизнес немыслим без верно разработанной маркетинговой стратегии, включающей целый комплекс операций по оценке и планированию деятельности компании на рынке. Во многих больших компаниях-производителях существуют маркетинговые отделы, которые занимаются продвижением товаров/услуг на рынке и проведением маркетинговых исследований. Узнать достоверную информацию о задачах пpедпpинимательcтва, развитии маpкетинга в Pоccии, пpинципах маpкетинга, целях задачах и функциях маpкетингового иccледования Подробнее смотрите на Элементы маpкетинговой cиcтемы