Що означає закон Джеймі Завінського?

Мені потрібно правильно пояснити Закон Джеймі Завінського про розробку програмного забезпечення :

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

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

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

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

Для прикладу є програма, над якою я працюю. Напевно, ви ніколи не чули про це, але ми лідер ринку в спеціалізованій галузі: контроль ЗМІ. Наша програма, швидше за все, керує вашою улюбленою телевізійною та / або радіостанцією. Клієнти люблять його, вони кажуть , що це так набагато краще , ніж все інше вони працювали с.

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

Ви повинні розуміти, що це сталося довгий час назад, і на той час ще не було основного напрямку, щоб комп'ютери могли запускати більше однієї програми одночасно для певного користувача. DOS для персональних комп’ютерів (можливо, Windows 3 зверху) та символьні термінали для користувачів Unix (лише деякі мали X11).

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

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

У наші дні це важко уявити, але ви можете зрозуміти, як це було, обмежившись одним вікном браузера - без вкладок, без додаткових вікон - і, можливо, навіть не використовувати закладки.

Як усі інші вже згадували, "закон" - це жартівливе спостереження за роздуттям програмного забезпечення та піднесенням балів , і він дуже схожий на десяте правило Грінспана :

Будь-яка достатньо складна програма C або Fortran містить спеціальну, неофіційну, неофіційну, помилку, повільну реалізацію половини Common Lisp.

Закон відображає роботу Zawinski з браузером Netscape, а згодом і з Netscape Mail & News, як описано тут , ну сам:

Далі я розробив, і ми з Террі Вайссманом реалізували клієнтів Netscape Mail та News, версії 2.0 та 3.0. Це був наш внесок у доказ цього Закону про розробку програмного забезпечення :

"Кожна програма намагається розширити, поки не зможе прочитати пошту. Ті програми, які не можуть так розширюватися, замінюються програмами, які можуть."

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

Дисфункція інтерфейсу користувача Mozilla

Оскільки більшу частину дизайну користувальницького інтерфейсу для продуктів Netscape було зроблено співробітниками Netscape, які працюють до вимог Netcenter, користувальницький інтерфейс Mozilla постраждав. Замість того, щоб бути чистим стрижнем, на якому Netscape міг побудувати продукт відповідно до його потреб, пакет Mozilla ніколи не відчував себе цілком правильним; це було багато незручних конструкцій інтерфейсу, які існували лише для заповнення накладками в сховищі приватного джерела Netscape - «комерційному дереві».

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

_{¹ З архівованої версії щоденного блогу Бена Гудгера.}

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

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

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

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

Також см Scope Creep .

Я бачу щонайменше три способи його перегляду.

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

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

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