Пол Грем: «The Other Road Ahead», частина 1

«Для Viaweb ми часто робили три-п'ять версій на день».
— Пол Грем, розробник, інвестор, есеїст.

Мені було цікаво познайомитися з прогнозом засновника впливового бізнес-інкубатора кремнієвої долини (Y combinator). Через 15 років з моменту публікації есе Пола Грема, завдяки компанії Edison і чудовим людям з Хабра, руки дійшли до перекладу. Для тих, кому цікаво, як відбувалося зародження нового продукту і як три програміста буцалися з гігантами індустрії, ласкаво просимо під кат.

image
Пол Грем, Роберт Морріс і Тревор Блеквел в 1995

Чергова глава книги «Хакери і художники» (яка вже майже повністю переведена на російську)

Інша дорога в майбутнє

Вересень 2001
Оригінал — The Other Road Ahead
(переклад плюс в карму knagaev)

(Ця стаття пояснює, чому багато З наступного покоління може бути реалізовано на серверній стороні, що це буде означати для програмістів, і чому цей новий вид буде гарною можливістю для стартапів. Джерелами статті були діалоги в BBN Labs.)

Влітку 1995-го я зі своїм другом Робертом Моррісом (Robert Morris) вирішили запустити стартап. PR-кампанія перед IPO Netscape тоді йшла повним ходом, і в пресі було багато розмов про електронну комерцію. На той момент в мережі вже було близько тридцяти реальних електронних магазинів, і всі вони були зроблені вручну. Якщо незабаром в мережі повинно було з'явитися безліч онлайн-магазинів, була потреба в ПО для їх розробки, і ми вирішили таке написати.

Спочатку, десь близько тижня ми думали, що це буде звичайна програма для ПК. Але потім у нас виникла ідея розробити додаток, яке буде виконуватися на нашому веб-сервері, з використанням браузера в ролі інтерфейсу. Ми спробували переписати додаток для роботи в Інтернеті, і стало зрозуміло, що це правильний напрямок. Якщо ми писали наше ПЗ для виконання на сервері, це було зручніше як для користувачів, так і для нас.

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

image

Коли ми починали розробку Viaweb, майже ніхто не розумів що ми маємо на увазі, коли говоримо, що буде працювати на сервері. Так було до тих пір, поки через рік не запустився Hotmail, і люди почали його використовувати. Тепер всі знають, що це розумний підхід. Тепер є назва для того, чим ми тоді були: провайдер додатків (Application Service Provider або ASP).

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

Новий пристрій?

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

Комп'ютери зараз на такому етапі розвитку. Для того, щоб користуватися персональним комп'ютером, ви змушені вивчити набагато більше, ніж взагалі хочете знати, що відбувається всередині нього. Однак комп'ютерами володіють більше половини домогосподарств у Штатах. Моя мама користується комп'ютером для листування по електронній пошті і ведення рахунків. Близько року тому вона була стривожена, коли отримала від Apple лист, в якому їй пропонували знижку при покупці нової версії операційної системи. Мабуть щось не в порядку, якщо шістдесятип'ятирічна жінка, яка хоче користуватися лише електронною поштою і рахунками, змушена думати про встановлення нових версій операційної системи. Звичайні користувачі не повинні навіть знати про термінах «операційна система», не кажучи вже про «драйвер пристрою» або «патч».

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

З веб-додатками більшість користувачів не будуть повинні думати про щось ще, крім самих додатків. Всі складні і мінливі складові будуть знаходитися десь на сервері і обслуговуватися спеціально навченими фахівцями. І більше того, вам взагалі може бути не потрібен комп'ютер, щоб користуватися додатком. Все, що вам потрібно, це щось з клавіатурою, екраном і веб-браузером. Можливо з бездротовим доступом в Інтернет. Можливо цим буде ваш мобільний телефон. Чим би це ні було, це буде побутовою технікою: буде коштувати близько $200, і будуть вибирати, виходячи з зовнішнього вигляду. Ви будете більше платити за доступ в Інтернет, ніж за обладнання, так само, як зараз це відбувається з телефонами [1].

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

Користь для користувачів

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

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

Поворотною точкою стали веб-додатки електронної пошти. Мільйони зрозуміли, що повинні мати доступ до пошти звідки завгодно. А якщо ви читаєте свою пошту, то чому б і не календар теж? Якщо ви обговорюєте з колегами документ, то чому б і не редагувати його? Чому взагалі ваші дані повинні бути прив'язані до певного комп'ютера?

Сама ідея «Вашого комп'ютера» зникає і замінюється «Вашими даними». У вас повинен бути доступ до своїх даних з будь-якого комп'ютера. Або навіть з будь-якого пристрою, і пристрій не обов'язково має бути комп'ютером.

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

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

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

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

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

З веб-додатками всі використовують одну і ту ж версію, і баги можуть виправлятися відразу після виявлення. Тому веб-додатки повинні мати значно меншу кількість помилок порівняно з додатками на ПК. Сумніваюся, що в Viaweb бувало більше, ніж десять багів одночасно. Це на кілька порядків краще, ніж у випадку додатків для ПК.

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

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

Ну і останнє, веб-додатки повинні бути менш уразливі для вірусів. Якщо на терміналі не запускається нічого, крім браузера менше шансів отримати вірус, і локальних даних, які можна пошкодити, теж немає. А програма, атакуюча самі сервери, виявить їх дуже добре захищеними [2].

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

Місто коду

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

У Viaweb програмний пакет складався з порівняно великих додатків, з якими безпосередньо працюють користувачі, з програм, які використовують ці програми, з програм, які постійно працюють на тлі для визначення проблем, з програм, які намагаються рестартовать те, що сбойнуло, з програм, які запускаються час від часу, щоб зібрати статистику або побудувати пошукові індекси, програм, які запускаються вручну для сміття, або для переміщення/відновлення даних з програм, які імітують користувачів (для вимірювання продуктивності або пошуку помилок), з програм для діагностики мережевих аварій, з програм, що виконують резервне копіювання, інтерфейсів до зовнішніх сервісів, програм, які керують вражаючою колекцією циферблатів, показують статистику сервера в реальному часі (необхідні не тільки користувачам, але і нам), зміни (у тому числі виправлення) у відкритому та з величезної кількості конфігураційних файлів і налаштувань. Після того, як ми були куплені Yahoo, Тревор Блекуэлл (Trevor Blackwell) написав ефектну програму для перенесення магазинів на нові сервери, розташовані в іншій точці країни, без їх вимкнення. Програми посилають нам пейджингові повідомлення, посилають факси і електронну пошту користувачам, збирають транзакції процесингу кредитних карт, і взаємодіють з іншими програмами через сокети, пайпи, http-запити, ssh, пакети udp, поділювану пам'ять і файли. Частина Viaweb навіть складається з «відсутності» програм, так як один з ключових принципів безпеки Unix — не дозволяти запускати зайвих утиліт, які можна використовувати для злому серверів.

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

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

Так як програмне забезпечення веб-додатках буде являти собою пакет програм, а не єдиний виконуваний файл, вони можуть бути написані на декількох мовах програмування. Коли ви пишете персональний софт, вас практично змушують писати на тій мові, на якому написана операційна система, тобто С або С++. Тому ці мови розглядаються (особливо нетехнічними співробітниками, наприклад, менеджерами або віце-президентами) як мови для «серйозної» розробки. Але це є просто стереотипом, що склався у сфері розробки персонального софту. Для додатків, які розміщуються на сервері, ви можете використовувати будь-яку мову який захочете.[3] Зараз багато програмісти вищого класу використовують мови, дуже далекі від С++: Perl, Python або навіть Lisp.

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

Більшість наших конкурентів використовують С і С++, що робить їх ПО помітно гірше, тому що (крім інших проблем) вони не можуть працювати з відсутністю стану CGI скриптів. Якщо ви збираєтеся щось змінити, всі зміни повинні відбуватися на одній сторінці з кнопкою «Змінити» нижче. Так як я використав Lisp, який багато як і раніше вважають мовою для досліджень, ми змогли зробити редактор Viaweb схожим на десктопное додаток.

Версії

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

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

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

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

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

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

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

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

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

До того часу коли нас купили, ми виконали це три рази, та були на 4 версії. Версії 4.1, якщо не підводить пам'ять. Після того, як Viaweb став Yahoo Store, гостра необхідність у популяризації відпала, і хоч система і продовжувала розвиватися, сама ідея з номерами версій було тихо похована.

Баги

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

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

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

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

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

Коли баги ловляться на ранніх етапах, ви отримуєте менше складових багів. Складові баги — це два окремих бага, які взаємодіють один з одним: ви спускаєтеся вниз по сходах, і коли ви чіпляєтеся за перила, то вони залишаються у вас в руці. В софті цей вид багів найважчий для виявлення, і крім того, має властивість приносити гірші наслідки. [5] Традиційний підхід «зламай все і баги отсеятся» сам по собі генерує безліч складових багів. Безперервний випуск дрібних версій не призводить до цього. Підлоги весь час чисто підметені від будь-яких втрачених дрібниць, які згодом можуть у чому-небудь застрягти.

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

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

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

Підтримка

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

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

Так що в Viaweb розробники завжди були в тісному контакті з підтримкою. Співробітники підтримки сиділи в десяти метрах від програмістів, і вони знали, що можуть у будь-який момент потурбувати повідомленням про новий ба. Ми могли перервати нараду ради директорів заради виправлення серйозної помилки.

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

Наша політика усунення помилок на льоту змінила відносини між співробітниками підтримки та висококласними програмістами. У більшості компаній В підтримці працюють низькооплачувані «вахтери», а програмісти — це маленькі копії Бога-Отця, творці Всесвіту. Яка б не була процедура повідомлення про помилки, вона, швидше за все, спрямована в один бік: співробітник підтримки, який отримав відомості про помилку, записує їх в яку-небудь форму і через деякий час пересилає (можливо через службу якості) програмістам, які ставлять їх у план роботи. Це було зовсім не так в Viaweb. Протягом хвилини після отримання повідомлення про помилку від користувача співробітник підтримки міг вже стояти поруч з програмістом і чути від нього «Чорт, ти правий, це баг». Співробітникові підтримки було дуже приємно почути «ти прав» від суперфахівця. Вони звикли приносити нам баги з тим же виразом обличчя, яке буває у кота, несе вам щойно вбиту миша. Це також робило їх більш обережними в оцінках важливості помилки, тому що їх реноме ставилося на карту.

Після того, як ми були куплені Yahoo, співробітники підтримки переїхали далеко від програмістів. Тільки тоді ми відчули що вони були фактично співробітниками служби якості і в деякій мірі маркетингу. Крім відлову багів вони були хранителями знань про неясних багоподобных штучках, які плутали користувачів. [6] Ще вони були в деякому роді фокус-групою представників користувачів; ми могли запитати яку з двох нових фіч користувачі хочуть більше, і вони завжди виявлялися праві.

Продовження слід.

[1] Розуміючи, що велика частка грошей у наданні послуг, компанії, що розробляють тонкі клієнти, зазвичай намагаються об'єднувати апаратні рішення з онлайн-рішеннями. Цей підхід не дуже хороший, частково із-за того, що вам потрібні дві різні фірми, одна з яких буде розробляти апаратну частину, а друга надавати онлайн-послуги, і частково тому, що користувачі ненавидять цю ідею. Продавати дешево бритви і потім заробляти на продажах лез може собі дозволити для гоління gilette, але бритва — це набагато менше вкладення, ніж веб-термінал. Компаніям, які продають мобільні телефони, вистачає виручки від продажу пристроїв, і вони не намагаються отримати весь дохід від телефонного зв'язку. Ймовірно це має бути моделлю для інтернет-пристроїв. Якщо хто-то просто продає красиву маленьку коробочку з веб-браузером, яку ви можете використовувати з будь-яким інтернет-провайдером, кожен обиватель купить собі таку.

[2] Безпека завжди боїться помилок, більше, ніж будь-які інші проектні рішення, але характер серверного ПО змушує розробників приділяти ще більше уваги захисту від злому. Компрометація сервера може завдати такий значний збиток, що провайдери програм (які не хочуть прогоріти) повинні подбати про безпеку.

[3] У 1995 році, коли ми починали Viaweb, Java-аплети розглядалися як технологія, яку всі будуть використовувати для розробки серверних додатків. Нам аплети здавалися застарілою ідеєю. Завантажувати для запуску програми на клієнта? Простіше дійти до логічного кінця і запускати програми на сервері. Ми витратили трохи часу на аплети, але зникаюче мало порівняно з іншими стартапами, яких заманили в цю смоляную яму. Мало хто зміг звідти вибратися живими, або Microsoft не змогла втекти, викинувши підтримку Java зі своїх останніх версій IE.

[4] Ця ідея від Тревора Блекуэлла (Trevor Blackwell), який додав «вартість створення ЗА зростає швидше, ніж його розмір. Можливо це головним чином з причини необхідності виправлення старих помилок, і зростання вартості буде ближче до лінійного, якщо всі баги будуть отыскиваться негайно.»

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

[6] У Viaweb одного разу ми влаштували змагання на опис гіршої проблеми у нашому софті. Два співробітника підтримки розіграли між собою перший приз, вказавши на такі речі, які я до сих пір згадую з жахом. Ми одразу ж усунули ці помилки.




Хакери і художники
image
Глави і переказиwww.paulgraham.com/hptoc.html
  1. Why Nerds Are Unpopular
    Their minds are not on the game.
    оригінал, переклад частина 1, частина 2
  2. Hackers and Painters
    Hackers are makers, like painters or architects or writers.
    оригінал, переклад частина 1, частина 2, альтернатива
  3. What You can't Say
    How to think heretical thoughts and what to do with them.
    оригінал, переклад
  4. Good Bad Attitude
    Like Americans, hackers win by breaking rules.
    оригінал, переклад
  5. The Other Road Ahead
    Web-based software offers the biggest opportunity since the arrival of the microcomputer.
    оригінал, переклад частина 1
  6. How to Make Wealth
    The best way to get rich is to create wealth. And startups are the best way to do that.
    оригінал, перевод
  7. Mind the Gap
    Could «unequal income distribution» be less of a problem than we think?
    оригінал, переклад
  8. A Plan for Spam
    Till most recently experts thought spam filtering wouldn't work. This proposal changed their minds.
    оригінал, переклад
  9. Taste for Makers
    How do you make great things?
    оригінал, переклад
  10. Programming Languages Explained
    What a programming language is and why they are a hot topic now.
  11. The Hundred-Year Language
    How will we program in a hundred years? Why not start now?
    оригінал, перевод
  12. б'ється серцем the Averages
    For web-based applications you can use whatever language you want. So can your competitors.
    оригінал, переклад
  13. Revenge of the Nerds
    In technology, «industry best practice» is a recipe for losing.
    оригінал, переклад 1, 2, 3
  14. The Dream Language
    A good programming language is one that lets hackers have their way with it.
    оригінал, переклад частина 1, частина 2
  15. Design and Research
    Research has to be original. Design has to be good.
    оригінал, переклад


Варто видати книгу Пола Грема «Хакери і художники» в професійному видавництві?

/>
/>


<input type=«radio» id=«vv73040»
class=«radio js-field-data»
name=«variant[]»
value=«73040» />
так
<input type=«radio» id=«vv73042»
class=«radio js-field-data»
name=«variant[]»
value=«73042» />
немає
<input type=«radio» id=«vv73044»
class=«radio js-field-data»
name=«variant[]»
value=«73044» />
інше

Проголосувало 26 осіб. Утрималося-2 людини.


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


Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.