Чому ІТ-індустрія не може швидко виконати великі бездоганні проекти, як в інших галузях?

Подивившись серії MegaStructures National Geographic , я здивувався швидкості завершення великих проектів. Після того, як попередня робота (дизайн, технічні умови тощо) буде виконана на папері, сама реалізація величезних проектів займає всього кілька років, а іноді і кілька місяців .

Наприклад, Airbus A380 "офіційно запущений 19 грудня 2000 року", а "на початку березня 2005 року" літак вже був випробуваний. Те саме стосується величезних нафтових танкерів, хмарочосів тощо.

Порівнюючи це із затримками в індустрії програмного забезпечення, я не можу не задатися питанням, чому більшість ІТ-проектів настільки повільні, а точніше, чому вони не можуть бути настільки ж швидкими та безвідмовними, в тому ж масштабі, даючи достатньо людей?

Такі проекти, як Airbus A380, представляють обидва:

• Основні непередбачені ризики: хоча це не перший побудований літак, він все ще підштовхує межі технології, і речі, які добре спрацювали для менших авіалайнерів, можуть не працювати для більшого через фізичні обмеження; аналогічно застосовуються нові технології, які ще не використовувалися, оскільки, наприклад, вони були недоступні у 1969 році, коли було зроблено Boeing 747.

• Ризики, пов’язані з людськими ресурсами та управлінням загалом: люди, які відмовилися в середині проекту, неможливість зв’язатися з людиною через те, що вона у відпустці, звичайні людські помилки тощо.

Маючи такі ризики, люди все ще досягають таких проектів, як ці великі авіалайнери, за дуже короткий проміжок часу , і, незважаючи на затримки доставки, ці проекти все ще є надзвичайно успішними та якісними.

Що стосується розробки програмного забезпечення, проекти навряд чи такі масштабні та складні, як авіалайнер (як технічно, так і з точки зору управління), і мають трохи менше непередбачених ризиків з боку реального світу.

Тим не менш, більшість ІТ-проектів є повільними та пізніми , і додавання більшої кількості розробників до проекту не є рішенням (перехід від команди на десять розробників до двох тисяч іноді дозволить доставити проект швидше, іноді ні, а іноді лише зашкодить проектувати та збільшувати ризик не закінчити його взагалі).

Ті, що все-таки доставляються, можуть часто містити багато помилок, що вимагають послідовних пакетів обслуговування та регулярних оновлень (уявіть, що "встановлення оновлень" на кожен Airbus A380 двічі на тиждень, щоб виправити помилки в оригінальному продукті та не допустити аварії літака).

Як можна пояснити такі відмінності? Це пов'язано виключно з тим, що індустрія розробки програмного забезпечення занадто молода, щоб мати можливість управляти тисячами людей на одному проекті, щоб дуже швидко поставляти великі, майже бездоганні продукти?

Марш смерті Еда Вайдона торкається багатьох цих питань мета-типу.

Загалом, в галузі індустрії програмного забезпечення бракує багато наступного, що заважає великим проектам.

• Стандартизація та розподіл робочих предметів.

  • Це, безумовно, стало краще, але дизайнерських конструкцій все ще немає, щоб вибудувати велику систему. Певним чином, програмне забезпечення навіть не може погодитись з тим, що потрібно для даного проекту, тим більше, що не можна розбити речі на компоненти.
  • Аерокосмічна, будівельна, будівельна, автомашина тощо. Усі архітектури, що керуються компонентами, мають досить щільний інтерфейс, що дозволяє повністю паралельно розвиватися. Програмне забезпечення все ще дозволяє занадто багато кровоточити у відповідних областях.

• Великий корпус успішних подібних проектів. A380 був не першим великим літаком, який побудував Airbus . Існує велика кількість великих програмних програм, але багато з них різко постраждали в тому чи іншому аспекті і не наблизилися до того, щоб їх називали "успішними".

• Великий корпус дизайнерів та будівельників, які працювали над низкою подібних та успішних проектів. Що стосується успішного проекту проекту, не маючи людського таланту, який там був, зроблено, що ускладнює справи з точки зору повторюваності.

• "Ніколи" двічі не будуючи одне і те ж. Багато в чому літак, як і будь-який інший літак. У нього є крила, двигуни, сидіння тощо. Великі програмні проекти рідко повторюються. Кожне ядро ​​ОС суттєво відрізняється. Подивіться на невідповідність файлових систем. І з цього питання, скільки справді унікальних ОС? Великі в якийсь момент стають клонами базового елемента. AIX , Solaris , HP-UX , ... глашатай назад AT & T System V . Протягом кожної ітерації Windows просунулася неймовірно. Варіанти Linux, як правило, повертаються до того самого ядра, що і Лінус. Я підводжу це, оскільки варіанти, як правило, поширюються швидше, ніж справді унікальні, власні ОС.

• Дійсно погана оцінка проекту. Оскільки коефіцієнт повторюваності настільки низький, важко спрогнозувати, наскільки це буде в кінцевому підсумку і скільки часу знадобиться для побудови. Зважаючи на те, що керівники проектів та менеджмент не можуть покласти руку на код і насправді бачити, що робиться, генеруються нереалістичні очікування щодо термінів.

• КК / КК не наголошується настільки сильно, як це могло б бути або повинно бути для великих проектів. Це повертається до того, що між компонентами є більш слабкі інтерфейси та відсутність жорстких специфікацій того, як компоненти повинні працювати. Ця в'ялість дозволяє передбачити непередбачувані наслідки та помилки.

• Послідовно вимірювана кваліфікація. Як правило, люди говорять про кількість років, які вони працювали мовою X або програмуванням. Час в використовується як заміна калібру або якості навичок. Як уже згадувалося багато разів, проводити інтерв'ю та знайти хороший талант програмування важко. Частина проблеми полягає в тому, що визначення поняття "добро" залишається дуже суб'єктивним.

Я не хочу бути негативним, і я думаю, що індустрія програмного забезпечення досягла значних успіхів від того, де ми були. Такі форуми та інші справді допомогли сприяти розмові та обговоренню принципів дизайну. Є організації, які працюють над стандартизацією знань «базового рівня» для інженерів програмного забезпечення. Звичайно, є можливість для вдосконалення, але я думаю, що галузь пройшла довгий шлях за досить короткий проміжок часу.

Відповідь дивно простий: ці «інші галузі» дійсно мають високу інтенсивність відмов. Ми просто порівнюємо неправильні речі. Написання програмного забезпечення часто називають "складання", і тому ми порівнюємо його з фазами виготовлення або будівництва в інших галузях. Але якщо поглянути на це, це зовсім не будівництво: це дизайн . Конструкції програмного забезпечення написані в коді, а складання здійснюється за допомогою комп'ютерів, будь то компілюючи програмне забезпечення або безпосередньо інтерпретуючи його на ходу.

Багато проектів в інших галузях промисловості або тривають довше, ніж спочатку оцінювали, коштують значно більше, або просто ніколи не бачать завершення. Звучить знайомо?

Отже, що ми робимо, коли плануємо програмне забезпечення? Ну, ми все ще розробляємо, але на більш ранній стадії.

У програмному забезпеченні немає виробничих приміток. Створення кінцевого компонента є (порівняно) дешевим, а тиражування цього кінцевого продукту є досконалим і ефективно безкоштовним - ви копіюєте артефакти збірки.

Щоб зазначити деякі цифри:

1. Зміна вимог після початку впровадження ; наприклад, коли перший завод Airbus A380 почав створюватися на заводі, я не можу повірити, що якби хтось захотів ще 200 місць, їх би там помістили; але у великому програмному проекті, навіть після того, як програмісти розпочали розробку, можна додати ще 5 типів користувачів.
2. Складність - великі програмні проекти надзвичайно складні; мабуть, найскладніші проекти людського типу, розроблені та розроблені;
3. Недостатньо ресурсів витрачається на етап архітектури та проектування ;
4. Повна незрілість - інженерія програмного забезпечення є відносно молодою дисципліною порівняно з іншими сестрами інженерії; це має два наслідки: а) не так багато евристики та передового досвіду; б) Не так багато дуже досвідчених фахівців;
5. Відсутність математичного підтвердження - у більшості випадків математичні формальні методи не використовуються для доведення того, що частина програмного забезпечення працює так, як потрібно; натомість використовується тестування. Це справедливо і в інших інженерних галузях, які значно більше покладаються на математику; причиною цього є така складність;
6. Rush - у багатьох менеджерів є недосяжні терміни; тому якість коду ставиться на друге місце через термін.

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

Попередження питання дещо недосконале. І A380, і Boeing 787 були доставлені на роки пізніше.

У випадку з A380 значна затримка була спричинена французькими та німецькими підрозділами Airbus, використовуючи різні та трохи несумісні версії програмного забезпечення CATIA . Це несумісно проявилося як електропроводки, які не зовсім підходили до літака.

З CATIA, яка є найбільш широко використовуваним програмним забезпеченням для проектування літаків, нічого не було, але хтось десь кинув кулю конфігурації програмного забезпечення.

Boeing 787 також зазнав затримок, пов'язаних із програмним забезпеченням, але більшість його проблем були більш традиційними новими проблемами з літаком, такими як контроль ваги та доставка нестандартних деталей постачальниками.

І A380, і B787 мали змінити конструкцію крил після того, як у початкового літального апарату виникли структурні проблеми.

Великі складні проекти важкі людям у всіх сферах.

Хлопець хмарочоса тут. Не впевнений, чи зможу я відповісти на ваше запитання, але я, безумовно, можу пролити трохи світла на різні предмети нитки. Будівлі дійсно відбуваються дуже швидко. Основним обмеженням є локальність (правила). Але загалом для високої будівлі від початку до кінця потрібно від 3 до 10 років.

Я думаю, що порівняння нової будівлі з новим програмним проектом не дуже точне. Нова будівля ближче до нової версії ядра або ОС. У цьому відношенні розробка програмного забезпечення відбувається набагато швидше. Ми ніколи не будуємо з нуля, оскільки це буде завданням високого ризику, на який клієнт ніколи не підпишеться. Більшість проектів і розробок в будівлях є похідними від перевірених і завершених проектів.

З особистого досвіду будується лише кожен десятий проект. Процес орієнтований на розвиток, а не на дизайн, тому в той момент, коли щось на зразок ціни на сталь піднімається, весь проект виходить за вікно або розроблений, оскільки дизайн є дешевою складовою процесу.

Дизайн займає місяць на схематичну схему, два - шість місяців на розробку дизайну, ще півроку на деталі та будівельні документи командою архітекторів, консультантів по плануванню, інженерів-конструкторів, вітроенергетиків, інженерів з обслуговування, консультантів з кількості та витрат, геодезистів, інженери з доступності, і список продовжується ...

Аргумент віртуального проти фізичного не дуже точний. Ми також працюємо в основному з віртуальними інструментами, і, крім того, ми віддалені від часу і масштабу від нашого кінцевого продукту. У більшості випадків ми навіть не можемо перевірити аспекти будівель у макетній шкалі, і ми використовуємо моделювання, щоб спробувати передбачити, що може виникнути.

Існують відмінності, але це може бути приблизно однаково. Ми маємо не тільки взаємозв’язані одиниці та кілька рівнів багаторівневих абстракцій та інтерфейсів, але й люди дуже спеціалізуються на невеликих частинах процесу, які ускладнюють спілкування.

Щодо аргументу дизайну проти розробки, я думаю, що обидва процеси побудовані на основі дизайну. Академічно звучить приємно тримати їх розділеними, але це неможливо розробити, якщо ви не знаєте, як все працює. Ви просто збільшуєте ризик невдачі.

В цілому моя (потенційно неправильна) оцінка, на думку ОП, полягає в тому, що програмування - це більше мистецтво, ніж інженерія. Навіщо людям насолоджуватися і навіть робити це безкоштовно, знаходити в ньому вираз і витонченість? Інформатика також (як і олово) більше наука, ніж інженерія. Чому б ви намагалися довести алгоритми, а не просто латати існуючі частини разом і працювати над тим, щоб все просто працювало? Не впевнений, чи це має сенс; Я не хлопець із програмного забезпечення.

Один із аспектів, який мене вражає при розробці та розробці програмного забезпечення - це саме середовище. Комп'ютери роблять людиноцентричну роботу дуже неприродною. Все настільки чітко і допусків мало. Важко подумки обходити це, а деякі йдуть із цим, скидаючи складність усередині. Якщо нічого іншого, це може мати щось спільне з цим?

Тоді скільки часу займала конструкція цих? Рік? Два? Десять років? Дизайн - це найскладніша частина того, що щось будувати, сама конструкція - це легко.

Виходячи з цієї статті , повільно розуміється, що розробка програмного забезпечення - це здебільшого процес проектування, де проектним документом є сам вихідний код. А процес проектування абсолютно відрізняється від виробничого. Це вимагає досвідчених людей і неможливо планувати, адже навіть невеликі зміни вимог можуть призвести до величезних змін у загальній архітектурі проекту. Це розуміння є основою для гнучких методологій , орієнтованих на поліпшення якості коду як остаточного документа проектування, а також тестування та налагодження як частини процесу проектування, як і тестування моделей літаків у вітрових тунелях.

Сама конструкція обробляється компіляторами автоматично. І завдяки цьому ми можемо за лічені хвилини створити цілі вироби.

Причина, по якій програмні проекти закінчуються з величезними затримками та завищеними витратами, полягає в тому, що менеджери все ще думають, що вони можуть оцінити, передбачити та спланувати такий процес розробки. Це зворотній удар частіше, ніж є насправді дійсним. Вони все ще вважають, що прив’язуючи людей до жорсткого будівельного процесу, вони можуть якось підвищити якість, хоча кінцевий результат здебільшого протилежний збільшенню витрат та пропущеним строкам.

Уявіть собі, в середині конструкції Airbus A380 хтось засідав на зустрічі і сказав: "Хе, не могли б це побудувати як триплан?" Інші приєдналися, сказавши: "Так, так. Триплан. Більше крил - краще". Наступні роки тебе проводять, перетворюючи конструкцію A380 на триплан. На іншій зустрічі хтось каже: "Триплан? Це старе. Ми хочемо біплан. Просто зніміть одне з крил".

Або уявіть, що посеред проекту з будівництва мосту хтось каже: "Ге, ми щойно уклали угоду з судноплавною компанією. Їм потрібен міст бути ще на 40 футів вище, тому що їхні кораблі набагато вище. Виправте це. Спасибі . "

Це лише деякі причини, через які програмні проекти, великі та малі, закінчуються невдачею з тривожною швидкістю.

Як хтось із машинобудування, який працює в ІТ, я часто замислювався про причини низького рівня успішності в ІТ.

Як і інші в цій темі, я також часто пов'язував збої з незрілістю ІТ, відсутністю детальних стандартів (так, я серйозно, ви коли-небудь перевіряли стандартний аркуш простого болта?) Та відсутність стандартизованих компоненти та модулі.

У інших галузях промисловості, як будівництво будівель або суднобудування, також є набагато більше "прокладених шляхів": знання та досвід конкретного прототипу рішення, який - у індивідуальній формі - знову і знову використовується. Ніколи не замислювалися про те, чому будівлі, кораблі чи літаки різної величини та призначення якось виглядають настільки подібними? (є винятки з правила звичайно ...)

Це тому, що ці прототипи добре досліджені, добре зрозумілі, зазвичай використовуються та мають перевірений досвід. Не тому, що це було неможливо зробити інакше. У ІТ стандартизації рідко буває так: (великі) проекти, як правило, переосмислюють компоненти, займаючись дослідженнями та доставкою одночасно та з тими ж людьми!

Це неминуче призводить до одноразових продуктів, які дорого розробляються та обслуговуються, схильних до помилок і виходять з ладу непередбачуваними способами в невизначених умовах. І через це, звичайно, ця продукція набагато швидше застаріла, списується та замінюється за однаково великі витрати лише на трохи кращі. Те, що потребує ІТ, - еквівалент промислової революції, яка перетворила ремісників середнього віку на ефективні фабрики.

Однак, є фактори, які роблять ІТ справді унікальним. На відміну від інших згаданих галузей, ІТ справді всюдисущий: він використовується у всіх аспектах нашого сучасного життя. Тож це маленьке диво, що ІТ досягли такого великого прогресу і здатний забезпечити результати, які він робить.

Боюся, що я не згоден з вашим твердженням.

Airbus і Boeing - два приклади компаній, які будують літаки. Скільки там компаній, що будують літаки? Дуже мало, якщо ви порівняєте це з тим, скільки компаній будують програмне забезпечення.

Накрутити проект літака настільки ж просто, як і накрутити програмний проект. Якщо тільки бар'єр на шляху входу був настільки низьким у галузі авіабудування, як і в галузі програмного забезпечення, ви, безсумнівно, побачите багато невдалих літальних проектів.

Подивіться на машини; Є високоякісні виробники, які виготовляють дуже міцні та дуже вдосконалені автомобілі (думаю, Land Rover, Mercedes), і є такі, які створюють автомобілі, які не протримаються і року, не потребуючи їх ремонту (подумайте, Kia чи Cherry). Це прекрасний приклад галузі з дещо нижчим бар'єром для входу, якщо ви почали мати слабших гравців.

Програмне забезпечення не відрізняється. У вас багато глючних продуктів, з іншого боку, Windows, Office, Linux, Chrome або Google Пошук - це дуже якісні проекти, які були доставлені вчасно і мали аналогічний рівень якості, як літальний апарат.

Інший момент, який багато хто сумує, - це те, наскільки технічне обслуговування йде на обслуговування автомобіля, танкіста або літака, які ми просто сприймаємо як факт життя. Кожен літак повинен пройти технічну перевірку перед кожним злетом. Ви повинні перевіряти свій автомобіль кожні кілька кілометрів і робити це регулярно, наприклад, міняти масло, міняти шини.

Програмне забезпечення також потребує цього. Якби тільки люди витрачали стільки часу на діагностику, профілактику чи аудит стану та якості програмного забезпечення, як це робиться з механічними / фізичними продуктами, я би очікував набагато менше тверджень, як це. Чи читаєте ви журнали додатків кожного разу перед запуском? Ну .. якби це літак, вам доведеться ;-)

Цифрові будівельні блоки можуть бути 1 або 0. Між ними немає.

Механічна конструкція має рівень толерантності. Я можу поставити одну, меншу за ідеальну заклепки в місток, і вона, швидше за все, не впаде, проте в коді навіть один раз екземпляр ставлення 0, де має бути 1, може провалити всю програму.

Через логічний та інтерактивний характер обчислень будь-які, навіть дуже невеликі зміни, можуть призвести до різкого збою.

Я часто дивувався одному і тому ж. Це, звичайно, відчуває (іноді) так, ніби ми купа любителів, які не мають уявлення, що ми робимо. Мені не подобаються пояснення, які покладають провину на менеджерів чи інші зовнішні фактори - ми, розробники, повинні відповідати за те, що ми створюємо.

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

Це створило культуру, де помилки - частина повсякденного життя . Їх приймають з плечима. Хоча деякі помилки, ймовірно, неминучі, чи повинні вони домінувати у нашій щоденній роботі ? Я цілком розумію менеджерів, які не відчувають, що QA вартих клопотів, саме тому, що вони все одно очікують помилок. Я не розумію програмістів, які не докладають усіх зусиль, щоб створити код без помилок, тому що виправлення помилок є нудним.

По суті я вважаю, що це проблема культури, і я сподіваюся, що вона зміниться.

Інженерні стандарти та практика в ІТ (як незалежна галузь) сильно відрізняються, ніж в аерокосмічній галузі . Це, мабуть, найлегше зрозуміти, якщо врахувати, як реагують ІТ-фахівці, стикаючись зі стандартними документами для ІТ в аерокосмічному просторі . Наприклад, стандарти C ++ Joint Strike Fighter, які останнім часом пройшли шлях до Інтернету.

Багато хто висловлює знущання або зухвалу відставку (хотілося б, щоб ми могли так зробити); і багато хто реагує насмішками, стверджуючи, що немає практичного способу доставки споживчих товарів таким чином. Це навіть може бути правильним, враховуючи очікування не споживачів, а керівництва. Існує велика недовіра до кодерам, які просто кодують і кодують протягом декількох тижнів, нічого не демонструючи. Допоможи Бог кодеру, який просто проектує щось на два тижні. Не так із літаками.

У програмному забезпеченні люди дійсно сподіваються, що зараз щось буде. Звичайно, міркування йдуть, це займе трохи часу, щоб воно було справді міцним; але хіба ми не можемо за тиждень описати просту фразу? Людина також дізнається, що складні речі, описані чесно, складно, рідко збуджують уяву; і, отже, багато інженерів виявляються співучасниками у уявному світі справді простих речей, які складаються творчо (на відміну від світу важких справ, які робляться дуже добре).

Деякі речі від мене:

1- Стандарти та деталі: Вони виробники літаків , а не розробники. Я не зовсім впевнений, але я здогадуюсь, що багато частин передано в аутсорсинг. Вони не створюють власних електронних / інструментів, вони отримують місця у якоїсь компанії, двигуни, ймовірно, розроблені в іншому місці тощо

Програмні проекти, з іншого боку, майже завжди починаються з нуля, лише на місці є невеликі рамки / помічники.

2- Час виходу на ринок: Час не є критичним питанням для літаків. Маю надію, що дизайн Airbus був доопрацьований за роки до його закінчення, і вони вирішили нехтувати будь-якими великими проривами, які можуть статися в той час. (Те саме стосується виробників автомобілів, наприклад, передова технологія, яку вони розробляють на даний момент, вийде на вулиці через 5-10 років.)

Що стосується програмного забезпечення, то ви повинні бути дуже спритними, якщо я запускаю грандіозний проект зараз і потребую трьох років, щоб його розробити без будь-яких змін, шанси досить високі, що я покладаюся на технологію, яка більше недоступна, або мій продукт повністю застарів. Це в свою чергу пропонує безліч проблем.

3- Цикл випуску та версії. - Літак потрібно повністю закінчити, коли він буде "випущений". Немає стабільних бета-версій, нічних версій чи подібних. Крім того, щойно це буде зроблено, його можна змінити лише невеликим способом. Ви не можете додати додатковий рівень на 100 місць до існуючого боїнгу, це просто неможливо.

Програмне забезпечення, з іншого боку, має додаткові зміни, які часто є лише «побудовою, яка працює», але не обов'язково готовою продукцією. Крім того, в ІТ незвично сказати "ей, додамо ще один багажник до нашого літака, який вміщує додаткові 50 тонн".

Я думаю, що відповідь досить проста:

1) Фізичне будівництво та реалізація існують так довго, як і люди - у нас було тисячі років, щоб розробити наші методи та прийоми для реалізації фізичних проектів. "Конструкція програмного забезпечення", яка вимагає абсолютно нового та різного набору навичок, не має більше 50 років - у нас ще не було достатньо часу, щоб усе це зрозуміти.

2) Віртуальна побудова складніше - ви повинні «бачити» речі, які не мають фізичної реальності. Це вимагає від вас проаналізувати та абстрагувати багато інформації, перш ніж ви навіть дізнаєтесь, як повинен виглядати ваш продукт та кроки, які потрібно здійснити для його створення. Не так, коли будують міст чи споруду.

3) Часто набагато складніше знайти джерело збою або помилки програмного забезпечення, ніж це робиться при фізичній техніці. Якщо балка перекручується, ви бачите, де вона вигинається, і ви бачите опори, які утримують її та виходять з ладу тощо. Виявлення програмного дефекту може спричинити за собою вивчення великої кількості коду та взаємодіючих процесів - складних, трудомістких і не пов'язаних з закони фізики та математики таким, яким є фізичні структури.

Я спробую відповісти, використовуючи дослівну копію статті із вбудованої музи Джека Гансле. Хоча це говорить прошивку скрізь, просто подумки замініть її на програмне забезпечення.

У порівнянні з Що?

Прошивка - найдорожча річ у Всесвіті. У своїй чудовій книзі "Закони Августина" Норман Августин, колишній генеральний директор компанії "Локхід Мартін", розкриває історію про проблему, з якою стикається оборонна громада. Високопродуктивний винищувач - це делікатний баланс конфліктуючих потреб: дальність палива та продуктивність. Швидкість проти ваги Схоже, до кінця 70-х винищувачі були приблизно такі важкі, як і коли-небудь. Підрядники, завжди отримуючи більший прибуток, даремно шукали щось, що вони могли б додати, що коштувало багато, але що нічого не важило.

Відповідь: прошивка. Безмежна вартість, нульова маса. Зараз на "Авіоніку" припадає більше половини вартості винищувача. Це шматок змін, якщо врахувати, що останній американський винищувач, F-22, коштує круту третину мільярда естради. Коли він пов'язує цю історію, Августин практично вболіває.

Але чому програмне забезпечення таке дороге? Том ДеМарко одного разу відповів на це питання цими трьома словами: порівняно з чим? Він продовжував обговорювати відносно нудні ділові справи, але ця відповідь резонувала в моїй свідомості роками. У порівнянні з чим? За допомогою програмного забезпечення ми регулярно створюємо поведінку продуктів безпрецедентної складності. Звичайно, код дорогий. Але ніколи в історії цивілізації ніхто не будував нічого такого заплутаного.

Розглянемо наступний сорт бульбашок, який безсоромно підняли з Вікіпедії та не перевіряли на точність:

void bubblesort(int * A, int n){

    for(int i(0); i < n; ++i)

        for(int j(0); j < n - i - 1; ++j)

            if(A[j] > A[j + 1])

                std::swap(A[j], A[j + 1]);

}

Це всього лише 110 символів, що не знаходяться в просторі, можливо, скинуті через годину-дві. Припустимо, у нас не було програмного забезпечення і довелося реалізувати сорт, використовуючи якусь іншу стратегію. Що б це коштувало?

Інженер-механік може похвалитися, що його професія будувала сортувальники задовго до комп'ютерів. Розглянемо сортувальник карт 82 моделі IBM 1949 року ( http://www.columbia.edu/acis/history/sorter.html ) з пропускною здатністю 650 карт в хвилину, а не менше, ніж наш фрагмент коду може управляти навіть на 4 МГц Z80. Модель 82, звичайно, сортувала лише один стовпчик картки за один раз; Для повного сортування колоди може знадобитися кілька десятків проходів.

Скільки часу знадобилося, щоб сконструювати та побудувати цього звіра? Роки, без сумніву. А його функціональність блідне порівняно з нашим кодом, який набагато швидше і який може працювати з гігантськими наборами даних. Але це було 1949 р. Скільки часу знадобиться, щоб створити міхурний сорт з електронних компонентів - без FPGA та VHDL чи процесора?

За годину я керував приблизною блок-схемою, одна над рівнем чіпа (блоки мають назви типу "суматор", "16-бітний засув" тощо). Але логіка послідовності очевидно досить безладна, тому я щойно закинув ПЛД, припускаючи, що в якийсь момент було б не надто важко написати відповідні рівняння. І так, можливо, це порушує правило непрограмованої логіки, але спроектувати та налагодити всю цю логіку за допомогою воріт у будь-який розумний проміжок часу настільки ж малоймовірно, як газ на галлон-галон.

Якщо припустити 16-бітові слова та адреси, схемі знадобиться близько десятка 16-бітових засувок, суматорів тощо. Плюс пам'ять. І я поняття не маю, як несортовані дані надходять в оперативну пам'ять або як результати експортуються. Це невизначені вимоги до дизайну. Програмне рішення, природно, вирішує ці вимоги саме актом написання прототипу функції.

Переклад грубої блок-схеми на схематичну може зайняти добу. Тоді є час розробити та виготовити друковану плату, замовити та завантажити деталі (та змінити конструкцію для вирішення несподіваних, але неминучих проблем із закінченням терміну експлуатації), а потім, звичайно, змусити схему працювати. Ми могли б говорити про тижні зусиль і багато грошей для дошки, деталей та відповідного тестового обладнання.

Все це замінить 7 маленьких рядків коду. Мало реальних вбудованих програм менше 10 000; багато перевищує мільйон. Скільки обладнання та скільки інженерії знадобиться для заміни реальної, великої комп’ютерної програми?

Розгляньте справжню програму, як електронну таблицю. Скільки схем потрібно, щоб зробити його без процесора? Це може бути розмір міста.

Прошивка - найдорожча річ у Всесвіті, але лише через немислиму складність проблем, які вона вирішує. Але це набагато дешевше будь-якої альтернативи. Тож коли ваш начальник роздратовано запитує, чому програмне забезпечення займає так багато часу, ви знаєте, що сказати. У порівнянні з чим?

Так що! Програмне забезпечення / прошивка має незрівнянну складність.

Інженерія та управління програмним забезпеченням принципово відрізняються, ніж у багатьох інших інженерних сферах. Результати роботи не є фізичними, а виробничий процес - це процес проектування та розробки. Створення іншої копії програмного забезпечення має по суті нульову граничну вартість; вся вартість виявляється на розробку першого примірника.

Через відносну молодість інженерії та управління програмним забезпеченням як дисципліни, існують деякі дезінформації та неправди, які все ще сприймаються як факт ( див. Це посилання ), що перешкоджає розробці програмного забезпечення та інженерії в цілому.

Не всі розробники створені однаково. Одні хороші, інші - ну, ні.

Спробуйте постійно читати код інших людей, щоб відчути, що я говорю. Занадто багато зайвих логічних тверджень можуть додати ризик. Ці ризики можуть призвести до неправильної поведінки або помилок. Не вистачає логічних тверджень і тепер у вас є нульові посилання. Хороший програміст це розуміє і знає, коли робити що і де. Але ніхто не ідеальний. Речі складні. Додайте погано продуману роботу інших людей, і легко зрозуміти, як тікають проекти.

На будівництво соборів знадобилося до 100 років.

Деякому літаку Airbus для роботи потрібен 1 мільйон рядків коду.

Чим більше часу ви щось вдосконалюєте, тим більше вдосконалюєтесь, тому дайте індустрії програмного забезпечення пару століть пробну помилку, щоб покращитися, і ми побачимо, скільки потрібно для розробки міцного величезного проекту без помилок або недоліки.

У великих організаціях часто трапляються великі проекти. Якщо ви ніколи не працювали у великій організації, є одне, що гарантовано знищує продуктивність і продуктивність: бюрократизм.

Дивно, але багато людей не знають, що таке бюрократія (її часто плутають з політикою), або навіть якщо / коли у них є проблеми з бюрократією.

Нещодавно ми завершили проект із впровадження аутентифікації смарт-карт. Спочатку його оцінювали в три місяці. Минуло 15 місяців. Не було жодних витрат, бюджету, обсягу чи технічних причин затримки. Діяльність насправді була досить вузькою - лише для акаунтів з підвищеними привілеями (акаунти адміністратора), близько 1200 загальних рахунків.

Ще одним важливим фактором є ваші ділові партнери. Сюди входять постачальники. Якщо у ваших партнерів є проблема, яка спричиняє затримку у вашому проекті, існує не так багато варіантів, які фактично виправлять проблему із затримкою. Вони не працюють безпосередньо для вас, і ви, можливо, не зможете звільнити одну людину з партнера, що може стати причиною. Партнер може бути звільнений або може бути застосований до фінансових стягнень чи відмовок, але це не змінює факту, що проект спричинив затримку. Це саме те, що відбулося з Boeing, коли вони здійснили стратегію пошуку мамонта з Boeing 787 Dreamliner .

У мене є коротша версія для вас:

Що б не було легко зробити або упорядкувати, ми пишемо програму, щоб зробити це замість нас.

А потім натомість боройтеся з мета-процесом.

Це не так вже й справді, але щодня створюються тисячі блогів замість того, щоб писати блогові двигуни. Кожного робочого дня записуються тисячі макросів Excel, замість того, щоб писати для них спеціально розроблені програми баз даних.

Є багато інших факторів - деякі з них тут згадуються - але я хотів додати цю точку до дискусії.

Відсутність відповідальності ... Люди позов ідуть, коли літак зазнає аварії. Програмна індустрія відмовляється від будь-якої відповідальності за будь-який дефект програмного забезпечення, тому створює відсутність стимулів для створення надійного та безпечного продукту.

Більшість великих проектів мають високу ступінь відокремленості підпроектів, де можна визначити невелику кількість дизайнерських обмежень; весь проект запрацює, коли ці підпроекти будуть виконані. Якщо в підпроекті щось піде не так, цілі зусилля не піддаються сумніву; ви просто шукаєте альтернативні способи завершити підпроект (наприклад, використовувати інший двигун).

Це можливо, але важко, як практично, так і з точки зору людської природи, в програмних проектах.

Частково в інших галузях навчилися важким чином, що подібне відокремлення є хорошою справою. Наприклад, якщо ви збираєтесь використовувати літакові двигуни Rolls Royce, вам не потрібно використовувати спеціальні болти та кріплення Rolls Royce, які працюють лише з крилами з певною конструкцією, а потім, якщо ви намагаєтеся перейти на Пратт і Уітні, вам доведеться переробити все крило з нуля (що, в свою чергу, вимагає повного перероблення фюзеляжу, що в свою чергу вимагає придбання різних сидінь, а це, в свою чергу, вимагає придбання іншої розважальної системи під час польоту, котрий...). Можливо, є кілька зв’язків - ви не можете просто поміняти двигуни без обережності - але великі проекти, як правило, працюють краще, коли такі речі зведені до мінімуму.

Я постулюю, що великі програмні проекти, розроблені як кластер невеликих програмних проектів із чистими інтерфейсами між собою, не будуть виходити з ладу особливо часто, доки великий проект насправді вирішується кластером малих проектів. (У цьому плані можна помилитися.)

Побудова програмних систем дуже відрізняється від побудови фізичних структур. Тобто реалізація дуже сильно відрізняється. Наприклад, будуючи величезний танкер, ви виконуєте безліч відносно простих (нелегких, хоча!) Завдань, таких як зварювання деталей разом роботом або вручну, затягування всіх гайок і болтів, фарбування, виготовлення прикрас, несучи все обладнання та меблі тощо. Все це дуже прості речі.

Однак, коли мова йде про програмне забезпечення, воно стає набагато складнішим . Наприклад, як саме ви реалізуєте захищений логін та дані користувача, що зберігають частину продукту? Які бібліотеки та інструменти ви можете використовувати? З якими бібліотеками та інструментами ви знайомі? Як саме ви займаєтеся написанням функції хешування + засолювання і як ви гарантуєте, що вона є надійною? Це можна зробити настільки багатьма способами, що неможливо встановити жодних фактичних практичних моделей дизайну для подібних речей. Так, зазначені шаблони проектування дійсно існують в меншому масштабі , як «кращі практики», але кожна програмна система сильно відрізняється від інших, і польові досягнення і зміни в такому швидкому темпі , що це практично неможливо , щоб НЕ відставати.

Будуючи будинок, ви насправді не стикаєтеся з такими проблемами, коли розумієте, що основні опорні стіни здаються недостатніми та потребують заміни, вимагаючи від вас зруйнувати прогрес досі та починати з основи, переробляючи опорні стіни . Ви вирішуєте подібні проблеми на етапі проектування , оскільки передбачити, які опорні стіни потребує ваша будівля, порівняно просто.

Однак це не стосується програмного забезпечення. Ви не можете реально спроектувати весь продукт як єдине ціле, а потім реалізувати його. Процес розробки програмного забезпечення, як правило, є ітераційним, і цілі та вимоги змінюються під час впровадження та тестування продукту. Розробка програмного забезпечення в цілому - це ітераційний процес, під час якого зазвичай змінюються речі, коли це найменше очікується, і багато разів такі зміни ставлять перед собою завдання, які потребують більшої праці, більшої складності і, на жаль, і, в кінцевому рахунку, більше грошей, часу та наполегливої ​​праці, щоб правильно вийти.

Отже, по суті, причина, по якій важко реалізовувати великі проекти та оцінювати терміни та дорожні карти проекту, полягає в тому, що розробка програмного забезпечення та особливо робочого дизайну є дуже складними сферами. Складність - корінна проблема.

Визначення "великий проект" перекошене.

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

• Клон Pac-Man.
• Калькулятор
• Текстовий редактор

Я впевнений, що ти думаєш ... "але це невеликі проекти! Текстовий редактор простий ". Я б не погодився з вами. Комп'ютери надзвичайно складні. Просто встановити та налаштувати користувачів в операційній системі часом може бути складно, і ви навіть не написали ОС або не побудували обладнання.

Проекти, про які ви говорите, - це величезні проекти, схожі на дослідження космосу. Як ви знаєте, скільки часу потрібно для розвитку міжгалактичних подорожей? На якій моделі ми її базуємо? У вас є відомі ноуни, відомі невідомі, невідомі знання і, нарешті, невідомі невідомі, які трапляються багато в розробці програмного забезпечення.

Я думаю, що проблема одна з очікувань. Тільки тому, що технологія є, це не означає, що її використання буде деяким часом успішним (або розумним у використанні). Якщо б інші галузі поводилися так, як це робили в індустрії програмного забезпечення, ми мали б продати пилососи з чорною дірою до кінця десятиліття. Або якийсь "прозорливий" мав би ресурси, щоб побудувати місячну базу, і вирішив би, що Starbucks дійсно "закруглить" досвід для відвідувачів. Я не думаю, що проблема полягає в галузі програмного забезпечення, але очікування покладені на неї.

Хоча це навряд чи єдине, що можна було б згадати, я вважаю, що варто зазначити одну основну річ. Більшість продуктів призначені для відповідності існуючій поведінці. Навіть продукт, який є радикальним проривом (наприклад, автомобіль), як правило, побудований, щоб відповідати існуючій поведінці, і просто зробити його трохи простішим / легшим / дешевшим / що б це не було зробити. Так, там часто деякі побічні ефекти на існуючому поведінці , а також (наприклад, отримання палива для автомобіля замість їжі для коней), але більша частина останніх має тенденцію бути досить незначним побічним ефектом.

На відміну від цього, майже будь-яке програмне забезпечення, яке не змінює поведінку користувачів (наприклад, нехай вони роблять свою роботу значно легше), в основному гарантується повним провалом з першого дня. Гірше, що великі програмні проекти не просто передбачають поведінку користувачів на індивідуальному рівні, але поведінка великих груп - часто цілісність організації.

Коротше кажучи, розробка самого програмного забезпечення часто є найлегшою частиною роботи. Важкою частиною є перепланування робочих місць людей для них. Почати це важко; зробити це таким чином, що не тільки буде працювати, але і бути прийнятим, все ще набагато складніше.

Airbus A380 не був успішним проектом, як ви вже згадували. Я, мабуть, працюю в компанії CAD / CAM, і мені сказали, що це (у нас теж був пріоритет Airbus) затрималося на кілька років, оскільки вони використовували різні версії програмного забезпечення в іншій компанії. Тобто різні частини проектувались у різних частинах світу. І під час інтеграції вони дізналися, що всі дизайни не можуть бути інтегровані, тому вони повинні переробити його в одній версії. Тож дивлячись на це, я не думаю, що це було успішним. Якби це прийшло 2-3 роки раніше, це було б зміною гри для Airbus.

Що стосується надійного програмного забезпечення, ви дивитесь на будь-який літак, автомобіль (ABS, EPS, клімат-контроль тощо) або космічний човник, у них більше 50% програмного забезпечення, яке працює на них, і вірите мені, що вони дуже надійні. Просто ми більше наближені до програмного забезпечення, і є набагато більше програм, тому ми бачимо в них більше помилок.

Відвідайте веб-сайт : http://www.globalprojectstrategy.com/lessons/case.php?id=23 і подивіться, наскільки успішним був Airbus A380.

Тут програмний інженер, який має інженерну освіту, і дружину, яка працює в будівництві. У нас були довгі дискусії (та аргументи) щодо відмінностей наших робочих місць.

Розробка програмного забезпечення полягає в розробці нових речей . Практично все базове було десь зроблено в бібліотеці з відкритим кодом. Практично на будь-якій роботі, де наймається інженер-программіст, їй доводиться проектувати щось, що не існує.

Щось подібне до побудови та більшості форм інженерії, речі, які інакше були б у «бібліотеці» програмного забезпечення, вже повністю розроблені. Хочете побудувати вежу? Просто скопіюйте та вставте плани з існуючої структури з кількома модифікаціями.

Насправді, одна з головних причин, що я вирішив не стати інженером, полягає в тому, що ви витрачаєте більшу частину свого часу на розробку 10% вдосконалення існуючого винаходу, коли той самий час можна було б використати для програмування чогось більш помітного, наприклад, соціальної мережі .

Нових конструкцій в техніці не так багато; надзвичайно кваліфікований інженер - це той, хто може маніпулювати існуючим дизайном у щось нове або вдосконалити його. Але майже від кожного програміста очікується модифікувати проекти, зламати їх або створити щось нове.

Погляньте на те, наскільки повністю змінилися стандарти: від складання до C до C ++ до Java, JavaScript, C #, PHP тощо. Існує не так багато коду, який можна переробити з 10 або 20 років тому. Це зовсім інше, щоб сказати ... автомобілебудування чи авіаційне виробництво, коли ви можете продовжувати вдосконалюватись на проектах з десятиліть тому.

Управління проектами, як відомо, складно у програмному забезпеченні . Оцінки часу найкраще робити людьми, які виконують роботу , але коли вони зайняті складанням оцінок, вони не пишуть код . Це спокушає людей взагалі уникати будь-якого управління проектами.

Часто багато коду залежить від конкретних людей, і якщо ці люди запізнюються або не можуть виконувати їх, код не рухається вперед. На відміну від цього, якщо ви хотіли побудувати автомобіль, ви можете просто найняти різних людей для збирання шин, шасі, акумулятора, двигуна тощо. Об'єктно-орієнтовані та існуючі рамки роблять це можливим, але це може бути не практично, коли ви проектуєте все з нуля.

У програмі можуть бути допущені збої . Тестування може бути дорогим. У програмному забезпеченні дуже спокусливо пропустити все тестування, коли можна просто виправити збій. У більшості інженерних форм "крах" може бути фатальним.

У вас є методи програмування, які використовують обширне тестування, як екстремальне програмування (яке фактично використовувалось у програмних мегапроектах). Але в умовах жорстких термінів (які можна зробити спеціально жорсткішими), спокусити пропустити все це програмування та запустити помилки. Стиль Джоела Спольського "завжди виправляти всі помилки" заощадить більше часу в довгостроковій перспективі, але недисциплінований пропустить це і провалиться.

Невеликі проекти краще . Дружина одного разу попросила мене влаштуватися на роботу у велику компанію. Це закінчилося аргументом того, що великі компанії - це погані компанії ... для неї велика компанія мала багато ресурсів, досвід, функціональне управління проектами та правильні процедури. Для мене велика компанія - це динозавр, де більша частина вашого часу витрачається на фіксацію коду, його тестування та документацію.

Я бачив ІТ-проекти на мільйони доларів, над якими працювали менше 10 людей. Більше людей уповільнило б проект і додало зайвої бюрократії. WhatsApp - приклад "маленького" проекту, який коштує мільярди доларів. Не так, що великі проекти неможливі, але вам просто не потрібно тисячі людей, щоб виробляти мільярди доларів на програмне забезпечення.

Однією з причин, яка насправді не була висвітлена в інших питаннях, є те, що сфера програмного забезпечення впроваджує інновації зі швидкістю, яка рідко зустрічається у світі, що базується на матеріалах.

Однією з причин цього є те, що еволюція програмного забезпечення є позитивним циклом зворотного зв’язку, оскільки для побудови програмного забезпечення використовується програмне забезпечення (мови програмування, засоби збирання, IDE). Це найочевидніший приклад закону Рея Курцвейла про прискорення прибутковості, внаслідок чого прогресує з експоненціально зростаючою швидкістю. Після того, як ви освоїли один фреймворк, мову програмування, протокол зв'язку, саме час перейти до наступного.

Якби літаки були побудовані як програмне забезпечення, ми б змінювали матеріал з кожною іншою моделлю, подвоювали їх потужність і швидкість кожні 18 місяців, замінюючи технологію двигунів для кожної нової моделі чимось щойно придуманим, додаючи при цьому можливість плавати і шукати позаземні життя.

О, і в ідеалі він слухає голосові команди та дублюється як повністю занурений кінотеатр, арена пейнтболу та нічний клуб з темною кімнатою, коли ваша робоча поїздка закінчиться. Те ж саме! (Компанія, яка побудувала літаки, які щойно надійно дісталися вам від А до Б, пішла на живо через рік після виходу одного з кінотеатру, пейнтболу та функції нічного клубу.)

Для мене головна проблема, з якою стикається інженерія програмного забезпечення - це використання кейсів, користувачів та крос-платформ.

Використовуйте випадки

Скільки випадків використання літака має? Більшість це просто перелетіти з одного місця в інше. Можливо, є більше таких, як радари, контроль руху тощо, але випадок використання зрозумілий і не дуже. В інженерії програмного забезпечення ми стикаємося з незрозумілими вимогами та користувачами, які не знають, чого хочуть. Інший користувач потребує різної конфігурації / потоку, чи можна літак налаштувати так, як хоче користувача (я хочу мати телевізор і холодильник!)?

Користувач

Хто керує літаком? Пілот, пілот, кілька управителів (якщо рахувати) та оператори башти. Всі вони за фахівець і мають чіткі посадові інструкції. Програмне забезпечення використовується нобухами та муляжами, не кажучи вже про злих хакерів та зломщиків, в той час як вони все ще потребують інтеграції з іншими модулями (такими як OpenID або Google AdSense ). Якщо літаком можуть керувати манекени, поки ще вціліли від ракет або розбійників ніндзя, то можна сказати, що літак має однакову якість з програмним забезпеченням.

Поперечні платформи

Літак літає лише в земному небі. Я не впевнений у тому, як вони справляються з туманним чи вітряним чи жарким, холодним та вологим кліматом, але літак не розрахований на літати на різному рівні гравітації (я буду вражений, чи зможе він летіти на Марс ). Іноді програма повинна переживати різні платформи, такі як Internet Explorer, Google Chrome , Firefox та Safari для браузера (вибачте Opera ), або Windows XP / 7/8 або Linux для рівня ОС. Не кажучи вже про мобільні пристрої та різну роздільну здатність та орієнтацію.

Якщо ви думаєте, що інші галузі завершують проекти без інцидентів, вам слід прочитати історію про будівлю Центру Citigroup, побудовану в 1977 році. Навіть після майже 7 років планування та будівництва будівля була завершена серйозним недоліком дизайну, який би спричинив крах з боку штормова подія очікується кожні 16 років.

Іншими словами, щорічно Центр Citicorp стояв, існує ймовірність, що він "за 16 років" розпадеться.

Оригінальні дизайнери не були в курсі проблем, але, на щастя, його спіймав студент, що вивчає будівлю.

все здавалося прекрасним - доки, як розповідає Лемессьєр'є, він не зателефонував. За словами Лемессьєр'є, у 1978 році студент з архітектури магістратури зв'язався з ним сміливою заявою про будівлю ЛеМессур'є: що Центр Сітікорп міг би дути вітром.

Ремонт робився буквально в нічний прикриття, в якому беруть участь найменша кількість людей, щоб зберегти секретність вад дизайну.

План радіаційної евакуації був підготовлений за радіусом 10 блоків навколо будівлі.

Вони проварювали всю ніч і кидали в світанку, так само, як мешканці будівель поверталися до роботи.

Ця історія залишалася таємницею, поки письменник Джо Моргенстерн не почув, як її розповіли на вечірці, і не взяв інтерв'ю у Лемессьєр'є. Моргенштерн розбив цю історію в The New Yorker в 1995 році.

Що викликає питання; скільки інших фатальних недоліків у дизайні таємно було усунено або проігноровано без публічного визнання.

• Несправність дизайну, яка майже знищила хмарочос NYC (slate.com)
• Центр Citigroup (wikipedia.com)