How to Implement Good Software Development Processes with Eric Elliott

A management role in software development can be difficult to navigate. You need to keep a high-level perspective on projects while making sure they go smoothly. Eric Elliott, today’s guest on the show, believes that you need to implement coding quality practices such as test-driven development. In this episode, we talk about why software development processes such test-driven development makes an impact and why it’s important to remove bugs. We’ll also talk about how to train developers and keep them happy—and why it’s inherently important not to rush the process.

Eric Elliott has been in software development for the better part of his life. He co-founded EricElliottJS.com and DevAnywhere.io, which aim to teach developers essential software development skills. He is also the author of the books, “Composing Software” and “Programming JavaScript Applications” 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. 

Outline of This Episode

• [2:08] Eric’s background in software development
• [4:28] What’s happened in the last year?
• [6:17] Tangible benefits to reducing bugs on the front-end
• [9:34] How much time should be spent on fixing bugs?
• [11:43] What happens when you rush engineers?
• [13:35] What happens when a manager steps in
• [19:50] How to communicate with your leadership
• [25:11] What tangible things should you measure?
• [29:55] Top 3 things to do to improve quality of code
• [34:30]Measure pull requests and open bug tickets
• [40:49] Test-driven development (TDD)
• [43:50] Resources Eric recommends 

What are the tangible benefits to reducing bugs?

If you are able to reduce bugs on the front end, you spend less time fighting fires. According to Eric, “Fixing bugs is not work that’s delivering direct value to your customers—it’s rework”. Customers don’t look at your software and think being “bug-free” is a benefit. They just assume that it’s a given that there will be no bugs. 

Secondly, Eric points out that you will lose customers if you produce buggy software. Struggling client retention and turnover means you’ll have to increase your marketing budget in order to attract new business. 

It is the most expensive and time consuming part of producing software. But it is imperative to deliver a stellar product on the front end. Because, per Eric, “Every hour spent in code review saves 33 hours of maintenance”. The hardest part is understanding that this process takes time and cannot be rushed, but it is well worth it in the end. 

What happens when you try to rush your engineers?

Those in leadership positions often have to deal with pressure from higher-ups to rush a project or push a timeline. This is the worst thing that could happen, and you’ll start to see significant negative results of rushing your developers. 

Eric points out that bugs will pile up, testing will get skipped, and communication will suffer. Your team will feel like they don’t have adequate time to mentor each other, and knowledge sharing is left behind. Productivity levels will plummet. 

Even worse, your developers can reach the point of burnout—with effects that can be long-lasting. The Japanese struggle with a culture of over-working to the point that they have a coined term for people who die because of overworking—”Karoshi”. While this is an extreme example, it’s something you want to steer clear of. Pushing your team to rush will bring to fruition the opposite of what you intend. 

What is your role as a manager/leader?

Eric uses a manufacturing analogy to drive this point home:

“ There's a floor mana