Taming Silicon Valley: How We Can Ensure That AI Works for Us (Большой обман больших языковых моделей)

Прочитал на днях эту книгу Гэри Маркуса, изданную в MIT Press в сентябре 2024 года, то есть буквально на днях:) Книга представляет собой критическое исследование социальных и этических вызовов, связанных с искусственным интеллектом (ИИ), и его развитием под контролем крупных технологических компаний. Сам Гэри - это американский психолог, когнитивист, писатель и предприниматель, известный своими исследованиями на пересечении когнитивной психологии, нейронауки и искусственного интеллекта (ИИ). Он является профессором-эмеритом кафедры психологии и нейронауки Нью-Йоркского университета и основателем компании Geometric Intelligence, которая была приобретена Uber в 2016 году.

Ключевые идеи книги примерно такие
1) У AI есть две медали - с одной стороны он может привести к революции в естественных науках, технологиях, медицине и так далее. А с другой стороны он несет с собой значительные риски, например, распространение дезинформации, киберпреступности, подрыв демократии, а также экзистенциальная угроза всему человечеству
2) Критика крупных технологических компаний. В книге утверждается, что основные технологические компании ставят прибыль выше этических соображений, выпуская системы ИИ преждевременно в гонке за рыночным доминированием. Это приводит к созданию ненадежных технологий с внутренними недостатками, которые усугубляют общественные риски. Маркус критикует культуру Кремниевой долины, ориентированную на быструю прибыль, часто игнорирующую долгосрочные последствия ради краткосрочной выгоды. Интересно, что эта критика даже вынесена в название книги
3) Пробелы в регулировании. Маркус рассказывает о том, как крупные технологические компании эффективно «захватили» политиков через лоббизм, маркетинг и обещания саморегулирования, что привело к слабым или отсутствующим механизмам управления ИИ. Он подчеркивает необходимость создания надежного регулирования для решения таких вопросов, как конфиденциальность данных, дезинформация и вытеснение рабочих мест.
4) Гэри предлагает следующий план действий
- Установление сильных прав на данные.
- Введение многоуровневого надзора за системами ИИ.
- Проведение значимых налоговых реформ для крупных технологических компаний.
- Продвижение прозрачности и ответственности в разработке ИИ.
- Приведение ИИ в соответствие с правами человека и этическими принципами.
Также он выступает за общественное давление для стимулирования регуляторных действий, утверждая, что граждане должны требовать ответственности как от правительств, так и от корпораций.
5) Моральный упадок Кремниевой долины. Маркус исследует «моральное падение» Кремниевой долины, прослеживая её переход от целей инноваций к эксплуататорским практикам, направленным на извлечение ценности за счет общественного благополучия.
Укрепление позиций граждан:
6) Книга является призывом к действию для обычных граждан: лучше понимать технологии ИИ и выступать за их этичное использование.

На самом деле Маркус написал эту книгу с чувством срочности из-за быстрого внедрения технологий генеративного ИИ и их последствий для демократии и общества перед важными политическими событиями, такими как выборы. И в целом книга "Укрощение Кремниевой долины" служит одновременно критикой современных практик в области ИИ и манифестом о необходимости создания этической структуры для того, чтобы ИИ приносил пользу человечеству вместо эксплуатации общества.

#Management #Strategy #Leadership #Vision #Bigtech #AI #ML

A Tool for Process Merging in Business-Driven Development (Рубрика #Architecture)

Пока искал материалы для книги по архитектуре наткнулся на артефакты из прошлого в виде подхода "Business-driven development", который 20 лет назад промотировал IBM:) Сейчас оригинальная статья на сайте IBM про business-driven development не доступна, но вот статья про инструменты все еще с нами. По-факту, BDD — это методология разработки IT-решений, которая напрямую связывает бизнес-потребности с IT-реализациями, в которой выделялись этапы вида
1) Моделирование: Определение целей бизнеса и построение моделей бизнес-процессов.
2) Разработка: Преобразование моделей в IT-реализации. В те времена реализация предполагала использование языка BPEL (Business Process Execution Language), который позволял устроить оркестрацию бизнес-процессов поверх сервисов из SOA (service-oriented architecture). Сейчас SOA ушла в прошлое и мы часто видим использование BPMN (Business Process Model and Notation) движков типа Camunda примерно для такой же окрестрации, но теперь микросервисов:)
3) Внедрение: Интеграция решений в инфраструктуру и мониторинг их эффективности.

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

Авторы предлагали делать 2 модели реальности:
- Аналитическую модель, что концентрируется на том, что делают процессы и используется бизнес-аналитиками
- Дизайн модель, что отвечает за IT-реализацию, включая потоки данных, логику решений и специфику имплементации

В общем, это была попытка от бизнес-процессов прыгнуть к реализации поверх сервисов через генерацию BPEL кода, но последняя версия BPEL вышла в 2007 году, то есть подход оказался нерабочим, так как остались незакрытыми вопросы, подсвеченные открытыми внутри самой статьи
- Поддержание согласованности между бизнес-моделями и кодом (round-tripping)
- Определение оптимальной детализации сервисов
- Обеспечение качества моделей (выявление ошибок проектирования)
- Улучшение визуализации больших моделей и поиск в их коллекциях

Хотя авторы предсказывали, что дальше модель станет кодом, где графические и текстовые элементы будут объединены в единую систему, а переходы между уровнями абстракции поддерживаются методами обеспечения качества.

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

P.S.
Примерно в эти года я защищал магистерский диплом на тему реинжиниринга бизнес-процессов и автоматизации деятельности retail компании, поэтому отлично помню большое количество вариантов моделирования бизнес-процессов и их автоматизации:)

#Management #Architecture #ArchBook #Retrospective #History #Processes #Software

SolarBalls (Шаранутый космос) (Рубрика #ForKids)

На этих каникулах детишки включили первую серию нового сериала с какими-то шариками и я залип вместе с ними. Оказалось, что это сериал про звезды и астрономию, гда главная роль у астрочела (космонавта), а планеты умеют говорить:) В первой серии меня подкупило изложение теории большого взрыва, а в следующих сериях уже был рассказ про образование планет и появление жизни. Если говорить подробнее, то вот как это обыграно

1) Теория Большого взрыва
Вселенная началась с сингулярного состояния — бесконечно плотной и горячей точки, которая около 13,8 миллиарда лет назад начала расширяться. Это событие не было "взрывом" в привычном смысле, а представляло собой расширение пространства. В мультсериале этот процесс объясняется через разговоры между персонажами-планетами, которые обсуждают "появление всего". Например, они шутят о том, как всё началось с "маленького пузырька", который раздувался (аллюзия на инфляционную модель. Также упоминается реликтовое излучение — "эхо" Большого взрыва, которое подтверждает эту теорию. Оно представлено как "фоновая музыка", оставшаяся от ранней Вселенной. Интересно, что за его открытие когда-то даже дали Ноебелвскую премию.
2) Образование звёзд и планет
Звёзды формируются из облаков газа и пыли под действием гравитации. В мультсериале это показано как "танец" частиц, которые притягиваются друг к другу, пока не зажигается звезда. Планеты образуются из протопланетного диска вокруг молодых звёзд. В одной из серий персонажи обсуждают, как "космическая пыль и газ начали сплющиваться", создавая планеты. Это сопровождается шутками о том, что они "родились из космического беспорядка". Звёзды также играют ключевую роль в создании элементов. Например, лёгкие элементы (водород и гелий) появились после Большого взрыва, а более тяжёлые синтезировались в недрах звёзд или при их взрывах (сверхновых).
3) Появление жизни
Жизнь на Земле рассматривается как уникальное явление благодаря её местоположению в зоне обитаемости ("золотой середине"), где температура позволяет существовать жидкой воде. В одной из серий персонажи обсуждают возможность появления жизни на других планетах. Например, Венера мечтает о том, чтобы поддерживать жизнь, но другие планеты объясняют ей, что её экстремальные условия (высокая температура и давление) делают это невозможным. Также поднимается вопрос панспермии — гипотезы о том, что жизнь могла быть занесена на Землю с астероидов или комет.

Прикольно, что в мульике наука смешивается с юмором, например:
- Планеты спорят о своих орбитах и размерах, что иллюстрирует стабильность Солнечной системы.
- Звёзды шутят о своей яркости и важности для жизни.
- и так далее

В общем, я очень рекомендую этот сериал к просмотру:)

#PopularScience #Physics #ForKids #Humor

Developer Productivity for Humans, Part 6: Measuring Flow, Focus, and Friction for Developers - Part I (Рубрика #Management)

Недавно я с большим интересом прочел статью от ребят из Google на тему состояния потока, фокусной работы и friction, что мешает работать эффективно. Эта статья из колонки про "Developer Productivity" в журнале IEEE. В этой статье авторы описываются свой подход примерно так:
1) Авторы хотели сфокусироваться на восприятии инженеров двух концепций: flow и friction
2) Для этого они собрали данные напрямую от разработчиков, включая проведение интервью, опросов, ведения разработчиками дневников
3) Дальше они взяли эти данные и попробовали связать восприятие инженеров с данными из логов - другие исследователи обычно сразу начинали с этого этапа
4) У исследователей получилось создать эвристики для трансформации сигналов из логов в метрики, что значимо связаны с flow, focus и friction
5) Дальше авторы отвалидировали эти метрики относительно само-отчетов инженеров и данных из логов - это позоволило верефицировать, что метрики все еще связаны с тем опытом инженеров, что был интересен исследователям.

Ну а теперь немного подробностей:
1) Обычные исследования flow предполагали, что context switches между инструментами рушит этот flow. Авторы же пошли от целей инженеров и показали, что flow сохраняется, если контекст задачи сохраняется. Подробнее про статью "Measuring Developer Goals" я рассказывал раньше
2) Из diary studies и follow-up interviews стало ясно, что flow многограннее, чем думали авторы
- Инженеры испытывают состояние потока, только если они позитивно настроены относительно работы, что они выполняют
- Это может быть не только код, но и другие активности (написание дизайн доков, изучение документации, написание писем/сообщений, ...)
- Когда состояние потока достигнуто, то инженеры могут оставаться в нем даже при небольших отвлекающих факторах
3) Дальше авторы рассказывают, что они не смогли выделить как определить из логов состояние потока, но можно выделить состояние сфокусированной работы. Для этого надо посмотреть занимаются ли инженеры связными задачами (фокус) или несвязными (расфокус).
4) Концептуальная модель выглядела примерно так: сфокусированная работа нужна для достижения flow, но ее не достаточно. Одновременно из логов можно вытащить focus time, когда инженеры работали над связными задачами, но не факт, что это точно отображается на сфокусированную работу. Для анализа связности задач ребята использовали word2vec по данным из логов
5) Дальше шла валидация того, что инженеры заполняли в опросах или в diary data с тем, что насчитали авторы насчет flow и focus из логов. В итоге, метрики авторов показали хорошую связь между восприятием и этими метриками

Рассказ про метрику friction в продолжении этого обзора.

#Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes

39 лет (Рубрика #Retrospective)

Сегодня мне исполнилось 39 лет:) Кажется, что это достаточно много, но мне до сих пор кажется, что я только начинаю знакомиться с окружающим миром:) И в этом мне помогает моя семья:
- Жена в прошедшем году изучала психоаналитическое бизнес-консультирование и местами мне казалось, что и я тоже. Она успешно закончила первый курс магистратуры и начала делать дипломную работу про профессиональную идентификацию продакт менеджеров:)
- Старший сын стал первокурсником, поступив на геймдизайн. Я начал читать больше книг по геймдизайну, чтобы быть способным поддерживать непринужденную беседу
- Средний сын заинтересовался футболом, хокеем и баскетболом. Теперь я хожу с ним на стадион и смотрю матчи футбольного и хоккейного ЦСКА, а на баскетбольный ЦСКА мы пойдем через 2 недели:)
- Младший сын научился считать и складывать в четыре года - он вообще быстро учится, поэтому я ему рассказываю научно-популярные истории о мире вокруг нас.
- Еще у нас в семье есть собака и кошка, причем кошка появилась относительно недавно. Теперь я понимаю фразу "живут как кошка с собакой" гораздо лучше:)

Если говорить про работу, то впечатления смешанные
- Моя команда радовала меня своими успехами - ребята действительно хорошо поработали и достигли крутых результатов, я писал об этом в посте про свой юбилей "0b1000 в Т-Банке"
- На уровне всей компании часть моих инициатив зашла не так хорошо, как хотелось бы мне. Мне кажется, что иногда мое особое мнение об идеальном результате мешает достигать just enough результатов:)

Если говорить про творческую часть, то за прошедший год я
- Прочитал порядка 100 книг
- Написал кучу постов на разные ITшные темы (здесь и на Medium)
- Снял порядка 60 часов видео с крутыми гостями
- Прошел курс МИФа для начинающих писателей
- Определился с четырьмя темами книг и нашел для каждой из них соавтора - осталось их только дописать:)

В общем, до 40 надо много успеть сделать, поэтому я не планирую снижать обороты.

#SelfDevelopment

Developer Productivity for Humans, Part 6: Measuring Flow, Focus, and Friction for Developers - Part II (Рубрика #Management)

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

1) Они решили опять начать отстраивать friction от восприятия инженеров, а не от данных из инструментов типа билдов, автотестов и иже с ним. В итоге, авторы построили метрику, используя
- Некоторое число компонентов, что включают ключевые активности инженеров
- Агрегировали эти компоненты по инженерам и вычислили среднее для каждого инженера
- Дальше для каждого из инженеров сравнили получившееся среднее с некоторым пороговым значением, рассчитанным в разрезе восприятия инженеров, а не просто условный 90 перцентиль
- Если пороговое значение было пробито, то считалось, что инженер испытывал friction в этот день
2) Раньше в Google уже были метрики friction, но они создавались для целей того, чтобы продемонстрировать помощь инфры или инструментов в деле снижения friction или для понимания того, а что мешает инженерам работать продуктивнее. Этим метрики отталкивались от количества или процента "плохих событий" относительно их большого количества, например, flaky tests в Google. Эти метрики имели смысл в сценариях инфра команд, но не очень матчились на опыт конкретных разработчиков.
3) Но оказалось, что если считать friction исходя из опыта разработчиков, то получаются все те же причины: test latency, flaky tests, issues with code changes being blocked due to CI failures. Это показывает, что старые метрики совпадали с новыми, но новый подход дал больше уверенности, что это отражает мнение самих разработчиков о том, что мешает им в работе.
4) Интересно, что разработчики отмечали, что до некоторой степени эти проблемы не являются причиной friction, а являются частью работы. Но при превышении некоторого порогового значения, например, flaky tests это становится проблемой и они классифицируют это как friction.
5) В итоге, метрикой friction стало
- Данные из логов о latencies для локальных билдов и тестов, latencies для change lists, проблемы с нестабильными тестами, проблемы с заблокированными submission attempts. Тут тоже пришлось поиграть с пороговыми значениями
- Данные из ежеквартальных опросов о том, испытывали ли они friction и насколько они удовлетворены со сложностью кода и скоростью разработки

В итоге, подход ребят позволяет создать базу для ответов на вопросы вида
- Можно ли улучшить focus и flow при уменьшении общекорпоративных встреч?
- Можно ли улучшить focus и flow делая дни или целые недели без встреч?
- Можно ли при помощи уменьшения длительности и слотов под сфокусированную работу добиться лучшего focus и flow?
- Как можно при помощи метрики friction определить какие процессы улучшать первыми?
- И так далее

Но сами исследователи пока в начале пути. Надеюсь, что они поделятся с нами результатами следующих шагов в очередных whitepapers.

#Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes

Стажировки в Т-Банк - Тинькофф Старт (Рубрика #HR)

Открылась очередная зимняя программа стажировок в Т-Банк. Набор идет по куче направлений, в software engineering это направления вида java, scala, go, python, iOS, Android, .net, а также SRE, ML, frontend:) Стажировки у нас оплачиваются и во время них вы будете работать над реальными задачами, у вас будет ментор, который поможет вам адаптироваться, а по итогам лучшие стажеры будут приглашены в штат компании. Стажироваться можно в рамках гибкого графика - от 20 часов в неделю, удаленно или в офисе, в России или в соседних странах (Беларусь, Казахстан).

Для попадания на стажировку надо будет
- Подать заявку и зарегестрироваться в личном кабинете нашей edu платформы
- Заполнить анкету об опыте и мотивации, а также пройти экзамен
- Пройти интервью с командами
Если все пройдет успешно, то дальше останется только проявить себя во время стажировки, чтобы по ее окончании получить штатуную позицию.

#Career #Software #Engineering

The elearning designer's handbook (E-learning. Пошаговое руководство по разработке электронного обучения) (Рубрика #Education)

Эта книга Тима Слейда попалась мне на глаза случайно и хотя она рассказывает про создание онлайн курсов, но мне это показалось отчасти близким к написанию книги:) По-итогу, я прочел книгу за пару часов в силу ее небольших размеров и общей очевидности идей. Если рассказывать про книгу кратко, то она состоит из предисловия, вступления, пяти основных шагов и финального напутствия о том, что надо продолжать двигаться дальше.
1) Предисловие - здесь автор рассказывает про свой путь к педагогическому дизайнеру электронного обучения (я даже не знал, что это так называется до того, как прочел книгу). Тим изначально был subject matter expert много лет, а потом его попросили сделать курс для обучения других и ... так его карьера сделала поворот к созданию курсов
2) Вступление - здесь автор на пальцах показывает, что создание курса похоже на строительство дома. Он объясняет, что нужно понимание кто такие бизнес-заказчики, кто такие subject matter experts и зачем нужен план (чтобы дом достроился и был сдан, а не остался брошенным недостроем)
3) Шаг первый - создание плана проекта. По-факту, если вы знаете про проектное управление и руководили проектами, то тут вы не узнаете почти ничего нового. Автор рассказывает про то, что надо определиться со scope проекта, участниками, их зоной ответственнсти (лучше по матрице RACI, но он про это не говорит). Важно построить график проекта и отметить ключевые точки и контролировать их прохождение и так далее
4) Шаг второй - составление раскадровки курса. В этой части автор говорит о том, что лучше не делать курс целиком, а пользоваться методом прогрессивного JPEG, когда содержимое курса сначала набрасывается в черновом верхнеуровневом варианте, а дальше показывается стейкхолдерам. Это позволяет на начальном этапе провалидировать концепцию курса и получить ценную обратную связь. Этот этап позволяет задать канву курса и зафиксировать примерно материалы, что войдут в него.
5) Шаг третий - разработка курса. На этом шаге надо пойти и сделать сами материалы. Когда есть понятная канва и структура, то это должно быть не таким сложным делом. Главное сломать страх чистового листа и начинать работать над деталями курса по частям.
6) Шаг четвертый - проверка и контроль качества курса. Здесь автор рассказывает про базовые вопросы тестирования самого продукта, потом выкатку на бета-тестеров, а также проверку удобства получившегося продукта с точки зрения user experience через интервью с бета-тестерами
7) Шаг пятый - запуск курса. Автор говорит о том, что иногда курсы могут публиковаться в LMS системах, а иногда это просто html странички в интернете. В любом случае автору курса надо понимать на какой платформе он публикует курс, как он сможет его дорабатывать, а также где сможет посмотреть аналитику по прохождению курса учениками.

В общем и целом, это очень базовая книга по созданию электронных курсов, у которой на английском вышло второе издание аж в 2020 году, а та версия, которую читал я, была издана на языке Шекспира в далеком 2018 году. Кажется, что с тех пор эта информация про создание курсов стала просто базой:)

P.S.
Кстати, у автора есть свой сайт TimSlade.com

#Education #Writing

Code of Leadership #27 - Интервью с Виктором Фирсовым про эволюцию развития веба Т-Банка за 12 лет (Рубрика #Management)

В этом выпуске подкаста ко мне пришел Виктор Фирсов для того, чтобы обсудить как эволюционировали веб-интерфейсы Т-Банка и как он всеми силами помогал этому. Сейчас Виктор является техническом руководителем 100+ инженеров, что отвечают за публичный веб и личные кабинеты физических лиц. А начинал Витя с позиции инженера и занимался формами для привлечения клиентов. Эпизод доступен в Youtube, Podster, Yandex Music.

На общение мы потратили чуть больше часа и успели обсудить следующие темы
- Где Витя родился, учился и как попал в IT
- Как он переехал из Нижнего Новгорода в Москву, приняв офер Т-Банка 12 лет назад
- Как прошла технологическая трансформация при переходе со старого решения на react
- Как команда росла и пришлось делать организационные изменения
- Как выглядели вызовы в 2022-2023 годах и как их удалось с успехом преодолеть
- Как выглядел проект ребрендинга в общем и что надо было сделать технической команде
- Как вообще подходить к позиции технического руководителя и чем она отличается от инженерной
- Какие советы можно дать вкатывающимся в IT, а также продолжающим свое профессиональное развитие

В общем, выпуск получился очень плотный по темам, поэтому думаю, что вам не придется скучать при просмотре:)

P.S.
Я с Витей работаю 8 лет, с самого своего первого дня работы в компании и могу сказать, что он прошел большой путь от хорошего инженера до крутого технического руководителя. До последнего года он был моим прямым reportee и я как мог помогал этому случиться. В последний год он мой skip level reportee, но это ему не мешает показывать классные результаты.

#Management #Leadership #Software #Processes #Retrospective #ChangeManagement

Developer Productivity for Humans, Part 8: Creativity in Software Engineering (Рубрика #Management)

Продолжаю читать статьи от ребят из Google на тему продуктивности инженеров, а точнее в этот раз это статья про креативность. Я уже рассказывал про колонку про "Developer Productivity" в журнале IEEE. В этой статье авторы описываются свой подход примерно так:
1) Авторы исследования сделали обзор предыдущих статей и литературы и отметили, что креативность - это качество крутых инженеров
2) Но вот что значит креативность в software engineering - это большой вопрос, который авторы по привычке решили выяснить, начав с людей
3) Если кратко, то их выводы были в том, что креативность в разработке - это умное переиспользование, а не полная новизна, как принято в других сферах
4) Авторы проводили это исследование для того, чтобы понять как лучше измерять и поддреживать креативность инженеров - их интересует именно, что делает кретивным процесс разработки, а не какие персональные качества делают креативными конкретных инженеров
5) Свое исследование они решили сделать количественным, но поделили его на отдельные фазы
- Feedback studies, когда обратную связь нужно было дать непосредственно, когда происходило определенное событие
- Elicitation studies, когда нужно было сделать фотографию креативного момента раз в неделю (это мог был скриншот с сессии брейншторма, скриншот дизайн-документа, скриншот кода, который подвергся жестокому рефакторингу и так далее)
- Follow-up interviews, когда исследователи задавали вопросы по фотографиям с воспоминаниями и просили инженеров описать в чем именно состояли моменты креативности
- Post analysis, когда исследователи идентифицировали общие темы из собранных данных, такие как: повторное использование, инфраструктура, knhowledge sharing, обучение, новизна
- Объединение полученных тем с конкретными моментами в developer workflow, которые помогли исследователям получить более глубокое понимание опыта участников исследований
6) В итоге, авторы выделили три ключевые темы, которые относятся к креативности
- Коллаборация и брейншторминг взращивают креативность среди разработчиков
- Problem solving с исследованием проблемной области через изучение и исследование создают сцену для креативности
- Умное переиспользование и рекомбинация существующего кода полезным способом является основным атрибутом креативности в software engineering. Суть в том, что не надо быть новатором в коде, а лучше сделать решить сложную задачу простым и понятным способом, который потом будет легко поддерживать и развивать
7) Интересно, что авторы видят противоречие между продуктивностью и креативностью, когда чрезмерно фокусируясь на продуктивности не остается времени на креативные решения. Например, часто инженеры отмечали, что коллаборация с коллегами для решения сложной проблемы или сложный рефаторинг являются креативными, но редко когда такое менеджеры считают продуктивным:) Авторы формулируют гипотезу, что продуктивность - это про ближайшее время, а креативность про долговременный эффект от качественного кода.

Напоследок авторы отмечают, что

There remains a need to better understand what creativity means in the context of software engineering, how it affects the whole software development process, and how factors like work location or AI tools might influence it.

#Management #Leadership #Software #SoftwareDevelopment #Metrics #Processes #Creativity

Enhancing Software Design and Developer Experience Via LLMs (Рубрика #ML)

Иногда меня спрашивают почему я читаю whitepapers преимущественно от bigtech компаний. Часто я отвечаю, что они редко разачаровывают с точки зрения качества. Но тут я решил дать шанс другой статье, а точнее "Enhancing Software Design and Developer Experience Via LLMs" с "ASE '24: Proceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering"

Абстракт статьи звучит неплохо
- Первоначальное внимание уделяется способности моделей понимать концепции дизайна высокого уровня
- Впоследствии исследование переходит к расширенной генерации программных артефактов
- В конце вводятся методы, специфичные для организации или задачи, для повышения производительности и опыта разработчиков программного обеспечения.
Но если читать дальше, то складывается ощущение, что саму статью писал LLM:) И из всего плана исследования сделан только обзор работы LLMs для генерации кода.

А дальше я расскажу подробности.

Во введении идет речь, что сейчас LLM обычно дают подсказки уже после коммитов, а хотелось бы давать их или на ранних стадиях или в рантайме. Для этого автор рассказывает, что создание софта - это не только про написание кода и там есть еще куча этапов CI/CD. Поэтому план исследования выглядит так
1) Understand LLM - How LLMs handle code and natural language
2) LLM for software design (Plan-Code-Build-Test), где автор выделил фазы
- Post commit. Identify problems and provide solutions
- Pre-commit. Predict problems
- Line level suggestion. Predict problems & provide hints while developers are working
3) ML Plugin. Develop a framework that can provide ML hints to developers
4) Generalize the framework. Apply the framework in other software development processes

Интересно, что автор фокусируется на использовании в своих предсказаниях логов

This project aims to advance the analysis and utilization of logs geneated during software development and testing. By implementing real-time log analysis and auto-suggestion features, the research seeks to improve the post-test phase and provide actionable insights for future testing, simulation, and maintenance activities

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

В третьей части автор раскрывает карты и рассказывает про модель, которую он планирует использовать ... и это откопанная стюардесса, а точнее методология Model-Driven Architecture (MDA) от Object Management Group прямиком из начала двухтысячных. Сама методология предполагает использование трех шагов
1) Создание Platform-Independent Model (PIM)
2) Преобразование PIM в Platform-Specific Model (PSM)
3) И дальше генерация кода для выполнения

Автор исследования стремится предоставить решения, специфичные для организации или задачи, адаптированные к различным контекстам компании, а также структуру, способную обобщать эти решения для более широкого применения в индустрии программного обеспечения. Чтобы достичь этого, автор планирует сначала разработать PIM на основе домена, а затем PSM, которые отражают конкретные настройки и требования различных компаний. Впоследствии можно усовершенствовать первоначальную PIM на основе отзывов от PSM, тем самым создав стандартизированную архитектурную структуру, которую можно будет использовать в будущих проектах внутри определенного домена.

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

В пятой части автор рассказывает, что из всего описанного пока готов только обзор использования LLM при написании кода:)

P.S.
В итоге, у нас whitepaper уровня курсовой работы студента, что он нагенерировал вместе с GPT-4 за пару вечеров - обзор нормальный, а все остальное в планах:)

#AI #ML #Software

Fundamentals of Enterprise Architecture (Рубрика #Architecture)

Прочитал на каникулах книгу Tanu McCabe, что была посвящена корпоративной архитектуре и вышла квартал назад, а точнее в сентябре 2024 года. Мое мнение, что корпоративная архитектура - это удел корпораций, что сначала запускали devops трансформации, потом digital трансформации, а теперь все гонятся за AI. В общем, если у вас не технологическая компания, то enterprise architecture вам может и пригодится. В этой книге Tanu McCabe делает подход к снаряду, чтобы придать корпоративной архитектуре современный вид и теоретически у нее получается неплохо, но неясно как это стоит осуществлять на практике, хотя каждая глава сопровождается практически анекдотами, где приводятся примеры плохой реализации корпоративной архитектуры и хорошие варианты, что соответствуют современным тенденциям. И у нее достаточно неплохо это получается

Если говорить про основные мысли книги, то они изложены в первой главе, где затрагиваются следующие моменты

1) Зачем нужна корпоративная архитектура? И автор отвечает, что она нужна для
- Избегания изоляции отдельных частей организации (avoiding silos)
- Избегания хаоса - здесь идет речь про борьбу с complexity через стандарты
- Избегания технического долга, который мешает инновациям и бизнес гибкости
Все три вещи выше являются признаками неэффективной корпоративной архитектуры, а вот эффективная помогает сформулировать технологическую стратегию на каждом уровне корпорации и помогает поставлять нужные решения

2) Автор описывает vision, mission, что должны быть у корп архитектуры и приводит generic примеры

The vision: Define technology strategy that transcends organizational differences to connect different aims into common business goals.
The mission: Enable great architecture decisions to deliver great solutions as one team.

Читатели могут взять эти или придумать для себя сами.

3) Автор описывает функции корпоративной архитектуры, куда входят strategy, oversight, enablement, пересечение которых обеспечивает крутые архитектурные решения.
- Стратегия помогает в достижении бизнес-целей организации - для этого важно про них знать
- Enablement мне напоминает по описанию то, как компании создают платформы для поддержки работы своих компаний
- Oversight включает в себя governance, risk, compliance

4) Автор рассказывает про роли архитекторов: enterprise, solution, software. Тут примерно то же самое, что я рассказывал 4 года назад в докладе "Архитектура в масштабе или как мы в Tinkoff принимаем архитектурные решения". Правда, у нас не было корпоративных архитекторов, а их роль лежит на технических директорах как мне кажется:) Эти ребята принимают решения разных volume и scope.

5) В принятии архитектурных решений помогают специализированные функции, что включают security, network, cloud, SRE, data, compliance и так далее. В общем, это похоже на привлечение центров экспертиз для принятия важных решений.

6) Бывают разные организационные модели: централизованная, федеративная и гибридная
- В централизованной модели роль корпоративной архитектуры централизована и находится на уровне других топ-левел орг юнитов.
- В федеративной модели роли распределена по отдельным доменам
- В гибридной есть небольшая центральная часть, а основная часть федеративна

7) Автор описывает типичные архитектурные deliverables, что включают
- Architecture decision deliverable - подробнее можно почитать здесь
- Architecture pattern deliverable - это паттерн для решения типичной проблемы внутри организации, желательно с объяснением логики и примерами кода
- Capability target architecture deliverable - это целевое описание группы возможностей, которое можно назвать архитектурным доменом. Про это интересно рассказать в отдельном посте
- Application target architecture deliverable - это целевое описание архитектуры приложения

В общем, книгу определенно интересно читать, она хорошо и логично написана, многое звучит хорошо, но не ясно как оно должно работать на практике:)

#Architecture #Management #Leadership #Software