The Hardest Part of Being a Software Manager
This post is part of the Managing Software series.
Next >
The hardest part of being a software manager is understanding that software takes the time it takes, and rushing it will slow it down and make it buggy. Patience is everything.
I know what you’re thinking. You have to finish your product in time for Black Friday, right? Or find product/market fit before the startup runway runs out? I feel your pain, but don’t make it worse on yourself. What you need to understand about software is that slow is smooth and smooth is fast.
Patience will help you move faster. Not just a little faster, but much faster. I once worked for a company that sold products through a custom shopping cart. Developers on the team lacked training and support, and a lot of the code they produced was buggy. About 40% of all commits were bug fix commits, many files had over 50 commits, meaning that it wasn’t right the first time. The code had to churn again and again before it was production ready. On average, a file needed more than a dozen changes before we could safely ship it to customers. We spent nearly half of our time on rework, and we had almost as many full time quality assurance specialists as we had engineers.
By slowing down, investing in training, and following a better quality process, we could have shipped working code considerably faster and spent more of our headcount building more value with software engineers instead of fighting fires with QA.
In manufacturing, assembly lines jam when work product piles up at any point in the assembly line. Work doesn’t continue until those jams get cleared. If the system jams, the last thing you want to do is try to push from the start of the assembly line. That makes the situation worse.
In manufacturing, that’s common sense, but when engineering managers detect a slowdown, the default strategy is to push developers to move faster instead of first fixing the jam.
Engineering managers usually lack visibility into the software development process and have misunderstandings about why things are slower than they expect. Instead of listening and observing and developing an understanding of the process, culture, and situation, they push harder and make things worse.
When you rush developers:
- Mentorship & reviews halt
- Bugs pile up
- Tests get skipped
- Communication suffers
- Developers burn out
- Productivity suffers
Tip: Do you measure your defect commit rate? Count the number of total commits and the number of commits that close bug tickets. If a file has 51 commits and 14 of those are bug fix commits, your file has a
(14/51) * 100 = ~27%defect commit rate. Average the defect rate across all files, and you have a relative bug density metric you can use to track improvement over time to evaluate your quality efforts.To do this accurately, you’ll need to mark all bug related issues with a “bug” tag so you can distinguish them, and then link commits to the tickets they’re related to. GitHub makes that process easy. A typical source file should have a low number of commits (i.e., single digits), and a near zero defect count. Most codebases have hotspots where commit numbers and defect rates are much higher per file. If those files have recent commit activity, you should consider improving unit test coverage and refactoring those files.
The Worst Thing to Do
Many studies have found a link between happiness and productivity. In “Happiness and productivity: Understanding the happy-productive worker” (Daniel Sgroi, 2015), experiment participants were given “happiness treatments” and tasks to perform. The recipients of the happiness treatments were 12% — 20% more productive than the control group. “Do moods affect programmers’ debug performance?” (Iftikhar Ahmed Khan, Willem-Paul Brinkman & Robert M. Hierons, 2010) found that programmers were better at debugging when they were in a good mood.
According to “On the Unhappiness of Software Developers” (Daniel Graziotin, Fabian Fagerholm, Xiaofeng Wang, Pekka Abrahamsson): The top causes of developer unhappiness were:
- Being stuck in problem solving
- Time pressure
- Bad code quality and coding practice
A 2016 survey by Stack Overflow found that “unrealistic expectations” was the #1 challenge faced by developers at work.
Pushing harder is going to make all of those worse.
The worst thing you can do when productivity drops is to bring developers into meetings for motivation-draining “performance review” to discuss their struggles. Those meetings are the fastest way to destroy a programmer’s mood and motivation, and often lead directly to resignation.
Praise in public, offer improvement suggestions in private. Never chastise individual developers in group meetings.
Don’t reprimand employees you want to keep. Because of their motivation destroying effects, reprimands should only be used if mentorship and support have already failed.
Frequent 1:1 meetings are a great alternative to get insights into the morale and thinking of your development team without making it feel like a scary disciplinary meeting. Meet with each of your direct reports monthly, and use those sessions to learn from their insights. Don’t think of it like a performance review or discipline, but the chance to connect with people, listen, offer support, mentor, and share.
Listening is key. Done right, those meetings are your opportunity to demonstrate that you are there for them if they have questions, ideas, or frustrations blocking their progress. Developers need to progress in three ways:
- On the project they’re assigned to.
- In their skills as a developer.
- In their career.
By understanding and supporting the goals of the members of your team, you can keep them highly motivated and highly engaged. Highly motivated, highly engaged developers are far more productive.
When developers are stuck, they don’t need reprimands. They need support. Do your developers feel supported? Do they have a safe cultural environment to ask questions and learn from each other? Do you practice code review so that developers have an opportunity to support each other with opportunities for code quality improvements? Are developers working within the constraints of hard deadlines and being pushed to meet those deadlines, even if that means cutting corners?
Instead, tell developers that they should ship as quickly as possible, but not at the cost of cutting corners, skipping unit tests, or building excessive technical debt (i.e., the next production jam clogging your team’s overall productivity). If they can’t meet a hard deadline, they should raise the issue with the product team and discuss priorities and possible scope cuts.
Empathy for the developers on your team is the best way to show them that you care about them as people, and not just about the money the company earns from their work.
The Cost of Moving Too Fast
Slowing down is not just about moving fast. It’s also about shipping a quality product. The economic consequences of shipping a low quality product are difficult to overstate, and the costs of bugs can be catastrophic.
The Boeing 737 Max
On October 29, 2018, Lion Air Flight 610, a 737 MAX 8 flight from Jakarta, Indonesia to Pangkal Pinang, Indonesia, crashed into the sea 13 minutes after takeoff, killing all 189 people aboard. Investigations into the cause of the crash revealed erroneous activation of commands from the Maneuvering Characteristics Augmentation System (MCAS) — a software system designed to compensate for airframe changes due to a larger engine with more weight and more drag.
MCAS caused the aircraft to pitch nose down against the will of the pilots. The problem is that those commands should never have been issued, and caused the aircraft to crash.
March 10, 2019, Ethiopian Airlines Flight 302, also a 737 MAX 8, went down under similar circumstances, killing all 157 people aboard. Flight 302 also reported erroneous nose down commands.
Boeing’s 737 MAX 8 was grounded for months, and production was halted. As of this writing (Februray, 2020), there is no timeline to lift the grounding, and orders of the MAX 8 have flatlined. Boeing planned for sales of the MAX 8 to account for 33% of the company’s revenues for 5 years.
In addition to the indescribable tragedy of losing hundreds of human lives, errors related to the 737 MAX have cost Boeing tens of billions of dollars.
The Boeing Starliner Capsule
Boeing made the news again for multiple bugs in the Starliner Capsule software designed to transport crew to the International Space Station, leading to the failure of the Starliner’s first crewless mission.
One of the bugs caused the mission clock to be off by 11 hours, which tricked the software into behaving as if it were in an “orbital insertion burn” phase, consuming too much fuel. That error made it impossible to dock with the IIS as planned. The capsule’s mission was aborted, and it landed safely, but before reentry, engineers discovered another bug that affected the thruster firings needed to jettison the Starliner’s service module safely. Either bug could cause the loss of the Starliner Capsule and the lives of its crew.
Toyota’s 10k Global Variables
In 2013, a jury found that Toyota was guilty of “reckless disregard” in an unintended acceleration lawsuit, which followed a ruling which fined Toyota $1.2 billion for failing to recall the vehicles after 12 reported deaths caused by unintended acceleration.
Philip Koopman, a Carnegie Mellon University professor in computer engineering and safety-critical embedded systems specialist, testified that he found over 10,000 global variables in Toyota’s software.
Bugs Hurt Everybody
Before you breathe a sigh of relief because you produce video games or social media apps instead of cars or airplanes, know this: Bugs and other stability, usability, or access issues cost money and chase away customers, regardless of your industry.
Expenses pile up from increased demand for customer service, increased rework from bug fixes (which can increase software development costs 30% — 100%), and fewer social recommendations.
Bugs hurt your conversion rates and new user acquisition. If your users aren’t recommending you, your product growth will lose steam. You need to maintain minimum recommendation rates and minimum conversion rates (collectively known as viral factor, or k-factor), or your product will slip into exponential decline the moment the marketing spend stops.
Buggy products aren’t viral. Products that aren’t viral can only be sustained by continually burning marketing dollars to keep the product selling. Eventually, your product will reach market saturation, and sales will taper off, even while maintaining marketing spend. The result is a slow death spiral.
Viral products market themselves, and that saves you mountains of money.
Key Takeaways
- The hardest part of being a software manager is understanding that software takes the time it takes, and rushing it will slow it down and make it buggy.
- Patience is everything.
- Slow is smooth and smooth is fast.
- Engineering teams frequently spend more than half their time on rework.
- Investing in training and quality processes can help you ship faster.
- When an assembly line jams, you don’t push more product through, you clear the jam.
- Track and improve your defect rate.
- Identify rework hotspots in your codebase and fix them.
- Happy developers are more productive.
- The worst thing to do is push harder.
- Don’t reprimand employees you want to keep.
- Time pressure, unrealistic expectations, and poor code quality are top causes of developer unhappiness.
- Pushing harder makes developers slower and more likely to write bugs.
- Favor regular, supportive 1:1 meetings over “performance review” meetings.
- Listening is key.
- Support developers in their assigned work, skill progression, and career progression.
- Empathy is the best way to show developers you care about them as people, and that makes them happier and more productive.
- Bugs are extremely expensive. Low quality software can cost more than double to develop than high quality software.
- Bugs expose companies to liability and severe product delays.
- Bugs have a severe impact on product growth and marketing costs.
- Viral products market themselves, and that saves you mountains of money.
Next Steps
Test Driven Development (TDD) can save an enormous amount of rework. We recently published the TDD Day curriculum used by employees of Disney, Spotify, Netflix, PayPal, and Amazon to ship better products on a reliable schedule.
Members of EricElliottJS.com get all 5 hours of TDD training included along with access to training on JavaScript, React, Redux, and software design best practices. Buy it for your whole team. It only takes a few hour’s worth of cost savings per employee to pay for itself.
Want to pay with a single invoice? Let us know how many passes you want to buy, pay the resulting invoice, and we’ll send you a link your employees can use to activate their accounts.
Eric Elliott is the author of the books, “Composing Software” and “Programming JavaScript Applications”. As co-founder of EricElliottJS.com and DevAnywhere.io, he teaches developers essential software development skills. He builds and advises development teams for crypto projects, and has contributed to software experiences for Adobe Systems, Zumba Fitness, The Wall Street Journal, ESPN, BBC, and top recording artists including Usher, Frank Ocean, Metallica, and many more.
He enjoys a remote lifestyle with the most beautiful woman in the world.
