Мысли вслух

Что значит имя?

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

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

Последовавший за этим мучительный процесс осознания производственного характера программирования в нашей стране протекал особенно мучительно. Большинство программистов имели математическое, а не инженерное образование, и потому им приходилось не просто осваивать новые технологии, а ломать свое мировоззрение. Поясню это на одном небольшом примере. Много копий было сломано в ту пору на тему эффективности программ. Проблема была, нет слов, актуальной, учитывая маломощные ресурсы компьютеров. Но уже тогда ясно была видна разница в подходах. Скажем, если для инженера задавался временной интервал, за который программа должна была отреагировать на событие - 1 секунда, то он, уложившись в эту самую секунду, считал свою задачу выполненной. Математики же и прочие художники пластались до изнеможения, кладя силы на достижение максимальной эффективности. Ощущаете разницу, а точнее, пропасть в мировоззрении? Даже само понимание результата - разное. Инженер полагает результатом систему, работающую в соответствии с техническим заданием, причем ресурсы на разработку потрачены в соответствии с заранее определенным планом. Художественная душа не успокоится,  пока не решит задачу наиболее изящным способом. Кстати говоря, наши светлые головы и вольные художники от программирования весьма часто обламываются, попав на вожделенный Запад - именно потому, что они совершенно не приспособлены к работе в производственном режиме. Сдается мне, что до самого последнего времени работа программиста никак не была регламентирована ресурсам и времени и денег. Традиционная стихия наших разработчиков - твердый оклад, не шибко зависящий от результатов, плавающий график и прочие прелести НИИшной жизни. 

Однако даже там, где необходимость заставила задуматься о жесткой организации работы программистского коллектива (а это прежде всего - "ящики"; в конце восьмидесятых я много тусовался на семинарах и конференциях по технологии программирования и был там одним из немногих штатских), так вот, даже там процесс этот принял какие-то странные формы. Как-то, изначально оттолкнувшись от термина program product и произвольно переведя его как "программное изделие" (чувствуете силу слова?), наши программистские начальники стали строить всё от этого, весьма неоднозначного термина. 

Все строилось как бы на автомате. Вот есть изделие - это программа. Так? Так. Изделие производят на заводе, следовательно, работа программиста должна быть организована также, как на заводе. Так? Так. То есть, нужно нормировать труд, запланировать производительность труда и т.д. В чем измерять производительность труда? Да очень просто. Программа - это изделие. Так? Программа состоит из операторов. Так? Стало быть, программист производит что? Правильно, операторы. Ну и все!

Вы будете долго смеяться, но в те героические годы уже были определены нормы для программистов- 5000 операторов в год. Уже в ближайший пятилетний план закладывали, сколько операторов за пятилетку выдаст наш новый вид промышленности. Куча народа защитила кандидатские и докторские диссертации на вопросах оценки производительности труда программистов. 

Много еще чего было, в том числе и созданный в те годы и многажды руганный потом ГОСТ ЕСПД, который исходил из той же концепции и был практически полностью передран с ГОСТ ЕСКД (единая система конструкторской документации).

И тут пришел мальчик и чуть было все это не испортил. Как ни странно, этим мальчиком был я. Я свято верил в промышленный подход в программировании, я искренне хотел как можно скорее решить технологические проблемы разработки программ. И у меня был уникальный материал, которого в те годы ни у кого не было и быть не могло. Дело в том, что с самого начала своей программистской деятельности я  не выбросил ни одной программы. Распечатки и по сей день лежат у меня в архиве. Но и это еще не все. Как раз в том году, когда я начал профессиональную деятельность как программист, я начал вести учет времени по системе Любищева, то есть у меня, в числе прочего, были зафиксированы затраты времени на все мои проекты, причем с разбивкой по этапам (проектирование, программирование, отладка и т.д). Причем все это уже было загнано в компьютер (если, конечно, можно назвать ЭВМ ЕС-1022 компьютером:о). Разумеется, я фиксировал моменты смены технологии (скажем, в 1979 году был переход к структурному программированию, а в 1982 году мы опробовали технологию "хирургической бригады"). Ну а теперь скажите, отказались бы вы от искушения свести все это в кучу и обработать? Посмотреть, например, как менялась производительность труда с годами (а у меня были данные, слава Богу, за 10 лет). Разумеется я тогда тоже оценивал производительность труда в операторах, хотя уже тогда мне казалось это немного странным: все-таки, я писал и на ассемблере, и на ПЛ/1 и даже на ФОРТРАНе - и как было сравнивать их операторы? 

Результат обработки меня ошеломил. Оказывается, производительность т руда у меня все десять лет ПАДАЛА. Причем интересный факт - она падала даже на разработке одной и той же системы (а мы выпустили в течение трех лет три версии одной и той же программной системы. Надо сказать, что на самом деле мы просто три раза написали ее заново от начала до конца, поскольку за эти три года у нас дважды кардинально изменилось понимание задачи и используемые технологии. 

Как же так? я же четко вижу, что на решение той же самой задачи я трачу гораздо меньше времени? Почему же тогда объективная оценка производительности труда оказывается такая же или даже хуже?

Ларчик открывался просто. Когда я сравнил объемы трех версий одной и той же программы (кстати говоря, очень немаленькой по тем временам), оказалось, что, хотя функциональная мощность программы с каждой версией росла, ее объем от версии к версии УМЕНЬШАЛСЯ. Оказывается, я просто научился программировать и мог излагать алгоритмы гораздо лаконичнее. Уменьшалось и время разработки, но немного медленнее (любопытно, что при этом собственно программирование "худело" по затратам времени, а предпроектная работа стремительно "толстела"). Но факт оставался фактом: на одну и ту же программу (если исходить не из размеров, а из функциональной мощности) я тратил с каждым годом все меньше времени. А подсчитанная производительность труда не росла, а падала. Из всего этого однозначно следовало, что соотношение "количество операторов / затраченное время" не годится в качестве оценки производительности труда. Результаты этого исследования я в довольно осторожной форме опубликовал в журнале УСиМ (Управляющие системы и машины). 

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

Я попытался тогда сформулировать понятие программы корректно с праксеологической точки зрения. Если кому интересно, можете почитать здесь. Но вкратце скажу, что самый важный момент был в том, что из себя представляет программное изделие и в какой момент происходит его изготовление. Впрочем, об этом я расскажу подробнее в следующий раз.


Опубликовано:   СТАЛКЕР 1999
© Алексей Бабий 1999