Design, Form, and Chaos (Дизайн, форма и хаос)

Эта классическая книга по дизайну от Пола Рэнда вышла в далеком 1993 году в "Yale University Press", а в России ее издает "Студия Артемия Лебедева". Книга очень короткая, но в ней есть определенная глубина - автор делится своими мыслями о сути графического дизайна и его роли в обществе. Автор может себе это позволить, так как у него десятилется опыта как успешного новатора в области графического дизайна. Свою книгу он выстроил вокруг следующих ключевых тем
- Связь между формой и содержанием - автор подчеркивает решающее взаимодействие между формой и содержанием, утверждая, что хороший дизайн не просто декоративен, но и служит для эффективной передачи идей
- Важность интуиции в дизайне - автор исследует роль интуиции в творческом процессе, подчеркивая, как дизайнеры должны сбалансировать инстинкт с рациональным мышлением для создания инновационных решений4
- Роль компьютеров в процессе проектирования - автор обсуждает влияние технологий на дизайн, предостерегая от чрезмерной зависимости от компьютеров в ущерб концептуальному мышлению.
По-факту, он отмечал уже в начале 90х годов засилие компьютеров и то, что молодые дизайнеры учатся зачастую не дизайну, а умению пользоваться компьютером (интересно что бы Пол Рэнд сказал на это сейчас)
- Принципы эффективного дизайна логотипов - опираясь на свой обширный опыт создания знаковых логотипов, Рэнд излагает принципы эффективного дизайна логотипа, подчеркивая простоту и запоминаемость. Мне действительно понравилась эта подборка, включающая IBM, IDEO и многие другие компании
- Искусство представления дизайнерских работ клиентам

Книга оказала глубокое влияние на сообщество дизайнеров.
1) Пол Рэнд укрепил свой статус лидера в графическом дизайне и поднял дизайн на уровень искусства и способа решения проблем клиентов
2) Акцент на форме и функции, а также призыв к критическому мышлению относительно своей работы, актуален для дизайнеров и сегодня
3) Стиль письма и крутые примеры Рэнда делают книгу популярной и доступной
4) Пол Рэнд не только делился своими мыслями и обучал коллег, но также смог поднять статус дизайна как профессии

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

#Design #Culture #History

From Requirements to Architecture: An AI-Based Journey to Semi-Automatically Generate Software Architectures (Рубрика #Architecture)

Это очередной академический whitepaper про использование AI в разработке софта. Здесь исследователи за 4 странички успевают
- Изложить свой план исследований, все значимое обещают в следующих сериях
- Сделать обзор предыдущих статей на тему генерации архитектуры из документации и автоматической оценки ее качества.

Концептуально процесс генерации от ребят выглядит так
1) Взять качественные требования и сгенерировать LLMs доменную модель и набор use cases
2) Взять напильник и немного ручками доработать получившуюся доменную модель и сценарии
3) Взять доработанные модель и сценарии и сгенерировать LLMs несколько архитектур-кандидатов + вытащить как-то ключевые ADR, которые были приняты при их проектировании. Тут предполагается использовать старый добрый "4+1 Model" от P. Kruchten (из 1995 года) + диаграммы в PlantUML и Mermaid
4) Взять кандидатов и прогнать через автоматизированную оценку (стандартный ATAM или другие подходы). Если с автоматизацией не сложится, то авторы готовы к запасному варианту в виде ручной оценки
5) Дальше если нужно эти архитектуры-кандидаты доработать через промпты к LLMs с просьбами о доработках
6) Финальным шагом является ручной выбор лучшего кандидата
Процесс до боли напоминает ICONIX в части генерации архитектуры из требований, но автоматизированный. Кстати, про ICONIX я сегодня уже вспоминал.

В рамках исследования авторы стаивили перед собой следующие вопросы

RQ1: Can state-of-the-art NLP technology generate reproducible, correct, and elaborate domain models and use case scenarios based on requirements in natural language?
RQ2: Can state-of-the-art AI technology generate software architectures based on a domain model, use case scenarios, and requirements that can appropriately fulfill these requirements?
RQ3: Can quantitative and qualitative software architecture evaluations and trade-off analyses be automated through the use of AI?
RQ4: Does a method for semi-automatic architecture generation improve the architecture’s quality while reducing the time required?
Ответы

на вопросы в этой статье не даны, но есть план на дальнейшие исследования, который включает
1) Ручной разбор нескольких референсных архитектур для восстановления списка требований к ним
2) Дальше скармливание этих требований обратно LLMs и получение архитектур-кандидатов
3) Сравнение этих кандидатов с референсными архитектурами глазами
4) Попытка сделать автоматическую оценку архитектур-кандидатов

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

Из референсов к статье мне показались интересными
- "Software Architecture Metrics: a literature review" с обзором архитектурных метрик
- "Experiences applying automated architecture analysis tool suites" с опытом автоматического примения инструментов для анализа

Также я вспомнил
- "Architecture Anti-patterns: Automatically Detectable Violations of Design Principles" - хороший paper, мой разбор здесь
- "Enhancing Software Design and Developer Experience Via LLMs" - поверхностый paper, мой разбор здесь

Собственно, этот paper по уровню практической проработанности слаб, но теоретически план исследований выглядит интересно.

#LLM #AI #Architecture #Software #Engineering #Management #Processes

Code of Leadership #28 - Interview with Vadim Goncharov about Design in Software Development (Рубрика #Management)

В этом выпуске подкаста ко мне пришел Вадим Гончаров поговорить про свой путь в ИТ и как на это повлияло увлечение дизайном. Вадим в веб-разработке больше 15 лет. В 2008 руководил собственной веб-студией. С 2013 работал в VK, а в 2017 присоединился к Т-Банку, где в качестве технического руководителя запускал "Тинькофф Журнал", самое крупное медиа про деньги в России. С 2020 Вадим начал руководить разработкой интерактивных спецпроектов и игр в мобильном приложении Т-Банка. Он проповедует lifelong learning: закончил МИЭМ, учился в Британке и Вышке, а сейчас учится в Сколково на программе МБА. Эпизод также доступен в Yandex Music и podster.fm

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

Список рекомендаций для изучения
- Программист Прагматик. Эндрю Хант
- Совершенный код. Стив Макконнелл
- Чистый Код. Роберт Мартин
- Release It! Second Edition. Design and Deploy Production-Ready Software. Michael Nygard
- Дизайн привычных вещей. Дональд Норман
- Дизайн для реального мира. Виктор Папанек
- Дизайн-мышление в бизнесе. Тим Браун
- Beautiful Evidence. Edward Tufte
- Visual Explanations: Images and Quantities, Evidence and Narrative. Edward Tufte
- Envisioning Information. Edward Tufte
- The Visual Display of Quantitative Information. Edward Tufte
- Look Inside: Cutaway Illustrations and Visual Storytelling. Juan Velasco and Samuel Velasco

#Management #Leadership #Software #Processes #Retrospective #Design #Processes #SelfDevelopment

Think Like a CTO (Настоящий CTO: думай как технический директор) - Part I (Рубрика #Management)

Прочитал на неделе эту книгу Алана Уильямсона, что работает в частном инвестиционном фонде и часто выступает временным CTO для небольших компаний, что покупает этот фонд. Алан написал достаточно интересную книгу на тему бытия техническим директором. По оглавлению книга выглядит как надо - автор постарался обсудить большую часть важных тем. Правда, если заглядывать внутрь, то многие из этих тем прокопаны не слишком глубоко. Я связываю это с тем, что Алан работал в основном с небольшими и нетехнологическими компаниями, поэтому его советы годятся на инженерный масштаб до нескольких десятков людей. Оригинальная книга издана в Manning, а перевод вышел в издательстве "Питер" и он приемлемый.

А теперь давайте заглянем в содержание книги

1. Технический директор - размышления автора насчет содержимого роли технического директора в зависимости от размера компании, ее типа, стадии жизненного цикла. В далеком 2021 году я рассказывал доклад "Что такое CTO от стартапа до IPO" на Highload++". Смысл примерно такой же, но мне кажется, что у меня получилось поинтереснее:)
2. Взаимодействие с руководителями и коллегами - здесь автор рассказывает как находить общий язык с CEO и CFO. Звучат советы про то, чтобы понять потребности коллег и найти с ними общий язык. Вообще важно уметь в правильные коммуникации и разбираться во внутренней политике:) А также надо уметь правильно реализовывать изменения.
Отдельно автор упоминает про разные стили лидерства, приводя в пример оркестр - тут я рекомендую почитать книгу "Несведущий маэстро" ("The ignorant maestro") про стили лидерства на примере стилей знаменитых дирижеров, про которую я уже рассказывал. А также рекомендую изучить книгу "Seat at the Table", которая рассказывает что нужно уметь техническому директору, чтобы сидеть за одном столом с другими топ-менеджерами (я про нее тоже рассказывал).
3. Долгосрочное видение - здесь речь идет про видение, миссию, стратегию организации, а также необходимость сделать так, чтобы технологическая стратегия помогала с этим. Автор рассказывает про долгосрочное планирование, питчинг идей, бюджетирование, окупаемость проектов, а также работу с ожиданиями стейкхолдеров. Я на эту тему могу порекомендовать отличную книгу "Technology Strategy Patterns. Architecture as Strategy", которую я изучил больше пяти лет назад и которая дала мне многое в плане построения технологической стратегии (я рассказывал про нее здесь)
4. Создание команды - здесь автор рассматривает разные способы формирования команды: найм в штат, найм на подряд, аутстафф, аутсорс и так далее. По-факту, автор дает базовую сравнительную табличку с плюсами и минусами каждого из вариантов. Также он рассказывает про матрицу навыков, которую стоит заполнять по своим людям в команде, чтобы понимать какие области небходимых навыков закрыты хорошо, а по каким есть риски (условно, только Петя знает про инфру и если он уйдет, то хз что станет с серверами) - это позволяет искать кандидатов, что усилят команду. Дальше автор говорит про составление вакансии и поиск кандидатов через разные источники. В общем, все очень просто и базово.
5. Собеседования, выбор подходящего кандидата и его онбординг - здесь автор рассказывает про собеседования, но очень базово. Мне кажется, что я гораздо интереснее это раскрыл в своей серии статьей про найм: как нанимают в крупные компании, а потом отдельно про разработчиков, руководителей, SRE и даже аналитиков.
6. Управление командой - здесь автор говорит про типы команд, их цели, метрики, состав и так далее. Но мне кажется, что про эту тему лучше почитать книгу "Team topologies", в которой отлично разложено какие команды бывают, какие у них бывают цели и форматы взаимодействия, тем более я уже рассказывал про эту книгу раньше. Ну и у меня есть большой рассказ про то, как создавать команды под запросы бизнеса

Продолжение обзора книги в следующем посте.

#Management #Leadership #Processes #Software #Architecture #Strategy #ChangeManagement

Think Like a CTO (Настоящий CTO: думай как технический директор) - Part II (Рубрика #Management)

В продолжении первого поста о книге "Think Like a CTO" здесь я расскажу про вторую часть книги.

7. Ежегодная оценка сотрудников - здесь автор рассказывает про performance review, промотирование и увольнение сотрудников. Я отдельно рассказывал про performance review, а также про наш процесс Т-Роста, который мы используем для роста сотрудников
8. Технологические решения - рассказ о том, как принимать сложные технологические решения, например, buy vs build, on-prem vs cloud, reliability vs cost или closed source vs open source, микросервисы или монолиты. Если кратко, то автор рассматривает плюсы и минусы каждого из подходов. Но вообще, общий паттерн рассмотрения вопроса долженн быть таков, что надо провести исследования, сравнить альтернативы, а потом принять решения. Я больше 5 лет назад рассказывал примерно об этом в докладе "Архитектура в масштабе или как мы в Tinkoff принимаем архитектурные решения"
9. Разработка - здесь автор рассказывает пару страниц о проектном управлении, потом криво рассказывает про waterfall и agile (очень криво), дальше про обеспечение качества. Честно говоря, это очень слабая глава, ооочень. По поводу проектов и продуктов рекомендую почитать мою статью, а про инженерные процессы рекомендую глянуть книгу "Grokking Continuous Delivery", про которую я рассказывал недавно
10. Работа с договорами - здесь гигиеническая база по договорной работе и важности привлечения юристов для изучения договоров:) А также важность лицензий на интеллектуальную собственность в общем, и код в частности.
11. Документация - здесь автор рассказывает базу про документацию. Правда, здесь видно, что автор привык работать в маленьких конторах и, например, предлагает документировать релизный процесс, а не нормально его автоматизировать. В общем, опять слабая глава.
12. Безопасность - очередная базовая глава про безопасность. Рекомендую вместо этого почитать книгу от Goolge "Building Secure and Reliable Systems", про которую я рассказывал. Также можно почитать старенькую книгу "Agile Application Security", про которую я рассказывал раньше
13. Поддержка и обслуживание - здесь автор рассказывает про operations часть, но делает это очень базово:) Рекомендую вместо этого почитать про это мой доклад о том, как проектировать надежные системы и поддерживать их надежность во время эксплуатации системы
14. Рост компании - глава про проведение due diligence, принятии и передаче должности технического директора. В принципе, норм, но очень базово.
15. Вы, Inc - глава о том, как идти в ногу со временем, поддеживать свой технический уровень, а также скиллы руководителя. А в конце автор дает совет, что не стоит задерживаться на работе, которая не соответствует вашим долговременным карьерным целям и не приносит удовлетворения.

P.S.
Про должности и ответственность CTO я уже как-то рассказывал в посте про инфляцию должности CTO

#Management #Leadership #Processes #Software #Architecture #Strategy #ChangeManagement