Confession of an Engineer: Overcoming Anti-Values in Extreme Programming
•
1 gostou•1,101 visualizações
We all are professionals, e.g. software engineers, quality engineers, technical/team leaders, project/product managers, etc. But we all are humans too. Often due to different reasons, like tight deadlines, push from customers/clients, etc., we all tend to neglect common sense and omit important practices. In this talk based on my both positive and negative experience we will review some patterns how we make common mistakes and what terrible results they may lead us to. Presented at XP Days Ukraine Conference in Kyiv in 2015. Design by Yarko Filevych (http://www.filevych.com/)
Recomendados
Recomendados
Mais conteúdo relacionado
Destaque
Destaque (20)
Semelhante a Confession of an Engineer: Overcoming Anti-Values in Extreme Programming
Semelhante a Confession of an Engineer: Overcoming Anti-Values in Extreme Programming (20)
Mais de Taras Matyashovsky
Mais de Taras Matyashovsky (10)
Último
Último (20)
Confession of an Engineer: Overcoming Anti-Values in Extreme Programming
- 1. Confession of an Engineer TARAS MATYASHOVSKY
- 3. About me
- 4. What is XP in a perfect case? WHEN SOFTWARE ENGINEERING PRACTICES ARETAKENTO "EXTREME" LEVELS
- 5. XP Practices
- 7. Values of XP • Communication • Simplicity • Feedback • Respect • Courage
- 8. What is this talk about? WHEN PAIN,ABSURDITY, MARASMUS ARETAKENTO "EXTREME" LEVELS
- 11. The 6 Principles of Influence also known as the Weapons of Influence • Reciprocation • Consistency • Social proof • Liking • Authority • Scarcity
- 12. Authority Humans feel a sense of duty or obligation to people in positions of authority
- 13. Authority in IT
- 14. Authority • Is senior engineer truly a “senior”? • Is architect really an expert in this technology stack? • Is manager truly an expert in risk mitigation, understands development processes, estimates techniques, etc? • Is this customer/client truly a domain expert (SME)?
- 15. Is Customer Always Right? BASED ONTRUE STORIES
- 16. CEO is extremely technical DRIVESALL CRITICALTECHNICAL DECISIONS
- 17. Customer • Push for specific technology, framework, tool, etc. without getting into the essence of the problem
- 18. Customer
- 19. Resistance • Remain professional • Use common sense • Play safe • Remember authority principle • Take into account political environment
- 20. Effect Captainitis Automatic, but irrational compliance
- 21. Effect Captainitis in IT Mistakes made by senior engineers, TL/PM, customer/clients are easily ignored
- 22. Is PM/Architect/TL Always Right? BASED ONTRUE STORIES
- 23. Architect/TL • Unipersonal decision maker and point of control
- 24. Architect/TL • Push for specific technical solution without getting into the essence of the problem
- 25. Architect/TL • Push for specific estimates for particular task/entire team
- 26. Architect/TL • Absence of key technical decision maker
- 27. PM/TL • Manipulation with scope, quality and definition of done
- 29. Resistance • Remain professional • Use common sense • Start conversation but play safe • Build trust via transparency & delivery • Remember effect captainitis
- 32. Since nobody is concerned, nothing is wrong Pluralistic Ignorance Phenomenon
- 33. Are Your Colleagues Always Right? BASED ONTRUE STORIES
- 34. Engineer • Missed important feature or a critical bug
- 35. Engineer
- 36. Engineer • Regression test suite always fails
- 37. Engineer • Long running feature branches
- 38. Engineer • Unjustified criticism of the customer
- 39. Resistance • Remain professional and be objective • Start conversation • Share your knowledge • Lead by example • Remember pluralistic ignorance phenomenon
- 40. What is XP in a worst case? WHEN ANTI-VALUES ARETAKENTO "EXTREME" LEVELS
- 41. Anti-Values of XP • Suppression • Complexity • Silence • Neglection • Fear Lead to lack of motivation
- 43. Resistance • Remain true to yourself and your own standards • Don’t lose your motivation • Make your own reality • Do your job or do your job
- 44. Q&A? THANKYOU!
Notas do Editor
- Люди говорять XP – і відразу згадують саме інженерні практики
- Проте книга Кента Бека не тільки про це
- Ще перед вивченням практик Кент Бек говорить про важливість існування спільних цінностей, всередині команди, збоку менеджера, замовника, навіть коду, які б показували нам, що ми рухаємося в правильному напрямку. Комунікація – як всередині команди, так із менеджером та замовником, уміння говорити про важливі речі, не замовчувати, уміння ставити правильні питання колегам, менеджеру, замовнику і навпаки. XP змушує нас комунікувати через відповідні практики: unit testing, pair programming, task estimation. Простота – це уміння зробити просту річ сьогодні і витратити більше часу завтра, щоб покращити її, замість того, щоб зробити надзвичайну складну річ сьогодні, якою завтра не будуть в повній мірі користуватись. Зворотній зв’язок – більщість людей думає про зворотній зв’язок від замовника чи менеджера, але це в основному про зворотінй зв’язок від самої аплікації. Час зворотнього зв’язку теж може різнитися – від швидкого через юніт тести, до довшого через user stories чи functional tests. Повага – до членів команди, до замовника і що найголовніше до самої аплікації, її коду. Мужність (сміливість) – здатність визнати неправильне технічне рішення, неправильну архітектуру чи дизайн компоненти, сміливість викинути код, без якого колись здавалось аплікація жити не зможе, уміння говорити правду про прогрес і естімейти. Уміння адаптуватись і змінюватись, коли потрібно.
- Коли біль, абсурд, маразм теж можуть бути доведені до екстремального рівня
- Ми будемо говорити про реальні негативні випадки з життя з точки зору 3 ключових ролей – замовника, тім/тех ліда/ПМ/архітекта та звичайного члена команди – інженера.
- Для пояснення поведінки людей в деяких випадках варто звернутись до психології, адже всі ми люди в кінці кінців. Мені дуже подобається книга Роберта Чалдіні «Психологія Впливу», у якій він описав найбільш популярні методи впливу одних людей на інших.
- принцип взаємного обміну принцип послідовності принцип соціального доказу принцип прихильності принцип авторитету принцип дефіциту У мене є окрема презентація, що детально описує їй всі, проте під час цієї доповіді ми згадаємо тільки ті, які релевантні до наших прикладів і історій.
- Люди відчувають почуття обов’язку або зобов'язання до людей, наділених авторитетом. У нас глибоко вкоренилася необхідность покори авторитетам. Приклад з тестом на пам’ять і електричним зарядом, якщо буде час.
- Job title, uniform, status, height, attributes, etc. can lend an air of authority and can persuade us to accept what these people say. Remove element of surprise and ask yourself – is this authority truly an expert? Seek for the authority’s credentials and the relevance of those credentials to the topic at hand
- Приклади в ІТ (умовно заберіть всі зовнішні атрибути авторитету і задайте кілька питань): чи той колега, який Вас так люто критикує є хоча б авторитетом у цій сфері? чи архітект є дійсно експертом в тій області, в якій він дає поради? Скільки в нього є успішних рішень взагалі і базованих на цих технологіях зокрема? чи Ваш менеджер дійсно розбирається в базових основах менеджменту чи це просто титул? естімейти коммітменти зниження ризиків процеси і практики Чи Ваш замовник є дійсно доменним експертом для продукту, що розробляється Вами, і чи його вимогам таки треба сліпо слідувати?
- CEO/CTO мають іншу роль, відповідальність, skill set, що не сумісний з суто технічною позицією. Дуже часто це призводить до внутрішніх конфліктів, проблем якості, підтримки продукту і до інших фатальних наслідків.
- Нав’язування конкретного фреймворка/тула без розбирання в суті проблеми: RDBMS vs. Impala/Splice Machine/Apache Phoenix (100m records) Impala - open source massively parallel processing (MPP) SQL query engine for data stored in a computer cluster running Apache Hadoop. Impala provides low latency and high concurrency for BI/analytic queries on Hadoop (not delivered by batch frameworks such as Apache Hive). Impala also scales linearly, even in multitenant environments. Apache Phoenix is a relational database layer over HBase delivered as a client-embedded JDBC driver targeting low latency queries over HBase data. Apache Phoenix takes your SQL query, compiles it into a series of HBase scans, and orchestrates the running of those scans to produce regular JDBC result sets. Splice Machine exposes a full ANSI SQL query facility for HBase, along with support for indices, database triggers, and other data management essentials. It's ACID-compliant, too. Neo4j vs. Apache Spark Gridgain vs. Apache Spark Etc.
- Resume-driven development: Коли замовник хоче брати в проект всі останні тули, технології, підходи до архітектури, або те, що юзають інші відомі компанії, навіть якщо це маловідомі тули. LinkedIn Norbert - is a library that provides easy cluster management and workload distribution. It is implemented in Scala. It helps to create a highly scalable architecture capable of handling heavy traffic. Microservices architecture (причому від невідомих компаній) Airbnb SmartStack - is an automated service discovery and registration framework. It makes the lives of engineers easier by transparently handling creation, deletion, failure, and maintenance work of the machines running code within your organization. Predictive analytics based on Spark, R, etc. Etc.
- перестрахуватись: наприклад в тих кейсах, що були в мене - додати логінг з усіх сервісів, подивитись реальний перформанс, юзати профайлінг і так далі, зрозуміти чи реальна проблема саме в storage чи в обробці результатів, кожеш раз питати себе «чому так?» пам’ятати про принцип авторитету і давати йому відсіч активності можуть бути як чисто технічні, так і політичні мислити глобально, намагатись зрозуміти реальні причини рішення керівництва, наводити контраргументи по реальним причинам
- Часто очевидна помилка капітана не виправляється іншими членами команди, що призводить до краху. Схоже, що, незважаючи на очевидну особисту значимість питань, пов'язаних з управлінням літаком, члени команди використовували правило-стереотип «Якщо так говорить фахівець, це має бути вірно», не звертаючи уваги на згубну помилку капітана.
- Приклади в ІТ очевидні: на помилки найдосвідченіших розробників в команді ніхто не зважає на помилки тім ліда/менеджера ніхто не зважає І що найголовніше, на помилки самого замовника ніхто не зважає
- Migration Tool в Marktplaats - чуть не призвело до трагедії Marktplaats - the Netherlands’ #1 classifieds site Most popular e-commerce site in the Netherlands — reaches 74 percent of the Dutch online population Мігрували всі оголошення на нову пакетну пропозицію. Головний архітект не давав нам почати роботи на тулом для міграції, бо вважав це елементарною роботою. В кінці кінців сам тул для міграції став незалежною апліікацією, що писалася з перервами 4 місяці і мала купу бізнес логіки, а також унікальних edge cases. Хоча сам архітект називав це 2 годинною роботою – простий Perl script. Перша версія ранилася ~8 годин, що буо неприпустимо. Далі ми покращували версію, яка ранилася в продакшені 3 годин. І працювали над збереженням гарних результатів роботи в лог і окрему таблицю. Кількість промігрованих оголошень – 50к+, відгуків 250к+ Також на базі цього був написаний тул, що мігрував неактивні оголошення після релізу. І якби нашого тула не було б, то могла б трапитись трагедія. Кількість промігрованих неактивних оголошень – 200к+
- Треба замінити Infinispan на Hazelcast без чітко сформульованої причини. Мені було виділено на це кілька днів, що виявилось нереально мало. Написав спільний контекст, можливість зробити будь-який кеш на базі Infinspan чи Hazelcast за допомогою простої проперті і так далі. Під час імплементації я виявив закоментовані завалені тести, а після мого коміту виявились завалені functional tests, так як один з кешів не був distributed насправді. Елементарна на перший погляд задача показала проблеми в тестах і в реальному використанні кешу. Second level cache для Hibernate - що було сказано, і в чому була реальна проблема - як я читав про second level cache, думав прикручувати, потів включився gut feeling, дебажив, проблема з фільтром на статичні ресурси, фільтром. який вимагав вибірку юзера з бази.
- Migration Tool – just 2 hours of work – simple Perl script. Тул писався кожен тиждень по пару годин, дуже багато часу зайняло вияснення requirements, індивідуальної обробки кожного edge case і так далі. Hazelcast - trivial task - just change bean in the context, замість Infinispan bean заюзай Hazelcast bean. Реально таска зайняла 2-3 тижні з тестами як unit, так і functional.
- відсутність глобального technological vision на проекті – нема нормальної deployment diagram, нема розуміння який сервіс з яким спілкується, в яких сервісах юзається hornetq, хто реально пише/читає з якої бази і так далі. неконтрольованість глобальних технічних рішень нема key technical decision maker, кожен з сініор девелоперів робить свій resume driven development запрошення сторонніх консультантів за великі гроші як варіант виходу із ситуації архітектурні мітинги по кілька годин в тиждень, просто щоб зрозуміти, що відбувається з аплікацією
- добавлення нового великого функціоналу в проестімований scope без зміни дат заниження стандартів якості, код без юніт/інтеграційних тестів льється в мастер під тиском зверху – просто треба запушати чуваки
- Гра слів з поганими результатами – як результат поняття respect з XP нівелюється. Розповісти як я їх почав теж називати ресурсами і як їм було неприємно це чути.
- перестрахуватись, розбиратись в суті проблеми, задавати собі кілька питань «чому так?» перед тим як братись за якусь технічну задачу, де є чітко описане технічне рішення пам’ятати про ефект капітанства і давати йому відсіч
- Феномен плюралістичного невігластва Situation in which a majority of group members privately reject a norm, but incorrectly assume that most others accept it, and therefore go along with it Розуміння суті цього феномена допомагає пояснити причину одного поширеного негативного явища - нездатності великого числа сторонніх спостерігачів надати допомогу жертвам, які надзвичайно її потребують. Pluralistic ignorance may help to explain the bystander effect. If no-one acts, onlookers may believe others believe action is incorrect, and may therefore themselves refrain from acting. This is also described as "no one believes, but everyone thinks that everyone believes." In short, pluralistic ignorance is a bias about a social group, held by a social group. With several potential helpers around, the personal responsibility of each individual is reduced social evidence
- Всі бачать один і той самий код, проте ніхто не задасть просте питання – чому у нас відбувається саме так? Що це за дивний код? Magic numbers in the code, 42?
- Build Failed - nobody cares - as everybody works in their own long running branches
- As a result it is not possible to say if new feature did not introduce regression in comparison to master So we sometimes compare stability of features by comparing quantity (not even list to list) of failed tests in regression suite
- Згадати найбільші маразми: Фічі тривалістю рік День/два коли всі бренчі підтягували зміни з мастеру замість того, щоб кодити Люди, які розвалювали спірну логіку, не знаючи що ми її уже змінили і так далі Фічі, які уже нікому то і не потрібні
- MP і приклад з точки зору UX, коли всі девелопери казали як має бути краще
- Приклад з моїм рефакторингом статичних методів, покриття тестами і так далі Створюйте атмосферу, де можна задавати будь-яке питання, навіть дуже абсурдне
- Багато хто думає, що найгірший варіант XP це відсутність 13-ти практик. Я вважаю, що найгірше – це відсутність цінностей або ще гірше – наявність анти цінностей
- Замовчування замість комунікації - communication Складність замість простоти - simplicity Тишина від людей/тестів/продукту замість зворотнього звязку - feedback Зневага замість поваги - respect Страх замість мужності щось змінити - courage І як результат втрата мотивації