суббота, 21 мая 2011 г.

Q:Are we not engineers?

Thinking Metaphorically about Software Engineering
Думая метафорически о разработке программного обеспечения


Years ago I heard a comparison of software engineering to chemical engineering. I believe the intent of the analogy between the two fields was due to the fact that software engineering is a very young discipline just as chemical engineering was in recent history.
Несколько лет назад, я слышал, как сравнивали инженерию ПО и химическую технологию. На мой взгляд, причиной такого сравнения было то, что разработка программного обеспечения является очень молодой дисциплиной, как и химическая технология, которая появилась всего лишь несколько веков назад.
Metaphors get used a lot in our industry, in Chapter 2: "Metaphors for a Richer Understanding of Software Development" of Steve McConnell’s Code Complete they are discussed in some detail. In that chapter he cites the following: Метафоры и раньше очень широко использовались в нашей индустрии, во второй главе «Метафоры, позволяющие лучше понять разработку ПО», книги Стива Макконнелла «Совершенный код» детально рассматриваются самые различные метафоры. Вот некоторые цитаты из этой главы:
A confusing abundance of metaphors has grown up around software development. David Gries says writing software is a science (1981). Donald Knuth says it's an art (1998). Watts Humphrey says it's a process (1989). P. J. Plauger and Kent Beck say it's like driving a car, although they draw nearly opposite conclusions (Plauger 1993, Beck 2000). Alistair Cockburn says it's a game (2002). Eric Raymond says it's like a bazaar (2000). Andy Hunt and Dave Thomas say it's like gardening. Paul Heckel says it's like filming Snow White and the Seven Dwarfs (1994). Fred Brooks says that it's like farming, hunting werewolves, or drowning with dinosaurs in a tar pit (1995). Which are the best metaphors?
Множество метафор, описывающих разработку ПО, смутит кого угодно. Дэвид Грайс утверждает, что написание ПО — это наука (Gries, 1981). Дональд Кнут считает это искусством (Knuth, 998). Уотте Хамфри говорит, что это процесс (Humphrey, 1989). Ф. Дж. Плоджер и Кент Бек утверждают, что разработка ПО похожа на управление автомобилем, однако приходят к почти противоположным выводам (Plauger, 1993, Beck, 2000). Алистер Кокберн сравнивает разработку ПО с игрой (Cockburn, 2002), Эрик Реймонд — с базаром (Raymond, 2000), Энди Хант (Andy Hunt) и Дэйв Томас (Dave Thomas) — с работой садовника, Пол Хекель — со съемкой фильма «Белоснежка и семь гномов» (Heckel, 1994). Фред Брукс упоминает фермерство, охоту на оборотней и динозавров, завязших в смоляной яме (Brooks, 1995). Какие метафоры самые лучшие?

Additionally, in a recent blog post by Chris Aitchison, titled "You are NOT a Software Engineer!" the gardening comparison is also made, including the following statement:
В дополнение ко всему, Крис Ейтсон в своем посте под названием «Вы НЕ инженер-программист!», проводит аналогию с садоводством, делая также следующие заявление:
You can’t just plant the same plants as Facebook, Flickr or Twitter and expect them to take root regardless of the quality of your gardeners or the climate of your organisation.
Вы просто не можете сажать те же саженцы, что и Facebook, Flickr и Twitter и ожидать, что они укоренятся, независимо от качества ваших садовников или климата организации.
The point of the metaphor is that each company is like a different ecosystem with a different climate and different soil conditions, but could you not make the same metaphor about engineering, in civil engineering would not building a levee or a dam or a bridge or a highway all have different "ecosystems" as in chemical engineering the following might be different "ecosystems:" manufacture of penicillin via fermentation, manufacturing sulfuric acid, petroleum refining, or extracting aluminum from molten bauxite via electrolysis. So it seems that you can make a number of different metaphors fit anything. I confess that I really don’t care for the farming/gardening metaphor.
Идея этой метафоры в том, что каждая компания – это как отдельная экосистема, со своим климатом и своей почвой, но, насколько применима эта метафора для инженеров-строителей; выходит так, что вы не можете успешно построить дамбу или плотину или мост или шоссе, потому что у каждого этого сооружения своя «экосистема»? Точно так же как и в химический инженерии, для следующих продуктов могут быть свои «экосистемы»: для производства пенициллина при помощи ферментации, производства серной кислоты, переработки нефти или извлечения алюминия из бокситов по средствам электролиза? Похоже, что вы можете придумать множество различных метафор, которые подойдут подо что угодно. Признаюсь честно, я не любитель садоводческих и сельскохозяйственных метафор.
Another metaphor appears in a recent post By Chip Camden "Why programmers should study the art of programming":
Еще одна метафора появилась в недавнем посте Чипа Камдена «Почему программисты должны изучать искусство программирования»
To the average programmer in the trenches, debating the theory of computation is like discussing the chemical properties of saltpeter while in a gunfight: it may all be correct, but it doesn’t apply directly to the problem in front of them.
Обсуждение теории вычислений, для среднестатистического программиста, сидящего в траншее, это все равно, что обсуждать химические свойства селитры в то время, как идет перестрелка: все может быть очень правильно и толково, но не относится непосредственно к проблеме, стоящей перед ним.

Now being in the trenches could refer to trench warfare or pre-mechanization mining or construction, but the gunfight statement implies the former. The gunfight/battle analogy gets used from time to time and I don’t think it is very fitting. Gunfights and warfare are destructive endeavors, which lead to the death of people: "It's a hell of a thing, killin' a man. Take away all he's got, and all he's ever gonna have." When you take a life, not to trivialize it, you are destroying all the information a person knows, in that way it is similar to the deletion of a file or loss of data. The analogy is based on the idea that the people doing the actual work have to deal with "front line" level stresses of getting the job done and the general chaos that seems to befall software projects. But software construction is a creative process not a destructive one.
Фраза «быть в траншее» может означать и «окопную войну» и добычу материалов для строительства, но, заявление о перестрелки явно подразумевает первое. Метафоры о войнах и перестрелках в разработке ПО, появляются время от времени, но я не думаю что они уместны. Перестрелки и войны – это разрушающие действия, сопровождающиеся гибелью людей: «Это не просто — убить человека. Ты отбираешь всё, что у него есть. И его будущее тоже». Отнимая жизнь другого человека, вы уничтожаете всю информацию, которую знал этот человек, и это подобно удалению файла или потере данных. Эта аналогия основана на той идее, что человек, пытаясь выполнить свою работу и бороться с хаосом, который вот-вот поглотит и разрушит весь проект, подвергается стрессам, вполне соизмеримым тем, что и на линии фронта. Но, разработка программного обеспечения – это конструктивный процесс, а не деструктивный.
I don’t mean to didactic or facetious but I think it’s also particularly ironic that he chose to reference saltpeter, which is a constituent in black powder, an older form of gunpowder that has been replaced by smokeless powder. Actually in the late 1800’s understanding the problem with black powder, which is based on the chemical properties of saltpeter, in some cases made the difference between winning and losing in a gunfight or battle. Black powder forms a thick white smoke, in some gun battles if you had smokeless powder you could remain concealed, but if you had black powder you were sending up a big smoke signal that revealed your position. This new technology gave you a distinct tactical advantage that could save your life. This smoke created another problem which was when a lot of people fired a lot of rounds it created an immense amount of smoke so that you could no longer see what you were shooting at in fact the term "fog of war" is thought to be based on this phenomenon.
Я не хочу быть поучающим или особо остроумным, но мне кажется особо ироничным то, что для своей метафоры Чип выбрал именно селитру, которая входит в состав черного пороха, устаревшей формулы пороха, которая была заменена бездымным порохом. В конце 1800-х годов, понимание проблемы черного пороха, которая основана на химических свойствах селитры, в некоторых случаях решало исход боя. Черный порох образует густой белый дым, и в некоторых боях, имея бездымный порох, вы могли оставаться незамеченным, но используя черный порох, вы создавали большой заметный дымовой сигнал, который выдавал вашу позицию. Новая технология предоставляла преимущества, позволяющие сохранить вам жизнь. А дым от черного пороха создавал еще одну проблему, так как ведя огонь продолжительное время, накапливалось огромное количество дыма, через который стрелок уже не мог видеть цель. Этому явлению было дано имя «туман войны».



I am not sure how apt the chemical engineering metaphor is either, but there are some interesting parallels. The early chemical manufacturing process to produce sulfuric acid is called the Lead chamber process and it was invented in the mid 1700s. The process was not very well understood and was inefficient in that it required the use of expensive nitrates often from Chile which were partially lost as nitric oxide vapor, and it took over a hundred years before a way to recycle part of the nitrates was added to increase the efficiency of the process. The discipline of chemical engineering was codified in the late 1800s when college curricula and associations for chemical engineering were created.
Я не знаю, насколько будет уместной эта химическая метафора, но все же прослеживаются интересные параллели. На заре становления химической промышленности для добычи серной кислоты использовались большие промышленные свинцовые камеры, которые были изобретены в середине 18-го века. Этот процес был не очень хорошо изучен и был неэффективным в том, что требовал дорогостоящих нитратов, привозимых из Чили, которые за время перевозки частично окислялись и испарялись. Только через 100 лет ученые нашли способ перерабатывать нитраты для увеличения эффективности производства. Только тогда, в конце 19-го века, химическая технология как дисциплина, была надежно закреплена в программах колледжей и была создана отдельная ассоциация.
Over time the sciences of chemistry and stoichiometry advanced as did thermodynamics which made major steps forward around the same time. I am over simplifying here but eventually little understood processes that were discovered and tweaked by trial and error became better understood and could be controlled and improved empirically by applying the laws of science and mathematics.
С тех пор передовые науки химии и стехиометрии, точно так же, как и термодинамика, сделали важнейшие шаги в перед в своем развитии примерно в одно и то же время. Я все немного упрощаю, но в конечном итоге, в это время, мало понимаемые процессы, которые были обнаружены и отлажены методом проб и ошибок, стали более изученными и контролируемыми и улучшенными эмпирическим путем применения законов естественных наук и математики.
Another parallel is the focus on reusable processes, in that if you are building a new plant to manufacture sulfuric acid you don’t want to design it from scratch each time. An interesting and abstract parallel is that both disciplines have their entropies, i.e. thermodynamic vs. information. A social parallel may be the transformative effect that software is having on our lives and our society is as profound as that of industrial scale chemical production, this keyboard and almost thing I can see right now has been influenced in some way by chemical engineering. Also what are the negative sides of these industries, what problems are we creating by the unregulated and somewhat opaque policies in regards to chemicals and what might some of the issues with software and IT be?
Следующая параллель заключается в процессах многоразового использования, а именно в том, что когда вы строите новый завод по производству серной кислоты, вы не хотите придумывать его с нуля каждый раз. И в любой дисциплине есть факторы хаоса и неоднозначности, в том числе и в термодинамике и в информатике. С точки зрения социологии, сегодня программное обеспечение оказывает на нашу жизнь не меньшее влияние, чем химическая промышленность, ведь именно эта клавиатура, на которую я смотрю, и почти все, что я могу видеть – продукты химической промышленности. Но, какие негативные последствия могут повлечь за собой эти химические вещества, и могут ли быть эти проблемы химической промышленности родственными к проблемам разработки программного обеспечения?
Now admittedly there is pretty big difference between a physical chemical process or the physical construction of a bridge and software construction. There are obvious parallels to building things in that people have to come together to build something that is greater than what one single individual could build. And there are similarities to chemical processes in that once you build it that you have keep it up and running and you will probably need to do maintenance and make improvements while it is operational and even in some cases take it off line or build a new one in parallel while the old one is still in production. Also might we possibly view computer science and math as related to software engineering as chemistry, stoichiometry and thermodynamics are related to chemical engineering?
Сейчас, правда, есть довольно большая разница между химической индустрией, строительством мостов и разработкой программного обеспечения. Общим со строительством есть то, что людям необходимо собраться вместе, чтобы создать нечто большее, что невозможно сделать одному человеку. Сходство разработки ПО и химической промышленности в том, что если вы уже создали и запустили некоторый продукт, вам необходимо его обслуживать и вносить необходимые улучшение в том время, пока продукт работает, а в некоторых случаях снять его с линии или создавать новый продукт параллельно, пока старая версия все еще в продакшене. Точно так же мы могли бы рассмотреть информатику и математику как тесно связанные науки с разработкой программного обеспечения, точно как в химии, стехиометрия и термодинамика связана с химической промышленностью.



Like Donald Knuth I too think there is an artistic element to software, this idea is not incongruent with building or bridge architecture which is a process that organizes groups of people to build something that can be beautiful. Perhaps a possible analogy for software engineering would be the construction of a bridge where we still don’t really understand all of the physics behind it or the best way to go about it. As a result when we are done it might stay up and it might not and it will probably take longer than we thought to build it.
Соглашаясь с Дональдом Кнутом, я считаю, что в разработке программного обеспечения есть очень важный элемент творчества, который, так же как и строительство мостов, позволяет объединить группу людей для создания чего-то прекрасного. Возможная аналогия с разработкой программного обеспечения – это строительство мостов, где мы до сих пор не четко осознаем все процессы стоящие за процессом строительства.
I guess the question is, is it possible to create a discipline of software engineering that is as effective as the other engineering disciplines? If we use the chemical engineering metaphor, where are we in the time line of understanding the underlying science and applying it to our process? Perhaps we are at the equivalent point to the mid to late 1800s but I very much doubt the years will map linearly, it’s probably more like an exponential mapping. The elusive software engineering is probably its own entity, are our metaphors confining our thinking and hindering our ability to objectively look at this problem?
Вопрос здесь в том, можем ли мы создать дисциплину, изучающую разработку программного обеспечения, и не уступающую по эффективности другим дисциплинам? Если использовать метафору химического производства, то где мы находимся сейчас на пути понимания самой науки и ее внедрения в процесс? Исходя из такого сравнения, возможно, мы находимся где-то в начале или в конце 19 века, но я очень сомневаюсь, что шкала времени тут имеет линейный характер и скорее всего эта шкала развития будет больше похожа на экспоненту. А возможно, разработка программного обеспечения – это отдельная сущность, и наши метафоры сдерживают наше мышление и препятствуют объективно взглянуть на реальность?
The software industry is also different from almost any other technical industry in history, just in the sheer number of people who now participate in it worldwide and it seems that the barriers to enter the field can be lower than that of other engineering and scientific disciplines in regards to formal degrees.
Индустрия разработки программного обеспечения отличается, практически, от любой другой известной нам технической индустрии, учитывая огромное количество людей участвующих в разработке программного обеспечения по всему миру, и кажется, что порог вхождения в эту область деятельности может быть ниже, чем у других инженерных дисциплин, и в соответствии с официальными научными степенями.

A: We Are Developers!
Ответ: Мы – Разработчики!

Оригинал текста: Q:Are we not engineers?
Автор оригинального текста: Geoff Moes, архитектор программного обеспечения и Java разработчик
Перевод: Дмитрий Жарий

Комментариев нет:

Отправить комментарий