Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Deliver Fast with Confidence

329 views

Published on

Being agile, with its attention on extensive testing, frequent integration, and focusing on important product features, has proven invaluable to many software teams. When building complex systems it can be all too easy to primarily focus on features and overlook software qualities, specifically those related to software architecture. Time has shown that agile practices are not sufficient to prevent or eliminate technical debt, which can ultimately affect reliability. Many issues arise when there isn’t good validation through tests and constant attention to the architecture and code quality. It is important to recognize what is core to the architecture and the problem at hand while evolving it. If there is not enough attention on the architecture and the code, technical debt will creep in to the point where it can become muddy, making it hard to deliver new features quickly and reliably. Two principles that can help teams deliver more quickly and with confidence is to focus on code quality and delivery size. Small frequent delivery with constant attention to a good codebase is crucial to being able to sustain faster reliable delivery. Practices that can help keep the code clean or prevent it from getting muddier include: Testing, Divide & Conquer, Gentrification, Quarantine, Refactoring, and Craftsmanship. This talk examines various practices and techniques such as Continuous Integration, Continuous Delivery, Continuous Inspection, along with techniques to pay good attention to software quality, all of which enable teams to deliver fast and with confidence.

Published in: Technology
  • Be the first to comment

Deliver Fast with Confidence

  1. 1. 6/4/2017 1 Deliver FAST “with confidence” Joseph W. Yoder The Refactory Teams That Innovate Copyright 2017 Joseph Yoder & The Refactory, Inc. Twitter: @metayoda joe@refactory.com http://www.refactory.com http://www.teamsthatinnovate.com Introducing Joseph Founder and Architect, The Refactory, Inc. Pattern enthusiast, author and Hillside Board President Author of the Big Ball of Mud Pattern Adaptive Systems expert (programs adaptive software, consults on adaptive architectures, author of adaptive architecture patterns, metatdata maven, website: adaptiveobjectmodel.com) Agile enthusiast and practitioner Business owner (leads a world class development company) Consults and trains top companies on design, refactoring, pragmatic testing Amateur photographer, motorcycle enthusiast, enjoys dancing samba!!! Loves Sushi, Ramen, Taiko Drums 
  2. 2. 6/4/2017 2 https://commons.wikimedia.org/wiki/File:2012_WTCC_Race_of_Japan_(Race_1)_opening_lap.jpg
  3. 3. 6/4/2017 3 architecture quality can be invisible …especially when the spotlight is on FEATURES
  4. 4. 6/4/2017 4 EBiz New Products Features Mobile Version © Can Stock Photo Inc. / alex5248 The Solution © Can Stock Photo Inc. / Freezingpicture
  5. 5. 6/4/2017 5 What’s below the waterline? all those “ilities” we can’t ignore … Reliability Scalability Stability Maintainability Performance © Can Stock Photo Inc. / SergeyNivens Chris Richardson http://microservices.io 11
  6. 6. 6/4/2017 6 Sustaining Your Architecture Big Ball of Mud Alias: Shantytown, Spaghetti Code A BIG BALL OF MUD is haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle. The de-facto standard software architecture. Why is the gap between what we preach and what we practice so large? We preach we want to build high quality systems but why are BBoMs so prevalent? Sustaining Your Architecture Big Ball of Mud Alias: Shantytown, Spaghetti Code A BIG BALL OF MUD is haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle. The de-facto standard software architecture. Why is the gap between what we preach and what we practice so large? We preach we want to build high quality systems but why are BBoMs so prevalent? Brazilian architect Oscar Niemeyer Lisa Pollack
  7. 7. 6/4/2017 7 Sustaining Your Architecture Agile Myths  Simple solutions are always best  We can easily adapt to changing requirements (new requirements)  Scrum/TDD will ensure good Design/Architecture  Good architecture simply emerges from “good” development practice  You always go fast when doing agile  Make significant architecture changes at the last moment “www.agilemyths.com”
  8. 8. 6/4/2017 8 Confidence Linda Northrop Values Drive Practices
  9. 9. 6/4/2017 9 Agile/Lean Design Values  Core values:  Design Simplicity  Quick Feedback  Frequent Releases  Continuous Improvement  Teamwork/Trust  Satisfying stakeholder needs  Building Quality Software  Keep Learning  Sustainable Development
  10. 10. 6/4/2017 10 Delivery Size??? Delivery Size is Key Large Delivery Size can cause many issues Issues:  More potential defects  Longer time to get feedback  Slower adjust time  Harder to experiment  Bugs take a long time to fix
  11. 11. 6/4/2017 11 Small Deliveries Quick Feedback Chris Richardson
  12. 12. 6/4/2017 12 What about Quality? Bad Code Smells Have you ever looked at a piece of software that doesn't smell very nice? A code smell is any symptom in the source code that can indicate a problem!
  13. 13. 6/4/2017 13 Neglect Is Contagious Disorder increases and software rots over time Don’t tolerate a broken window http://www.pragmaticprogrammer.com/ppbook/extracts/no_broken_windows.html Is it better to clean little by little? Or to let dirt and mess accumulate?
  14. 14. 6/4/2017 14 Some dirt becomes very hard to clean if you do not clean it right away! Technical Debt? Clean Code Doesn't Just Happen •You have to craft it •You have to maintain it •You have to make a professional commitment “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” – Martin Fowler
  15. 15. 6/4/2017 15 But We Don’t Have Time! Professional Responsibility There’s no time to wash hands, get to the next patient! http://en.wikipedia.org/wiki/Image:I_Semmelweis.jpg
  16. 16. 6/4/2017 16 Professionalism Make it your responsibility to create software: Delivers business value Is clean Is tested Is simple Good design principles When working with existing code: If you break it, you fix it You never make it worse than it was You always make it better Refactoring “If you value clean code…”
  17. 17. 6/4/2017 17 Sustaining Your Architecture Refactorings Behavior Preserving Program Transformations • Rename Instance Variable • Promote Method to Superclass • Move Method to Component Always done for a reason!!! Refactoring is key and integral to most Agile processes!!! TDD Two Refactoring Types* Floss Refactorings—frequent, small changes, intermingled with other programming (daily health) Root canal refactorings—infrequent, protracted refactoring, during which programmers do nothing else (major repair) * Emerson Murphy-Hill and Andrew Black in “Refactoring Tools: Fitness for Purpose” http://web.cecs.pdx.edu/~black/publications/IEEESoftwareRefact.pdf
  18. 18. 6/4/2017 18 Ten Most Putrid List 1) Sloppy Layout, 2) Dead Code, 3) Lame Names, 4) Commented Code, 5) Duplicated Code, 6) Feature Envy, 7) Inappropriate Intimacy, 8) Long Methods & Large Class, 9) Primitive Obsession & Long Parameter List, 10) Switch Statement & Conditional Complexity … 0) Magic Numbers, Sustaining Your Architecture Lame Names void foo(int x[], int y, int z) { if (z > y + 1) { int a = x[y], b = y + 1, c = z; while (b < c) { if (x[b] <= a) b++; else { int d = x[b]; x[b] = x[--c]; x[c] = d; } } int e = x[--b]; x[b] = x[y]; x[y] = e; foo(x, y, b); foo(x, c, z); } void quicksort(int array[], int begin, int end) { if (end > begin + 1) { int pivot = array[begin], l = begin + 1, r = end; while (l < r) { if (array[l] <= pivot) l++; else swap(&array[l], &array[--r]); } swap(&array[--l], &array[beg]); sort(array, begin, l); sort(array, r, end); } } http://dreamsongs.com/Files/BetterScienceThroughArt.pdf
  19. 19. 6/4/2017 19 Sustaining Your Architecture Fixing Names Names should mean something. Standards improve communication - know and follow them. Standard protocols object ToString(), Equals() ArrayList Contains(), Add(), AddRange() Remove(), Count, RemoveAt(), HashTable Keys, ContainsKey(), ContainsValue() Standard naming conventions Sustaining Your Architecture Safe Refactorings Rename is always safe!!! New Abstract Class moving common features up Extract Method (always safe) Extract Interface / Extract Constant Pull Up / Push Down Create common component for shared internal methods  Fairly safe but can be harder to share
  20. 20. 6/4/2017 20 Sustaining Your Architecture You Must Test When you find smelly code, you often apply refactorings to clean your code. Testing is a key principle for safe refactoring! Sustaining Your Architecture Common Wisdom “In almost all cases, I’m opposed to setting aside time for refactoring. In my view refactoring is not an activity you set aside time to do. Refactoring is something you do all the time in little bursts.” — Martin Fowler Work refactoring into your daily routine…
  21. 21. 6/4/2017 21 PAUSE POINTS HELP Kaizen The Sino-Japanese word "kaizen" simply means "change for better", with no inherent meaning of either "continuous" or "philosophy" in Japanese dictionaries or in everyday use. The word refers to any improvement, one-time or continuous, large or small, in the same sense as the English word "improvement". (Wikipedia) Most view it as Continuous Improvement…
  22. 22. 6/4/2017 22 Slack Time Need Slack time to improve Ways to get slack time…  Monitor and Make Visible  Reduce Waste (Muda)  Inject time into process (retros, daily cleanup, …) Try little experiments… (c) Can Stock Photo / AntonioGuillem Continuous Improvement “Retrospectives are Key!!!” Small Steps we can take - next sprint!!!
  23. 23. 6/4/2017 23 Spotify: Innovation Regular Practices We must make time: Allocate time for dealing with tech debt Team building and education sessions Evaluate and Reflect…small changes
  24. 24. 6/4/2017 24 HOW SYSTEM QUALITY WORK CAN FIT INTO YOUR RHYTHMS “QUALITY IS NOT AN ACT, IT IS A HABIT.” —ARISTOTLE Build architectural quality into your project rhythms
  25. 25. 6/4/2017 25 SO CHOOSE THE MOST RESPONSIBLE MOMENT Some decisions are too important to leave until The Last Responsible Moment Qualify the Roadmap “All you need is the plan, the roadmap, and the courage to press on to your destination” — Earl Nightingale
  26. 26. 6/4/2017 26 Qualify the Roadmap2017 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2018 Jan Feb Mar DELIVERY Delays expected to Version 1 Delays expected to Version 1 DEVELOPMENTDASHBOARD BUDGET RESOURCE ARCHITECTURE DEPENDENCIES Budget will need bolstering in Q2 2017 Budget will need bolstering in Q2 2017 All resources on track. All resources on track. Persistence Framework Load- Balancing. Cloud Persistence Framework Load- Balancing. Cloud Partnerships and services all in place and on track. Partnerships and services all in place and on track. RISKS ISSUES ON RADAR COMPETITOR E Corp – new product. COMPETITOR E Corp – new product. ARCHITECTURE Performance Platform stability ARCHITECTURE Performance Platform stability DELIVERY Tech issues DELIVERY Tech issues ARCHITECTURE Migration Security ARCHITECTURE Migration Security AUG 2017 New mobile opportunity AUG 2017 New mobile opportunity OCT 2017 Re-evaluate NO SQL strategy OCT 2017 Re-evaluate NO SQL strategy RICH MOBILE WEB APPSMOBILE WEB v2MOBILE WEB v1 PC PLATFORM v1 PC PLATFORM v2 ONGOING RELEASES MOBILE RESEARCH ANDROID v1 IOS v1 RESPONSIVE DESIGN ENTEPRISEARCHITECTURE MOBILE GENERIC SERVICES SYBASE TO ORACLE MIGRATIONPERSISTENCE FRAMEWORK LOAD BALANCING PLATFORM STABILITY CLOUD RESEARCH MICROSERVICES TBD LOW RISK HIGH RISK NORMAL NO SQL / BIG DATA v1 NO SQL / BIG DATA v2 MOBILE SECURITY Qualify the Backlog You can add backlog items for technical debt and quality-related architecture work… yes, you can
  27. 27. 6/4/2017 27 Make Architecture Work Visible and Explicit http://philippe.kruchten.com/2013/12/11/the-missing-value-of-software-architecture/ Visible FeatureVisible Feature Invisible Architectural Feature Invisible Architectural Feature Visible DefectVisible Defect Technical DebtTechnical Debt Color your backlog—Phillipe Kruchten Positive Value Negative Value Visible Invisible Plan a Sprint Product Envisioning / Roadmap Product Envisioning / Roadmap Deploy to Stakeholders Deploy to Stakeholders Functional Acceptance Testing Functional Acceptance Testing Develop and Manage the Backlog Run a Sprint Daily Review Incorporate Feedback How Quality Fits Into An Agile Process Identify: Architecture Risks Key Quality Scenarios Landing Zone Criteria Can Include Quality Items Quality Testing Quality Testing Include relevant quality tasks
  28. 28. 6/4/2017 28 Test Driven Development Test Driven Development
  29. 29. 6/4/2017 29 VALUES DRIVE PRACTICE CALL TO ACTION Daily Practices Sustainable Development (CC) by muffinn on Flickr Visibility Visibility “We are uncovering easier ways of developing valuable products by doing it and helping others to do it. Through this work we have come to value:”
  30. 30. 6/4/2017 30 Lazy Manifesto Keeping slack over being busy all the time Small high quality software over large complex software Doing only what is necessary over exhaustively discovering all tasks Doing less to deliver the same over doing more to deliver less “We are uncovering easier ways of developing valuable products by doing it and helping others to do it. Through this work we have come to value:” That is, while there is value in the items on the right, we value the items on the left more… Harada Kiro Relaxed Principles of Lazy Manifesto Doing nothing is always an option. We seek to minimize the number of backlog items while keeping the value of the backlog. We believe to keep increasing velocity is not always good. We try to eliminate tasks that generate no value. We try to combine tasks to reduce latency and rework. We try to rearrange tasks to find problems early. We try to simplify all tasks as much as possible We are not afraid of eliminating our own tasks / processes by continuously acquiring new skills / capabilities. We expand capabilities over increasing capacities. We only work hard to make our work easier and safer. We always look to get help while we provide help to others with minimum effort. We never try to add an unnecessary principle simply to match with the other manifesto :) “We follow these principles when they don’t add work:” Relaxed Harada Kiro
  31. 31. 6/4/2017 31 Dogmatic Pragmatic Synonyms: bullheaded, dictative, doctrinaire, fanatical, intolerant Antonyms: amenable, flexible, manageable Synonyms: common, commonsense, logical, practical, rational, realistic, sensible Antonyms: idealistic, unrealistic Being Pragmatic No Planning No Design or Architecture Sometimes called Agile  Lot’s of Upfront Planning Lot of Design & Architecture Traditional or Waterfall  Rough Adaptive Plan (changing) Right Balance of Design & Architecture Being Agile  Balance Between…
  32. 32. 6/4/2017 32 It is a Journey Commitment Follow-through Deliberate practices Slack Time to Improve Paying attention Continuous Learning © Can Stock Photo Inc. / jefras Joe’s cool photo goes here!!!joe@refactory.com Twitter: @metayoda www.joeyoder.com www.refactory.com Thanks!!!

×