Эволюция разработки: 1623 — 2020

Я начал заниматься разработкой в 15 лет. В институте я делал сайтики на фрилансе, а после проработал в нескольких крупных IT-компаниях, но устав от бессмысленных процессов, построенных на эксплуатации рынка разработки, я открыл свою компанию, чтобы делать классные вещи.

— Классные вещи?

Для некоторых фанатиков IT сфера по определению создаёт классные вещи, но если задуматься, то всё с точностью наоборот — в большей степени IT решает свои проблемы и очень редко проблемы людей. В 2018 году было опубликовано исследование, согласно которому IT находится на первом месте по текучке кадров. И это выше, чем в ритейле! Навряд ли сфера с такой текучкой может создать много «классных вещей». Чтобы понять, к чему пришло IT, предлагаю окунуться в историю.

Эволюция ценностей в IT

1637. Рене Декарт заложил эпистемологические предпосылки для возможности создания компьютера и искусственного интеллекта. В своих трудах он представлял животное, как сложный механизм, который можно в некотором смысле скопировать.

1647. Блез Паскаль построил свою счётную машину со множеством шестерёнок, а Лейбниц примерно в это время описал двоичную систему исчисления, которая стала основой современного программирования. В этот период люди видели в таких машинах вычислительную ценность.

1832. Русский коллежский советник Семён Корсаков впервые выдвинул идею искусственного интеллекта, которая во многом перекликалась с идеями компьютерных алгоритмов в целом. Так идея компьютера и идея ИИ всегда шли вместе.

1842. Идея первой в мире программы принадлежит женщине-математику. Ада Лавлейс (опустим шутки про то, что разработка есть порождение Ада) в 1842 года написала первый в мире алгоритм для гипотетической вычислительной машины, разрабатываемой Чарльзом Бэббиджом. Она же впервые использовала термин «цикл» в своих трудах.

1936. Следующий шаг сделал более известный учёный, Алан Тьюринг, когда описал работу «Машины Тьюринга» и частично реализовал её концепцию в разработке железа того времени. На этом этапе люди видели в вычислительной мощности компьютера научную ценность, которая была призвана помочь в математических исследованиях.

1945. Этот год ознаменовался появлением первого компьютера. ЭНИАК был разработан для научных и военных целей, поэтому о его появлении узнали лишь в 1946, а проработал он до 1955. Одна из задач, которую решало это чудо техники: «Прогноз погоды в СССР для предсказания направления выпадения ядерных осадков на случай ядерной войны».

Источник.

В этот же период был впервые введён термин «нейронная сеть». Уоррен Маккалок и Уолтер Питтс опубликовали исследование под названием «Логическое исчисление идей, относящихся к нервной активности» (1943 год).

1960-е. После разработки фортрана (первого высокоуровневого языка) программное обеспечение стало развиваться гораздо быстрее, но его идея оставалась в рамках промышленных и государственных потребностей. Стали появляться первые аутсорсинговые компании и термин «программное обеспечение» плотно вошёл в обиход — все увидели в нём бизнес-ценность. В 1964 году в Business Week появилась статья, согласно которой на рынке наблюдается нехватка разработчиков😆

1970-е. Когда стали появляться первые персональные компьютеры и их можно было купить за более-менее приемлемую цену, за дело взялись гики. Такие компьютеры покупались ради одной-двух программ, наличие которых считалось достаточной мотивацией для приобретения. Первыми такими программами был текстовой редактор WordStar и финансовый калькулятор VisiCalc. Люди увидели в компьютерах повседневную ценность в решении их бытовых задач и рынок был открыт для массового потребителя. С ростом сложности программ в языках программирования появился термин структурное программирование — это второй шаг в создании современных языков.

1980–1990-е. Параллельно с железом, с 60-х годов развивалась концепция Интернета — его идея волновала умы учёных и военных. Но его истинная ценность обнаружилась в конце 80-х, когда Тимом Бернерсом-Ли был разработан протокол http и Интернет c 90-х стал активно распространяться по всему миру. Люди увидели коммуникативную ценность в программном обеспечении. С точки зрения разработки программы становились всё сложнее и потому инженеры всё чаще стали обращать внимания на ООП, принципы которого, однако, были придуманы ещё в 1967, но не были замечены. На фоне роста популярности ООП появились новые мощные языки программирования, которые остаются популярными до сих пор. Параллельно развивалось функциональное программирование, но оно так и не захватило рынок. Где-то в конце 90-х, в пору юной впечатлительности, я написал свою первую программу — классическую игру «виселицу» на Паскале.

2000-е. Наконец, начало века ознаменовалось появлением социальных сетей и ПО стало нести культурообразующую ценность. Люди стали самовыражаться благодаря Интернету. Для поддержания этой ценности стало активно популяризироваться слово «продуктовая разработка» — такой подход, при котором твоя программа сама по себе имеет ценность и бренд. Языки стали обрастать синтаксическим сахаром и фреймворками. Они начали работать на быструю поставку функционала, но основные принципы перестали меняться. Основной мотивацией при выборе технологий стало наличие на рынке разработчиков, а не уместность того или иного подхода. Стал популяризироваться термин «лучшие практики», согласно которому, если ты будешь знать «это, это и это», то ты точно продашь себя бизнесу.

2010-е. Повлияв на развитие всех отраслей в мире, IT стало обрастать мишурой в виде бесконечных JS-фреймворков, мифическими «лучшими практиками» и целым набором новых модных слов. У бизнесменов стала появляться паранойя, если они ещё не в IT. У сотрудников в других сферах появилась жуткая зависть к IT-деньгам. И все рванулись учить эти ваши языки программирования. Забавно, что содержательно в IT стало меняться очень мало, закон Мура перестал работать (по мнению самого Мура) и сами сервисы не стали работать быстрее. Переодическое появление «революционных подходов» стало делом повседневным и все занялись «вкусовщиной». IT стало самоценно.

Изначально IT развивалось под конкретные задачи, но испытав влияние массовой культуры, оно сильно испортилось (точно так же как кино, искусство, литература). Архитектурно красивое здание IT с ручной лепниной, которое мы хотели создать, превратилось в цыганский базар с причудливыми зеркальцами и дорогими побрякушками — потерялась задача, потому что в каждом IT-офисе вдруг захотели вкусный кофе, которое в свою очередь стимулировало очень много митингов и очень мало кода.

Кто платит за твой кофе

Основная проблема современного IT — все платят за хайп. От незнания или лени, но хайп живёт аж на четырёх уровнях:

Разработка🔨
Бизнес💶
Сотрудники👨‍🔧
Пользователь🧜‍♀️

🔨Лучшие практики — миф

С архитектурной точки зрения все решения имеют право на жизнь. Вопрос в том, насколько часто встречается контекст, в котором это решение будет лучшим. Однако люди с таким упорством используют хайповые технологии, что разработка превращается в один большой конвейер, за который отдельно взятый заказчик явно переплачивает. Я слышал историю, согласно которой девушка, которая три года работала с TS не смогла на собеседовании ответить, чем он отличается от JS.

В мире разработки слова постоянно искажаются и теряют свою строгость. Сейчас на рынке разработки придумали слово «инженер». Это новый способ сказать: «Сделайте мне хорошо». В следующим году это будет значить «ниндзя». Слова появляются, обесцениваются и заменяются, а по большому счету ничего не значат.

💶А давайте-ка поиграем за счёт клиента?

«Лучшие практики» влияют и на бизнес. В одной из компаний я видел показательный случай. Для заказчика делалось простое приложение на пару часов работы — одностраничная форма, которая после отправки генерировала PDF-документ. Но было одно НО — набирал популярность Реакт. Думаю вы уже поняли, к чему я веду. По итогу проект занял 300 с лишним часов. В этой истории я нахожусь по другую сторону баррикад, но мне не хочется тратить жизнь на бесполезные глупости.

Другую историю рассказывал мне друг. Шел 2010 год и популярность набирал Ruby. Команда разработчиков взялась за переработку проекта на Битрикс. Команда сказала: «Это прям вчерашний день, сейчас мы переделаем все на рельсах и будет современно». Как итог — команда проработала 2 года, потратила 15 миллионов рублей заказчика, а проект между тем был закончен лишь на 10%. И как изюминка на торте — все мы знаем, что стало с руби с тех пор.

👨‍🔧 Нет мотивации работать хорошо

Самое главное, о чём часто забывает бизнес — нельзя просто так наживаться на программистах. Ты работаешь, заказчик платит за тебя компании $35 в час и он смотрит на тебя как на человека, который должен нести ответственность на 35 долларов в час. Он же не знает, что из этих 35 долларов ты по факту видишь 5 — при этом ты пишешь код, общаешься с клиентом, принимаешь архитектурные решения. Компания в свою очередь не привносит никакой ценности в этот процесс.

В таких компаниях тебя постоянно пытаются продать, поэтому возникает и обратная проблема. Однажды была ситуация в одной компании — очень нужен был iOS-ник, проект горит. Взяли парня на 20% выше обычной ставки. За три месяца испытательного срока он может пять раз на работе появился. В итоге за три месяца он ничего не сделал, получил зарплату и ушёл.

В целом, проблема не в деньгах, а в желании продать тебя как разработчика и ограничить твою свободу делать хорошо корпоративным эгоизмом. Если сейлз продал тебя со словами «блокчейн», то делай блокчейн, даже если для клиента он вообще не нужен. При этом на рынке начинают цениться не твои навыки, а возможность тебя продать.

🧜‍♀️«Продукты»

Когда придумали ещё одно модное слово «продуктовая разработка», продукты от этого лучше не стали. Примеры на российском рынке: борьба пользователей и разработчиков «Кинопоиска». Или редизайн «Флампа» — когда из атмосферного лампового приложения сделали бездушное приложение, которое одинаково отображает свою бездушность на всех устройствах. Наконец возьмём hh.ru — невероятно избыточный сервис, который не решает никаких задач. Например, я людей уважаю и всегда предпочитаю личный контакт, но вместо возможности позвонить человеку (если он указал номер), тебя заставляют писать письмо по бездушному шаблону через их систему. Что меня реально расстраивает, так это раз в три месяца приходящее письмо: «Помогите нам сделать наш сервис лучше, нам очень важно ваше мнение» — кого вы обманываете? Я в этот момент сажусь, начинаю писать, потом понимаю: «Господи, что я делаю?».

Источник.

Смысл любой сферы измеряется не сложными словами, а конечными продуктами. Конечный — значит имеющий отношение к конечному потребителю (пользователю в нашем случае). Признаем тот факт, что большая часть IT всё так же далека от пользователей. Как я недавно слышал на одном выступлении: «О каком искусственном интеллекте мы можем говорить, когда я до сих пор не могу запустить скайп с первого раза».

Мой вывод простой: открыть свою компанию в современном IT и не продать совесть легче. В сущности, я вижу простые проблемы, которые в силах исправить, но сделать это в рамках существующих крупных компаний, которые были основаны в 2000-х на диком росте рынка, я не вижу возможности. Для себя я выработал ряд простейших правил, которые помогают не забыться в своём бизнесе.

  • Превосходить ожидания сотрудников (а не только клиентов) и давать ясную схему оплаты труда, повышения зарплаты и выплаты бонусов (у меня даже формула есть), а не обещать мифические плюшки.
  • Работать в узком стеке, в котором я точно разбираюсь и потому клиенту не придётся переплачивать за моё незнание. При этом ограничивать тот круг бизнес-задач, под которой подходит мой стек. Или в крайнем случае, работать с теми технологиями, которые легко освоит любой разработчик, тренируясь на внутренних проектах.
  • Максимально стандартизировать все рабочие процессы. Если чего-то нет в описанных процессах — мы думаем, как нам это лучше сделать и добавляем. Если мы ошиблись — меняем и пробуем снова! В целом процесс выглядит так: выяснение требований, составление описания, уточнения, составление глоссария на проект, проектирование структуры данных, планирование вех проекта, разработка. Отступления от процесса возможен только по объективным причинам. Высказывания в духе «мы не успеваем» как таковой причиной не являются, потому что если мы пропустим важный этап, работа от этого быстрее не пойдёт.
  • Единый стиль кода для всех проектов. Причем у заказчика могут быть свои требования к коду — тогда мы составляем отдельный документ со стилем под конкретный проект, потому что в бизнес-задачах частное важнее общего, тем они и ценны для заказчика.

🌲2020

Мне кажется, что в новом десятилетии IT стабилизируется — исчезнет мода на функциональный жир, так как пользователи уже сейчас пишут гневные отзывы на «оверфункциональные» приложения и тупую логику, бизнес постепенно отходит от IT-эйфории, а разработка наконец возвращается к истокам и понимает, что решения нужны для задач, а не для разработчиков. Надеюсь новое десятилетие будет более плодотворным для пользователей и более интересным для разработчиков. С Новым годом!