Seven Deadly Sins

by Brian McElaney

In his talk "Seven Deadly Sins" at RubyConf 2019, Brian McElaney discusses the various forms of 'debt' that software projects accumulate, particularly focusing on process debt, which he argues is often more damaging than technical debt. He draws parallels between these debts and the seven deadly sins, using them as a framework to explore unproductive behaviors in development teams.

Key points discussed include:

Anger: He details how project pressures lead to unproductive reactions, exemplified by a failed project with multiple teams lacking proper coordination, resulting in requirements oversight and eventual project cancellation.
Desire: McElaney warns against unchecked ambition in teams, sharing an experience where excessive effort on a challenging feature led to burnout and project failure—not due to lack of capability, but mismanagement of team morale.
Envy: This sin highlights the risks of seeing users as outsiders. He discusses a transportation project that failed to consider user contexts, leading to alienation instead of engagement.
Gluttony: The profligate use of advanced coding patterns without stemming from user needs can create compatibility issues within a project. He stresses the importance of cohesive processes.
Greed: Focusing on cost-cutting measures can lead businesses to miss value-adding opportunities, asserting the need to balance cost and quality in development.
Pride: McElaney points out the dangers of over-reliance on fast developers, where their isolated contributions can create knowledge gaps in the team, underscoring the need for collaboration and code reviews.
Sloth: He emphasizes the importance of strategic decision-making and architecture planning during software development.

In closing, McElaney encourages teams to build processes that allow for collective reflection and realignment toward user needs, relational dynamics in projects, and healthy developer engagement. He emphasizes that by recognizing and naming these debts, teams can regain control of their development processes and avoid detrimental outcomes.

00:00:11.860 All right, I want to thank everybody for coming today and for coming to see me specifically. I hope everyone's RubyConf has been as great as my RubyConf has been.

00:00:18.560 This has been one of the more exciting conferences I've had a chance to be a part of recently. My name is Brian McElaney. I'm the Senior Vice President of Technology at Think Company, a user experience design firm in Philadelphia.

00:00:26.330 We have a lot of business-minded designers, developers, and project managers working on things like design systems, product design, and more. I'm not here to talk about my time at Think Company; most of the stories I'll tell today are about my early days as a development lead.

00:00:37.010 These are decisions that seemed like good choices at the time but didn't work out the way I thought they would.

00:00:43.520 I should mention that I'm going to name one company today; for the rest, I'm trying to obfuscate a bit. However, nothing I'm going to say today should wow anybody. These are things that we all sort of experience.

00:00:49.880 The goal of this talk is to start forming a vocabulary around these matters so we can name them and take back some power over them. I should also ask that you please bear with me; this is kind of a terrifying talk to give because I'm discussing seven of my biggest blowups as a dev lead.

00:01:11.509 When I use words like 'we,' 'us,' or 'they,' keep in mind that I was a key part of all these decisions. I'm not trying to disown any of that.

00:01:18.109 I've had a unique career as a developer, working in many different contexts in the industry. I've worked as a consultant, where people sold my time. I've been in product companies, where people sold the things that I created, and on internal teams—it's kind of like overhead to the workings of the business.

00:01:31.909 I've been involved in wildly overfunded and wildly underfunded projects, in giant enterprise organizations and tiny little nascent startups.

00:01:37.069 Throughout all of that, we found ways to make software go wrong. It seems that none of those factors really matter when it comes to making things succeed.

00:02:00.079 Let me tell you a story about a project that didn't succeed but was one that I learned a lot from. I was working for a motorcycle parts and apparel firm called Rozilla.

00:02:06.229 We merged with another company, and we were trying to figure out how to iron out their e-commerce experience with ours. We realized that their giant enterprise e-commerce platform was just never going to do what we wanted it to do.

00:02:24.480 So, we decided we were going to build a new one from scratch. Furthermore, we decided to do it in a programming language that none of us knew, using a functional programming paradigm, while I was from an object-oriented background.

00:02:31.859 I got sick and ended up in the hospital for several months. When I came back, I coded on painkillers for a while afterward.

00:02:37.829 I was one of the leads on this project, but when another lead quit, everything was kind of stacked against us.

00:02:44.489 We hit deadlines, and during a one-on-one with the CTO, he asked me how I felt about the project. I told him it was horrible—a giant pile of bugs and tech debt that we were calling software. It couldn't be launched.

00:02:57.629 The CTO responded by asking about security problems. I said I wasn't aware of any, and then he asked about performance and memory leaks. I assured him that we were good there.

00:03:09.000 Finally, he said, 'You know what? This is just tech debt. This is how people want software. It's fine—hit the button.' So, I hit the button, launching the largest amount of tech debt I ever knowingly placed into production.

00:03:16.379 Here's the thing: I was both right and wrong. What he saw, and I couldn't, was that if I wanted two more weeks to make this better, that was really what I was asking for. He recognized that the increase in revenue from switching from the old platform to the new one would justify doubling the size of the dev team and spending six months refactoring the software.

00:03:31.909 He was able to see the business impact where I couldn't; I was only focused on tech debt, which can destroy the experience I had on many projects. In the years following this experience, I realized that a 10,000-line method is easy to point out and say this is bad for my codebase, or a big pile of tangled statements is similarly easy to identify.

00:03:51.989 But I don't think they've ever destroyed a project if you define failure as the product never seeing the light of day. However, I have seen projects fail to achieve what they aimed for.

00:04:03.569 What I realized was that not all project failures are due to tech debt—process debt has killed most projects I’ve been involved in that didn’t succeed. Debt works like friction: you don't stop a train by applying a ton of pressure to one wheel; you stop it by putting little bits of pressure on many wheels.

00:04:15.930 Over time, that will grind the behemoth to a halt. So we’re talking about these little things. They might not be dangerous to a project on their own, but if left unmanaged, they have the potential to stop a project from launching.

00:04:28.770 We're discussing this through the lens of the seven deadly sins—not as a religious talk, but as a lens for understanding unproductive behaviors in teams. We'll talk about each of these in turn, with a story that goes with each one.

00:04:43.940 First up is anger. Anger is a strong or hostile reaction to a perceived slight, and the term 'perceived' is important here. These slights don't have to actually be real; we face many pressures on projects, such as budget pressures, time pressures, and prestige pressures.

00:05:01.039 We want our clients, customers, and stakeholders to think we are on top of our game. All these pressures can create friction that eventually grinds us down.

00:05:12.440 Years ago, I was part of a project with a major reinsurance company. We needed a BI tool to evaluate risk over time and had six teams involved: a data cube team, a data science team, two app-tier teams working on various parts of the business logic, my team for front-end and data visualization, and finally, the SharePoint team.

00:05:30.979 We realized we needed to move faster than our collective efforts allowed and decided to work in our corners, agreeing on contracts and APIs in isolation, planning to integrate later. Many of you may have heard the common fallacy that integration would only take three days—so I went away for six months.

00:05:52.960 When I returned, I stepped into the client's office, and within the first hour, three developers from other teams asked me to review their resumes. I knew something was wrong and started looking into it.

00:06:08.060 What I found was a requirement everybody missed: a t-shirt sizing for risk. This required an understanding of various geo-locations, and the concept of t-shirt sizing was never going to work without someone overseeing those requirements.

00:06:20.960 Project went over budget for two years before the client finally killed it and moved on to buy a product that better met their needs.

00:06:30.640 This wasn't a bad call; parallel work can work, but you need someone like a conductor in the orchestra to keep track of everything happening. Without that person, you lose coordination, leading to coordination debt.

00:06:44.270 An object lesson for my team is dragon boating, which is an interesting sport that requires 20 people to paddle in unison. If one person tries to paddle faster than everyone else, the boat slows down.

00:07:02.640 In software, this matters because by the time you realize a developer has done the wrong thing, it's usually too late. The code has already been written, and at best, you get churn, depending on how large the issue is.

00:07:20.300 I love this quote by Seymour Cray: "The trouble with programmers is that they can never tell what a programmer is doing until it's too late." In a way, this is like Schrödinger's scope; any task in a project is infinitely large and small until you actually do it.

00:07:37.730 This is why in agile methodologies, we talk about points instead of hours. Velocity is what matters, not necessarily how long something takes.

00:07:50.920 So how do we get around this? We need to get in sync. We need to share priorities, values, and communication systems. This isn’t about tools like Slack or Confluence; it’s about understanding.

00:08:00.130 I recommend visual feature documentation because it’s easy to misunderstand prose, especially with team members coming from different backgrounds and cultures. Iterative prototypes help too—moving from design to code as quickly as possible, and hopefully placing that code in front of actual users.

00:08:16.700 Having well-documented APIs, as discussed in TV McMinn's talk on awesome APIs, ensures continuity and understanding. North Star design helps keep everyone aligned as you're moving through iterations.

00:08:29.840 Ultimately, it’s about orchestrating a process to raise and lower voices as needed to ensure we get software out the door. One other talk to bring up here is Ivan Venkov's discussion on visualizing object-oriented programming, which focuses on low-level visual documentation.

00:08:46.420 The next deadly sin is desire—a longing for fulfillment. Imposter syndrome is real, and even as I stand on this stage speaking about software development, anxiety can creep in.

00:08:56.700 Desire that isn’t managed, especially on an entire team, can result in significant damage to the business. Some years ago, I was working on an environmental reporting application.

00:09:08.420 Our stakeholders insisted on specific features regarding content governance on the project. After assessing the features, our team concluded that we weren’t sure if it was technically possible.

00:09:23.200 Thus, we reached out to contractors for their insights, and the consensus was similar: it might not be feasible.

00:09:31.230 However, we were determined and buckled down, ultimately putting in approximately 8200 hours of effort and delivering the feature. Ironically, the project never launched—this had nothing to do with our efforts.

00:09:47.000 The message here is that while hard work may seem praiseworthy, it can have detriments. Short, intensive sprints can be gratifying, given buy-in from the team, but they cannot last forever.

00:10:02.960 If your entire team experiences morale debt from overwork, you risk burnout. In the example I provided, we celebrated achieving what was initially considered impossible.

00:10:20.060 The leadership praised our dedication—employees were happy because they'd received a solution they didn’t think was possible. However, the entire team was burnt out, and we exploded every estimate for the next 18 months.

00:10:34.630 Thus, I coined the term 'morale debt': trading emotional safety in the name of delivering results. This might be tolerable during short bursts, but teams with morale debt often feel a conflict between desire and reality.

00:10:47.230 This sentiment of being worn down can stem from other sources too. Ernesto Tagwerker’s talk about 'escaping the tar pit' indicates that projects running over budget or slow shipping contribute heavily to morale debt.

00:11:04.160 Sacrificing quality to escalate tech debt can demoralize a team. Again, none of these issues when taken in isolation are inherently problematic, but combined, they create the potential for burnout.

00:11:16.780 This concept of 'hope creep' becomes prevalent when optimistic estimates aren't grounded in the reality of past experiences.

00:11:27.130 When under pressure, individuals may underestimate timeframes, especially if they lack a clear understanding of project timelines. Thus, planning more granularly is essential.

00:11:43.040 As a rule of thumb, break tickets longer than four hours into half-day tasks. Not only will this track progress, but it also allows for accurate velocity assessments.

00:12:02.420 Pair programming and mob programming helps to get developers out of isolation and counter burnout. Shipping more frequently is vital; nothing boosts morale like hearing users engage with software you created.

00:12:15.130 Furthermore, after intense efforts, the next sprint cannot return to normal; it should be managed to lessen the burden on the team. Leave some buffer days for these refactor actions.

00:12:29.050 Additionally, self-care is crucial for team health. Especially in positions of leadership, one should lead by example by ensuring a healthy work-life balance.

00:12:43.390 This brings us to envy, defined as the pain felt when noticing another's good fortune. Often in tech, developers perceive users as 'others.' This perspective detaches empathy and fosters a detachment from user context.

00:12:59.490 For instance, a large transportation agency aimed to engage a younger demographic but relied on outdated train schedules that required users to adapt instead of facilitating understanding.

00:13:16.960 I once illustrated this point to a stakeholder by highlighting the fact that people often prefer accessible methods of transport rather than wrestling with information overload.

00:13:28.200 The important lesson is: if a project team begins to see user contexts as edge cases rather than essential workflows, they risk creating a product that alienates its audience.

00:13:40.180 This danger can escalate to the extremes where engineers design solutions without considering the user experience, as evidenced by tragedies such as plane crashes due to unfathomable user interfaces.

00:13:57.230 It's imperative to have designers, product owners, and engineers aligned to ensure user contexts are critical considerations in the software's design.

00:14:16.180 Building diverse teams enhances discussions on user experience, leading to more robust solutions. Regular user validation is essential; involving developers in user testing offers insights that help them empathize with user experiences.

00:14:32.130 To conclude, the next deadly sin is gluttony, or overindulgence, particularly as a status symbol. It's not about consuming too much kale; it's about the motivation behind choices.

00:14:47.470 I once observed this dynamic in a logistics service provider where excited engineers misapplied patterns that initially felt cutting edge but ended up creating incompatibilities in a codebase plagued with 300,000+ lines of code.

00:15:06.890 While improvement is vital, it needs alignment and consistency across the codebase to avoid further friction of integration novices trying to piece disparate components.

00:15:22.120 We need processes that keep a continued evolution of good practices; this is where the team must come together to maintain velocity and share knowledge.

00:15:39.400 Lastly, resist the temptation for premature decisions; stack the relevant team members on design choices to gain insights at various levels.

00:15:52.980 Now, let’s discuss greed, which pertains to an insatiable longing for material gain—something required for business survival.

00:16:06.130 During my product consulting experience, one client claimed they lacked the budget necessary for software—yet their flawed processes cost them disproportionately.

00:16:23.420 They were losing revenue by repeatedly sending replacements for defective merchandise without tracking failures, and at once portrayed cost-cutting as a budgetary issue.

00:16:39.850 However, measuring software value cannot solely come down to cost; the value streams attached to each project affect relationships and revenue.

00:16:55.790 Achieving a balance between minimizing costs and maximizing value is essential—often requiring investment in design to optimize the path of product delivery.

00:17:09.990 We encounter a cultural tendency toward politics-oriented development, where misalignment exists in understanding software complexity and timelines.

00:17:27.300 Stakeholder communication around the value of specific development tasks is often nebulous. This underlines the importance of visual documentation to organize efforts based on business value.

00:17:55.160 In pursuing agile methodologies, we should concentrate on the velocity of getting our tasks done effectively, rather than merely completing tasks based on stakeholder perceptions.

00:18:14.250 The last deadly sin involves pride, often inflating an engineer’s perception of their ability and, sometimes, causing negative outcomes in a team.

00:18:44.850 I once worked with a remarkably fast developer, but when tasked with critical updates, they were the only one familiar with the foundational code. Their speed became detrimental to the overall team.

00:19:07.480 As updates happened, this developer lost context, and as new team members joined, they struggled to make heads or tails of what had been coded.

00:19:22.020 Every time they modified structures they deemed fit, everyone else lagged behind and became overwhelmed. This highlights the danger of letting fast developers become torpedoes without direction.

00:19:43.790 This is where the importance of code reviews becomes crucial. Not only do they act as quality control, but they also facilitate knowledge sharing amongst team members.

00:20:05.130 Creating an education-oriented culture can empower teams and deprive the toxic notions of pride from prevailing.

00:20:22.380 Finally, in pursuit of simplicity, I saw a young child replicate their parent's actions in every step toward their daily journey. This demonstrated how valuable it is to create patterns that others can easily follow.

00:20:43.460 Complexity can inhibit velocity and adversely impact development, thereby necessitating practices that promote alignment without excess.

00:21:05.360 Concluding, sloth—defined not simply as inactivity but as a lack of discernment in decision-making—emphasizes the need to exercise caution, plan diligently, and make strategic changes.

00:21:38.490 So, as a summary, consider thoughtful architecture and firm frameworks when executing in development, while simultaneously being attentive to the impacts and connections of team actions to software delivery.

00:22:14.840 I will be around at the reception after the conference and on Slack, so don't hesitate to reach out. Thank you for your time.