Recommended
Recommended
More Related Content
Similar to Seven Deadly Sins
Similar to Seven Deadly Sins (20)
Recently uploaded
Recently uploaded (20)
Seven Deadly Sins
- 1. Seven Deadly Sins Process Anti-Patterns and Project Failure HindsightHindsight
- 2. Brian McElaney (he/him) Senior Vice President, Technology
- 3. Things Go Wrong Size, Shape, Industry, Funding, Process… doesn’t seem to matter
- 4. A Tale of Tech Debt
- 5. • Improved Conversion Rates • Massive Revenue Increase • Lower Cost • Improved Content Governance
- 6. Debt is a Good Thing Until It’s Not Debt Only Works For You When Managed Vietnam Telecom by Shawn Harquail from Flickr
- 7. Project Debts are a Friction Problem No single debt is likely to destroy a project – but friction compounds
- 8. Seven Deadly Sins • Anger • Desire • Envy • Gluttony • Greed • Pride • Sloth The Seven Deadly Sins and the Last Four Things by Hieronymus Bosch from Wikipedia
- 9. Anger Strong or hostile response to a perceived provocation
- 10. A Tale of Six Teams
- 11. Parallel Works But things need to stay in sync DSC_1735 by @usarmyband
- 12. Coordination Debt Trading clarity of communication for “speed”
- 13. Watermelon by Rafael Moreno Watermelon Effect Tasks reported as ok when inside they are not ok
- 14. Schrödinger’s Scope No one knows the cost until long after the work is done
- 15. Get In Sync Visual Feature Documentation Iterative Prototypes Well Documented APIs “North Star” Design
- 16. Get In Sync Check Out: - Ivan Nemytchenko – “Less Abstract” - Keavy McMinn – “Principles of Awesome APIs”
- 17. Desire Intense longing for a fulfilling of emotion
- 18. A Tale of Impossible Tasks
- 19. Some Efforts Require Extra Effort You Don’t Sprint Triathlons 140504-M-QH615-097 by @DOD
- 20. Glorifying Martyrdom “But for some, ‘hustle’ is just a euphemism for extreme workaholism.” -- Dan Lyons “In Silicon Valley, Working 9 to 5 is for Losers” (NYT 2017)
- 21. Morale Debt Risking Emotional Safety in the Name of Shipping
- 22. Ernesto Tagwerker :: Escaping The Tarpit
- 23. Hope Creep Allowing Aspiration Estimates to Hide the True Cost of an Effort Popular Meme: Original Source Unknown
- 24. Plan More Granularly Pair/Mob Programming Reduce Planned Velocity Ship We do pair programming in the class by Brandon Carson from Flickr
- 25. Go Home We do pair programming in the class by Brandon Carson from Flickr
- 26. Envy Pain at the sight of another’s good fortune
- 27. Ignoring Real World Workarounds
- 28. Limit Scope We Can’t Make Everyone Happy Macaroons by Olga Khomitsevich from Flickr
- 29. Empathy Debt Training Teams to Think of Real-World Users as Stress Cases
- 30. Context Is More Than Just Permissions
- 31. Build Diverse Teams Build User Validation in to Schedule Devs Participate in User Testing Meet Your Users
- 33. Tale of The Next Great Thing
- 34. Always Be Improving Great is Almost Always Iterative Pecan-smoked Chocolate Tarts w/jalapeño jam - photo and plating by @krooooop
- 35. Velocity Follows Patterns Avoid Mismatches
- 36. Contentment Debt Always Reaching for the Next Best Tool
- 37. Define Patterns and Stick To Them Leave Refactor Time Bring Entire Team in on Architecture Find Your Patterns
- 38. Breakfix Satisfies A Ticket Resolves a Code Smell Introduces New Architecture Young’s Hierarchy of Pull Requests
- 39. Greed Inordinate or insatiable longing for material gain
- 40. A Tale of Saving Too Much
- 41. Cost Cutting Not the same as making money
- 42. Politics-Oriented Development “Why Can’t We Just” feature planning
- 44. Prioritize Business Value Measure Impact Stay Agile Stay Lean
- 45. Pride Irrationally corrupt sense of one's personal value Peacock by Mathias Appel from Flickr
- 46. Tale of the 10X Engineer
- 47. Fast is Great Every relay race has an anchor 2015 Inter-Agency Games by ITU Pictures
- 48. It’s Not “Brave” To Embrace Anti-Patterns Fast Context Changes Bad Behavior Code Review Exemptions
- 49. Show Your Work Code Reviews as Education Education-Oriented Culture Value Simplicity
- 50. Easy Enough For All Processes should be repeatable by everyone on the team
- 52. It’s Not About “Slow” “Don’t Move Faster Than The Speed of Good Ideas” -- @MrkPlt
- 53. A Tale of Orientation Debt A Plan Without a Goal
- 54. It Can Be OK to Cut Corners to Hit a Budget
- 55. When it’s a Problem Putting off the wrong decisions Exclusive focus on short term cost Popular Meme: Original Source Unknown
- 56. Move With Purpose Tackle Biggest Risks First Continuous Refactor Defer Hard to Change Decisions
- 57. In conclusion
- 58. Thank You Slack: Mac @ RailsConf2019 Mac @ PhillyDev Company: @ThinkCompany Twitter: @McElaney Instagram: mac_in_philly
Editor's Notes
- Think Company business-minded designers and developers with expertise in: Evidence-based design Software development Design systems & operations
- I've had - employers who sold my time - sold products I worked for - saw me as "overhead" Didn’t matter whether projects were well funde Projects fail for the same kinds of reasons END ~ 1:48
- 2016 Comoto Buys Cycle Gear Kicked off project to replace a Large Scale Enterprise Commerce System - Decided on Elixir - set a deadline - None of us knew the language or FP - I ended up taking three months off. The DBA quit. The week before CTO asked me what I thought. “This is a bad idea” He pointed to tech debt and ordered the launch
- Here’s the thing -- I was wrong. Accepting the debt Provided opportunity to refactor Funded a sizable team expansion Lessons learned rebuilt other systems In the end - amazing software
- But here is the other thing... I also wasn't wrong We accepted massive amounts of technical debt …And had to pay it off More expensive while in production Constellation of Pain
- You don't stop a train all at once – small pressure across lots of wheels Not are project debts are technical
- Anger: Strong Response to a Perceived Provocation Desire: Longing for Fulfillment Envy: Pain at the site of other's good fortune Gluttony: Indulgence as a status symbol Greed: Insatiable Longing for Material Gain Pride: Corrupt sense of personal value Sloth: Acting without care END ~4:12
- Not one comes up between individuals on project often Not in a sustained way Projects large enough multiple teams - each experiences Prestige Pressures Budget Pressures Unless Key Stakeholder Mediates - Fireworks
- One of Largest Re-Insurance Companies – BI Platform to access risk Six separate teams working in parallel – my team (data viz) on pause "We'll integrate in 6 months” When I returned my team discovered a major problem. A known-unknown was in the project – every team decided it was someone else’s problem Project set back four months – ran out of budget and failed to release for two years.
- We took a services-approach to design with (relatively) well-defined contracts… this should have worked™ The issue wasn’t in the contracts – everyone read the requirement differently Multi-team projects need a product owner acting like a conductor Even if everyone is playing the same tune – a central figure needs to adjust speed and volume
- Dragon Boating - Speed is not about how fast you paddle Pull Strong, Pull in Unison – one row moving faster then the rest slows the boat down Shared understanding Shared resourced Shared Goals The goal is agility more so than speed
- Thin layer of “green” but big messy red center
- Best case Feature Misalignment Worst Case Outright Failure
- The tools are not the answer. Confluence and Slack are not the answer. Shared understanding is the answer ~ 8:24 mins
- The tools are not the answer. Confluence and Slack are not the answer. Shared understanding is the answer ~ 8:24 mins
- Imposter Syndrome is real Overcoming it often involves unhealthy choices We want our teams/products to succeed We want to be praised for our work We want job security We don't want anyone to know we are a fraud
- Environmental Reporting App - Sophisticated content governance As far as we knew the tool was not technically feasible Hired contractors - got the same answer 4 devs * 10 weeks of overtime We ended up achieving the feature on time but the project never launched
- We work in an industry that often requires extra oomph at times Every long-distance race is going to have hills This can be ok – in fact it can be super exciting with buy-in But it has to treated as a wind sprint… The problem in this case wasn’t the asked effort
- We were thanked - we celebrated Management bragged about our dedication We bragged about our win A entire high performing team burnt-out - missed every deadline for the next six months
- We failed to manage the morale debt of pushing that hard for that long
- This doesn't always come from overwork Long running tasks Or sustained lack of definition Sometimes has NOTHING to do with work Still a real problem with real financial costs Projects running over budget Taking forever to ship small changes Sacrificing quality, increasing tech debt
- Hope Creep Allowing Aspiration Estimates to Hide the True Cost of an Effort Bad morale leads to aspirational thinking We convince ourselves things will go fast - fail to break work down properly Tasks start taking longer Panic-driven Development Things go out of control
- People who are burnt out typically fail to operate as well burnt out Need to prevent the risks and give time to recover ~ 12 Mins
- People who are burnt out typically fail to operate as well burnt out Need to prevent the risks and give time to recover ~ 12 Mins
- Labeling users "favorite" and "not favorite" Often tied to seeing users as "others" We figure we know the domain - This is crazy common assumption No such thing as “perfect” – at best “temporary best”
- Working for a large regional transportation agency Project to improve route finding Employees intimately understand Time tables Vehicle IDs Stakeholder wanted to educate users – not redesign Even power users had workarounds new users had no access to enroute Could not understand why the system should change Highlighted version with sticky notes ON HIS DESK
- We need to draw a line Infinite possibilities Limited time and resources This is about HOW WE THINK not WHAT WE DO All members of the team need to be able to see our work through the eyes of our users
- Users and contexts are not edge cases - workflows are edge cases We need to embrace idea that the users are THE reason for our software Any roadmap leading away from users going to the wrong place
- Accessibility/Internationalization - Low hanging fruit Easy to understand that autoplay video can cause seizures "We'll never sell this overseas" has always been a lie Applies to other business cases "They will learn it” without validation "We can just train the users" "They aren't our customer"
- 1st - Add more variety to the voices creating your software Aaron Aldrich – community manager @ ElasticSearch Diverse teams - longer to form consensus but decisions stand the test of time -- catch more blindspots before user do 2nd Validation shouldn’t stop during design time --- Validate quant with qual – test with users in production 3rd - Get devs involved in UX research -- preferrably asking questions -- at least taking notes End 16:12
- None of us want to feel left behind We'll work crazy hard to experience the newest framework important to identify when we're doing that to show off rather than to improve our code
- Logistics Service Provider High turnover in architect role Each bungie boss wanted to make their mark A least a dozen major architecture patterns - high coupling low cohesion Changes often meant crossing contexts - Code shaped based on where it lived so decide to add _MORE_ new or just copy what was already there
- I don't subscribe to "great is the enemy of good" Great is great It takes time - innovation often means being imperfect before you're right When I started cooking competitively I destroyed probably a dozen briskets before I figured it out. I needed to get the basics down before I started innovating on things like making desserts for bbq competitions
- The boot might in fact be the better shoe for a hike - but unless I have the time to change both shoes it really won't matter. When we iterate on software patterns – we accrue debt until we reflect the pattern everywhere The expiration of trying a new pattern is important… pull it out or push it everywhere
- Our goal - day to day - shouldn't be to write the best possible code Our goal should be to write the most malleable code – most maintainable code New for new’s sake is like decorating with designer corks - I guess... but it misses the whole point When it comes to architecture “Same is Better than Better”
- READ SLIDE
- Sometimes we get so wrapped up in the money while building systems we forget to make money
- Large retailer warehouse Customer Service couldn't see warehouse vice-versa Found out customers receive bad product, return, caused auto-re-ship sent more bad product Bad batches not seen in system - handled by sticky notes System integration wasn’t considered worth the cost because of IT budgets losing hundreds of thousands in logistics errors
- Can't make IT cost the only metric -software cost does NOT pay for software Need to focus goals on the value being provided 60% of projects fail - worry about finishing ACIEVING YOUR GOALS AT LEAST as much as cutting costs Especially problematic when the business doesn’t understand it’s relationship with the software lifecycle
- Often we choose political simplicity over velocity and profit We need to manage up but the work stream is probably not the place to do that Don't adjust estimates to get someone off your back Don't base ticket sizes on the least technical person's ability to understand the work Focus your communication with the business on impact to bottom line Managing to politics is why most teams don’t actually practice agile
- I understand that we can't spend money forever Too often not spending money is called agile Agile doesn't mean paint the easy half of the wall Painting the lower half of the wall doesn't tell up what the upper half costs Need to orient our projects toward achieved goals
- Create the cheapest artifact - go straight from the whiteboard or paper prototypes to code Test it with users Write complete features Validate the features Improve while adding features Huge proponent of approach to agile proposed in LeanUX End 24
- We all need a personal sense of value - keep it in check
- Product Company - super crazy prolific dev lead 3rd Iteration of main product line - written by one developer Constant code changes in the name of improvement Near impossible to teach the system to junior developers
- Talent and experience are important to success – but software is a team sport. Like Jess Kerr mentioned in her keynote – at some point that additional capability needs to be focused on others
- Patterns exist to prevent us from becoming clever afraid to be critiqued? More expensive than slow These problems get exponentially worse over time The longer it lasts the harder it is to fix
- Some aspects need encouraging Experimentation is important Some specialists will work at a level peers can't understand If in startup mode - where time to market is crazy important - can be instrumental
- Maintainability comes from predictability No pattern should be so dense you junior-most developer can't learn it Code review is way more than finding defects - teach those around you End 27:36
- Last One In this context - making decisions without appreciating the consequences In fact slow can be a good thing
- The boot might in fact be the better shoe for a hike - but unless I have the time to change both shoes it really won't matter. But we do need to try on new shoes - probably on a regular basis
- Heathcare Product Company Monitoring system for hospital equipment Seven year long project - industry changed twice in that time Rebuilds layered on rebuilds every 18 months for as long as I payed attention Every iteration had a different set of goals - we were rudderless
- Get the hard to replace parts solved first don't make temporary code look permanent End 30
- Make decisions in the right order Decide where the windows go before you lay out your rooms Work from the user back - focus on workflows and clean APIs Don't try to decide the structure of the database before we know whether we even need a database
- Some aspects need encouraging Experimentation is important Some specialists will work at a level peers can't understand If in startup mode - where time to market is crazy important - can be instrumental
- Be intensional