Абсурдні закони світу програмного забезпечення

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

Моїм першим комп’ютером був Commodore 64. Майже 30 кб оперативної пам’яті було призначено для системи, залишаючи 32 кб для обробки текстів, ігор, бухгалтерського обліку сімейного бізнесу та майже всього, що я роблю з моїм комп’ютером на 6 Гб. Це залишає питання відкритим Чи відповідає сучасне обладнання потребам програмного забезпечення, чи програмне забезпечення використовує більше апаратних ресурсів, оскільки воно доступне?

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

Ось причини.

Закон Завінського

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

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

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

Принцип Пітера застосовувався до програмного забезпечення

Лоуренс Пітер прославився тим, що в ієрархії людина просувається до тієї посади, для якої вона абсолютно некомпетентна. Але він також встиг щось сказати про складні проекти:

"Складний проект стане занадто складним, щоб його зрозуміли навіть власні розробники".

Принцип найменшого здивування

Опублікований у IBM Systems Journal у 1984 році, цей принцип свідчить, що:

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

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

Шкода, що Шаттлворт не врахував цього, коли запустив Unity.

Закон про кібернетичну ентомологію

Перша помилка в історії комп’ютера була справжньою. Моль влетіла в одне з реле комп'ютера MARK II, спричинивши несправність.

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

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

Закон Кернігана

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

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

Звідси закон Кернігана стверджує, що:

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

Правило 90/90

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

Комп’ютерний світ має свої варіанти цього закону. Наприклад, один Том Каргілл сказав:

«Перші 90 відсотків коду представляють перші 90 відсотків часу розробки. Решта 10 відсотків коду представляють інші 90 відсотків часу розробки.

Чи не було ясно? Можливо, закон Гофштадтера допоможе:

"Це завжди займає більше часу, ніж ви очікуєте, навіть маючи на увазі закон Гофстадтера".

Я думаю, розробники Ubuntu та Fedora повинні це знати. Або принаймні пам’ятайте про це кожні 6 місяців.

Закон Брука

Програми з відкритим кодом часто мають дві проблеми; фінансування та відсутність співробітників. Хіба що друге не є проблемою. За словами Брука:

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

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

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