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

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

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

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

Як мені впоратися з ситуацією?

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

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

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

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

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

Ось кілька фактів, які ви можете взяти з собою з цього питання.

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

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

Ви цього не робите.

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

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

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

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

Я б запропонував прочитати « Чистий кодер» від «дядька» Боб Мартіна. Написання хорошого коду є частиною вашої роботи. Ви не просите дозволу виконувати свою роботу, ви просто виконуєте це.

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

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

Удачі!

Представити діловий кейс

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

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

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

• Скільки часу в даний час розвиток витрачає на вирішення проблем, які це усуне або пом’якшить?
• Скільки скарг користувачів у вас пов’язані з проблемами, які це усуне або пом'якшить?
• Які ще переваги вона матиме?

Поставте числа і складіть це приблизне, але просте рівняння. Це обійдеться X, і це піде на користь компанії Y.

Примітка: Не дивуйтеся, якщо реалізувати академічно хорошу ідею надзвичайно дорого.

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

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

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

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

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

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

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

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

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

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

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

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

Але неодмінно дотримуйтесь чудових порад щодо покращення речей.

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

Генеральний директор (який практично має Mohawk) любить PHB, тому що PHB забезпечує функції . Кожен спринт, який він з гордістю демонструє новий прапорець (злегка нерівне, з неоднозначною міткою), блискучий значок (ще не працює в будь-якому середовищі, але 8-бітний колір над Citrix) та форму (що має випадкові збої через умови перегонів у варіанті C на замовлення xml на базі C впроваджена локальна база даних, яку ніхто з команди розробників не наважується торкатися, тому що вона була написана однією зі старовинних легенд Dev Guard 10 років тому і робить ВСЕ з макросами з 5 іменами літер, чи потрібно 5 букв або ні).

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

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

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

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

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

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

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

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

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

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

Як ви вирішуєте це питання? Ви досить добре спілкуєтесь і розумієте один одного з ряду питань. Саме на цьому буде зосереджено увагу на залученні та задоволенні клієнтів.

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

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

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

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

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

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

Ви повинні продати ці зміни єдиним способом, який бажає купити керівництво:

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

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

1. Скільки часу потрібно для доставки за запитом клієнта?
2. Ви доставляєте, коли скажете, що хочете?

Більшість, скоріше, ви скажете, що це займе 6 тижнів, а доставка за 5, ніж скажете, що ви доставите через 3, але візьміть 4.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Одне, що можна спробувати, - це скласти задокументований план. Перевірте, чи можете ви прив'язати його до випусків або вийти з критеріїв для нових функціональних можливостей. Прохання "витратити деякий час на перерахунок довідок" може бути важким для вашого начальника, щоб схвалити, але планувати 5-денний блок часу через 4 тижні може бути простіше. В основному, однак ви бачите, що нові функції заплановані та заплановані, спробуйте імітувати це, або введіть у нього частину "під капотом".

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

Удачі!

Ось чому ваш запит на автоматичний підрахунок посилань відхиляється:

1. Це не поліпшення . Як тільки у вас є щось більше, ніж привіт, світ, будь-яка зміна піде в неправильний бік. Жодна кількість рефакторингу не змінить того факту, що якщо вам потрібно буде внести зміни, це завжди піде в неправильному напрямку. Хитрість полягає в тому, щоб знати, коли ваші зміни є досить вагомими, що все ж варто ризикувати причиною нових проблем. Ваше керівництво чітко сказало, що якщо кінцеві користувачі цього не бачать, ризикувати не варто.
2. Підрахунок довідок - абсолютно божевільна особливість. Ви побачили, як якась велика відома компанія реалізує якусь функцію, і відразу подумала, що вам потрібна та сама функція. Що ж, дуже ймовірно, що ваша кодова база зовсім інша, ніж яблуко. Можливо, підрахунок посилань не спрацює, або це просто марна трата часу. Ви повинні знайти інший спосіб, який не вимагає поширювати примітивні підрахунки для підрахунку посилань скрізь у коді. Можливо, ваш план перерахунку коштів потребує тисячі змін у кодовій базі, більшість із цих змін не потрібні. Просто витрата часу і грошей.
3. Ви вирішуєте неправильну проблему. Керівництво зазвичай знає, які проблеми є в системі. Якась невідповідна проблема витоку пам'яті, яку вирішує рішення про перерахунок, не є однією з них. Зосередьтеся на реальних проблемах, а не на деяких уявних проблемах із тим, як комп'ютери обробляють пам'ять.
4. Для його впровадження потрібен занадто довгий час, Apple трохи більша компанія, ніж ваша незначна команда з кількома програмістами та деякими менеджерами. Вони можуть зробити великі зміни, просто заплативши ціну. Якщо на реалізацію чогось потрібно кілька мільйонів, це арахіс. Якщо маленькі компанії намагаються зробити те саме, у них швидко закінчуються гроші. Розробка програмного забезпечення вже дуже дорога; додавання зайвих витрат не допоможе ні на один біт. Одна невідповідна особливість, як управління пам’яттю, має намір відкрити шлюзи: після їх затвердження половина ваших програмістів хочуть здійснити власне «покращення». Це непересічна історія, і компанія може зробити щось корисне натомість.

Ось декілька кроків, які ви можете використовувати для вирішення проблеми:

1. Видаліть функцію
2. З’ясуйте, яка реальна проблема
3. Почніть робити щось корисне
4. Уважно сплануйте, як ви використовуєте свій час
5. Дізнайтеся, як ваші поліпшення приносять гроші
6. Вибирайте лише ті функції, які приносять більшу кількість грошей
7. Зрозумійте, що аспект програмування розробки програмного забезпечення є лише невеликою частиною всієї системи - вдосконалення її ніколи не будуть варті часу