Balancing Developer Productivity & Code Quality

Facebook
Twitter
LinkedIn

Balancing Developer Productivity andSoftware Quality

Key Insights from the World Forum Event

A panel of experts gathered virtually on November 24, 2020 for the World Forum Disrupt Data Series webinar to discuss key strategies for balancing code quality and developer productivity. It was a great discussion out of which came a number of key insights summarized here. The panel included the following speakers:

  • James Rutt (Moderator): Chief Information Officer, The Dana Foundation
  • Rahul Subramaniam: Chief Executive Officer, Dev Factory
  • Warren Lenard: Chief Information Officer, Byrider
  • Ivo Yeuh: Director of Software Development, Envision HealthCare

 

 

Studies show that nearly one-third of developer productivity is lost dealing with technical debt. The core problem is that teams are often forced to balance quality with productivity in order to ship software faster than ever. It’s time to reassess how to manage technical debt by going straight to the source. Writing high-quality code in the first place is ultimately less expensive and time-consuming. Code quality does not just start with the QA process. Instead, it needs to be addressed at the source by coaching developers how to write better code in the first place.

 

Insight #1: If you build it, you own it

Insight #2: Don’t write code unless you have to

Insight #3: Technical debt includes interest payments

Insight #4: Address quality problems at the source

Insight #5: Consider using hackathons to bring down technical debt

 

Insight #1: If you build it, you own it

 

Warren Lenard: “I eliminated the break-fix team because I felt that it was counter to releasing good quality code. We changed the philosophy: if you build it, you support it.”

 

Ivo Yeuh: “When it comes to the build or buy decision, it is increasingly more important what we choose to have our developers spend their time on.”

 

The underlying concept of ownership is captured within the DevOps philosophy. The approach motivates engineers to write higher quality code because they (or their teammates) will be responsible for maintaining it. If something breaks, they will be the ones who are called.

Quality leads not only to reduced error rates but also faster iterations in the future. Changes and additions to the system are inevitable to meet the needs of the business. The functional behavior of software typically is what determines when development is “done”, however, the structure and quality of the code can be equally as important throughout the product’s lifecycle. Engineers should work towards common architectural goals to enable the flexibility needed to meet the needs of the business on an ongoing basis.

 

Insight #2: Don’t write code unless you have to

 

You might also like:   5 Tips for Sphinx Indexing

James Rutt: “The best line of code you are ever going to write is the one you don’t need to.”

 

Rahul Subramaniam: “As a thought exercise, imagine that every line of code costs you $1,000. Would you change what lines you write?”

 

Warren Lenard: “If the ‘better widget’ won’t differentiate my company, I’m probably going to look to buy (versus build).”

Even if you write the best line of code today, it will likely accrue technical debt over the next three to five years. High-quality code in today’s context may be evaluated differently years from now given the rapidly changing technology landscape. Therefore, only write software that differentiates your business or provides key value-added capabilities.

Having performed many software acquisitions, Rahul noted It is common for 80% of a product codebase to be focused on infrastructure or support functions. Much of that functionality can now be handled by cloud providers such as AWS. For example, Fogbugz is an issue tracking system comprising 1.7 million lines of code that was initially released 20 years ago. The product was recently rewritten on top of AWS in less than 5,000 lines. A smaller codebase makes it much easier to maintain higher levels of quality.

The concept of Domain-Driven Design is something to consider as a part of your methodology. Consider the core subdomains of your business, and focus your energy on components within those areas. Consider off-the-shelf or managed service solutions for other concerns, as they don’t yield the same competitive advantage for your business.

 

Insight #3: Technical debt includes interest payments

 

Ivo Yeuh: “If you say we don’t have time to do it right, well, do we have time to do it twice?”

 

James Rutt: “Don’t write checks that your team can’t cash.”

 

When a development team takes a shortcut in order to meet a deadline, technical debt is incurred. While the shortcut is often viewed as simply deferring the original work, the total cost is actually increased further by the “interest payments” required to undo the shortcut. After that work is complete, then you can introduce the long-term desired solution.

These are important considerations for management when making decisions on whether to invest now to “get it right” or take shortcuts based on immediate needs. Some technical debt is incurred simply by the passage of time and changes in context. Design and coding decisions that made sense at the time now appear as liabilities given changes in either the technology or the business. Other technical debt takes the form of shortcuts. Although they are often taken with good intentions, consider the long-term ramifications.

 

Insight #4: Address quality problems at the source

 

Rahul Subramaniam: “We need to constantly coach developers, similar to how an athletic coach reviews exactly what happened using game film. Do this with each individual developer, and within 6-8 weeks you can start eliminating (code quality) issues.”

You might also like:   Useful Rewrites for Nginx

 

You can coach your developers to solve problems at the source (no pun intended). In addition to reviewing issues as a team, consider taking a proactive approach to quality by sitting down with each individual developer once a week. Preventing the introduction of problems at the outset can be more cost-effective than dealing with the ramifications of poor quality throughout the product life cycle.

Code quality tools can also help, however be aware that many of them output a high level of false positives. It can take significant time to wade through the results and determine where time and effort should be spent. A large codebase could have hundreds of thousands of findings on an initial scan. This is why DevGraph introduced the DevCoach product to provide meaningful insights that can dramatically improve your team’s productivity. 

 

Insight #5: Consider using hackathons to bring down technical debt

 

Warren Lenard: “We set aside time not only for break-fix and non-sprint related work, but also for hackathons per team (to address technical debt).”

 

Rahul Subramaniam: “A developer’s job is changing dramatically. Hackathons are a prime indicator of where we are headed. Developers must quickly stitch together components that are readily available to them.”

 

Hackathons are not typically viewed as an internal debt reduction mechanism, however they provide a great opportunity for engineers who continually have to deal with existing technical debt. Developers are often motivated to refactor and fix lingering issues, but other tasks often take priority. A hackathon provides not only concentrated time to focus on cleaning up the code, but also the potential for rewards and recognition by doing so. During the normal course of business, these clean up tasks may be less likely to occur.

A model used successfully by Warren Lenard is to allocate a half day for planning, and then a full day for the hackathon event itself. Lunch is typically provided which further adds to the focus and energy of the day. Hackathons offer a proven model for delivering results and also increasing team morale.

 

Looking Ahead

 

Code quality and productivity do not always have to be mutually exclusive. By focusing on quality from the start using coaching and tooling, productivity gains can be achieved through fewer defects and less time spent on rework. Deadlines will always exist, but consider carefully the total cost of ownership when making tradeoff decisions as technical debt accrues interest. Put in place a framework to build your products in a consistent manner that moves your organization towards its architectural goals. 

Want more posts like this?

What you should do now:

Facebook
Twitter
LinkedIn

Easy Application Deployment to AWS

Focus on development, not on managing infrastructure

Deploying, running and managing your Ruby on Rails app is taking away precious resources? Engine Yard takes the operational overhead out of the equation, so you can keep innovating.

  • Fully-managed Ruby DevOps
  • Easy to use, Git Push deployment
  • Auto scaling, boost performance
  • Private, fully-configured Kubernetes cluster
  • Linear pricing that scales, no surprises
  • Decades of Ruby and AWS experience

14 day trial. No credit card required.

Sign Up for Engine Yard

14 day trial. No credit card required.

Book a Demo