Ведь может же случиться так, что современный мир давно уже созрел для того, чтобы программисты, заполоняющие большие организации, вышли на свободу и начали работать на себя самих – решая проблемы пользователей, а не своих коллег и менеджеров.
Стагнация и борьба с ветряными мельницами
По своей натуре я всегда любил и умел решать проблемы. Не просто решать, как мистер Вульф из Криминального Чтива, а видеть, откуда растут ноги проблемы, и решать ее так, чтобы она не вернулась снова. В этом, по сути, и есть задача архитектора – решить не проблему, а класс проблем, которые внедряет данное архитектурное решение. Причем, решить так, чтобы не внедрялись новые проблемы, а если и внедрялись, то такие, которые не проявляют себя в том сценарии использования, на который рассчитана система.
В рамках анализа проблем, возникающих большой организации, я заметил, что в среднем разработчик тратит только 2-10% своего времени на решение пользовательской задачи, остальное же время он тратит на решение внедренных им самим или другими разработчиками проблем, которые пользователю даже объяснить невозможно. Например, не понимая интерфейс унаследованного кода (потому что кто-то спроектировал его кривым, решая свою локальную проблему, не думая о будущих клиентах), разработчик пишет обертку, которая делает поведение системы еще более непонятным, замедляет сборку, увеличивает кодовую базу для будущих читателей. Затем, борясь с замедленной сборкой, вместо того чтобы попыхтеть и выкинуть лишний код, задавшись вопросом «откуда, блин, столько кода?», пишется система быстрой сборки, отслеживающая измененные файлы и обеспечивающая маппинг на те модули, которые надо пересобрать. В этом организационном болоте, разработчики уходят в некое состояние вещи в себе, решая проблемы не бизнеса, не технологии, а сложности, специфичной для самой организации – т.е. некий опыт, который не пригодится нигде, кроме как в этой организации.
Тем временем, мир идет вперед, появляются новые технологии, задачи и возможности. Работая в большой организации, очень сложно идти в ногу с миром, потому что большие организации любят отстраняться от сторонних зависимостей, потому что vendor lock-in – это антипаттерн, да и юристы не дремлют. В итоге, работая в большой организации, ты решаешь проблемы, внедренные группой из 20-30 людей для них же самих вместо того, чтобы решать проблемы, решением которых могут воспользоваться миллионы.
Я вдруг обнаружил, что отстал от мира. Что не умею писать под iOS и Android, зато знаю, в каком именно из 20 врапперов надо закэшировать прогресс бэкапа. Так не должно быть.
В рамках анализа проблем, возникающих большой организации, я заметил, что в среднем разработчик тратит только 2-10% своего времени на решение пользовательской задачи, остальное же время он тратит на решение внедренных им самим или другими разработчиками проблем, которые пользователю даже объяснить невозможно. Например, не понимая интерфейс унаследованного кода (потому что кто-то спроектировал его кривым, решая свою локальную проблему, не думая о будущих клиентах), разработчик пишет обертку, которая делает поведение системы еще более непонятным, замедляет сборку, увеличивает кодовую базу для будущих читателей. Затем, борясь с замедленной сборкой, вместо того чтобы попыхтеть и выкинуть лишний код, задавшись вопросом «откуда, блин, столько кода?», пишется система быстрой сборки, отслеживающая измененные файлы и обеспечивающая маппинг на те модули, которые надо пересобрать. В этом организационном болоте, разработчики уходят в некое состояние вещи в себе, решая проблемы не бизнеса, не технологии, а сложности, специфичной для самой организации – т.е. некий опыт, который не пригодится нигде, кроме как в этой организации.
Тем временем, мир идет вперед, появляются новые технологии, задачи и возможности. Работая в большой организации, очень сложно идти в ногу с миром, потому что большие организации любят отстраняться от сторонних зависимостей, потому что vendor lock-in – это антипаттерн, да и юристы не дремлют. В итоге, работая в большой организации, ты решаешь проблемы, внедренные группой из 20-30 людей для них же самих вместо того, чтобы решать проблемы, решением которых могут воспользоваться миллионы.
Я вдруг обнаружил, что отстал от мира. Что не умею писать под iOS и Android, зато знаю, в каком именно из 20 врапперов надо закэшировать прогресс бэкапа. Так не должно быть.
Преимущества веб-приложения над десктопным софтом
Если уйти от того, чтобы
- Клиенты мучились с установкой софта на конюшню версий виндов и линуксов, и вместо этого отдавали свои данные на обработку веб-серверу, которой развернут на вашем собственном стократно протестированном окружении
- Вам приходилось поднимать собственный дата-центр с вашей серверной инфраструктурой, и вместо этого вы арендовали нужную вам инфраструктуру в облаке
- Вам приходилось искать клиентов, уговаривая их купить ваш сервис, и вместо этого они сами находили вас и рекламировали ваш полезный сайт и сервис
- Вам приходилось производить тонны товаров, перевозить и хранить их, и вместо этого вы получали деньги за вычисления
то что мешает вам в одиночку создать успешную компанию? Зачем вам куча людей, которых надо уговаривать, которым надо объяснять и следить, что они поняли вас правильно? Один грамотно настроенный мозг может за пару секунд провести brainstorming, на который два мозга, обменивающиеся словами – средством заведомо сериализованным и медленным, потеряют пару дней. Зачем нужно много программистов, когда столько всего уже понаписано по всему миру? Чем больше людей вы наберете, чем больше велосипедов они вам напишут. Ограничивая себя в количестве рук, понимаешь истинное очарование повторного использования. Повторного использования, не как акта вежливости к коллеге, а как средство выживания бизнеса.
Специальности
- Ведущий разработчик
- Главный архитектор
Книги
- Hackers & Painters Пол Грэм
- Черный Лебедь Нассим Талеб
