This document discusses seven common "deadly sins" or anti-patterns that can lead to project failure: anger, desire, envy, gluttony, greed, pride, and sloth. For each sin, it provides a definition and tells a story ("A Tale of...") showing how that sin can manifest and accumulate technical or social debt on a project. It advocates identifying and managing different types of debt proactively to keep projects on track.
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
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)
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
