What the New York Giants Can Teach Us about Software Quality

by

As we all know, Sundays are for football, and this past Sunday brought some choice matchups. Although I am a devout fan of the New England Patriots, one of my favorite games paired the undefeated Green Bay Packers, led by quarterback Aaron Rodgers, and Eli Manning's New York Giants. Tied with less than two minutes to go in regulation, Rodgers did his best Tom Brady imitation, leading his team on a spectacularly engineered drive that preserved their as-yet unblemished record.

After the game, I wondered if Giants Head Coach Tom Coughlin repeated his prior week's answer to reporter’s question, where he stated that his staff had prepared the team, but the team hadn’t delivered. It also made me think more about technical debt and the question I posed (and hopefully answered) last month: “Is there a technical tipping point?

Then, I read Gartner analyst David Norton’s post on technical debt, where he quotes his colleague Andy Kyte as predicting technical debt will top $1 trillion within the next five years. Norton states, “that’s a trillion dollars of development that needs to be done to remove bad code, poor architecture, and ill-thought-out technical strategy or simply time catching up with good design.”

As I dug into this more, I came across an excellent presentation from Thomas Sundberg of Sigma Software, which he presented at the Agile Sweden 2009 conference. While it’s two years old, it really got “into the weeds” about the causes and results of as well as potential solutions for technical debt. I thought it would be worthwhile to share a few of his key points here.

Line of Scrimmage: The Causes of Technical Debt

With increasing turnover of IT teams and outsourcing software development, it’s critical that developers are educated in the domain and that there’s a process in place to retain information. In many organizations, each time there’s a staffing change, knowledge is lost. Sundberg asks, “if you don’t understand the problem you need to solve, how can you solve it?”

He adds that given an environment of continuously changing talent, teams should always verify their assumptions and these should be stated as clearly as possible as part of the planning and ongoing communications process. “Incorrect assumptions are the mother of all f**k ups,” he notes.

Another contributor to additional technical debt is premature optimization. Premature optimization can cause developers to optimize the wrong feature, resulting in code that isn’t used, an incorrect solution or a solution with unnecessary complexity – all a waste of time and resources.

The Game Plan: Dealing with Technical Debt

Sundberg offered a host of ideas to reduce technical debt. I realize several of these are elementary, but in the bustle of meeting everyday objectives, several of these practices can easily fall by the wayside.

Team communication is critical, especially when development is spread out between in-house and outsourced talent.  Managers must identify team rules and stick with them, discuss the pros and cons to each solution and then choose one approach and stick to it as long as it makes sense. This may sound easy, but when developers create their own rules and generate different solutions to similar problems, they waste time and resources.

Sundberg notes that when teams fall into technical debt, they should plan immediately for how that debt will be repaid, but the debt doesn’t have to be repaid immediately. He pushes for teams to have a plan that pays it down at a sustainable pace, but is adamant about identifying the debt and creating a roadmap for paying it off.

Managers should consider paired programming to avoid the knowledge drain that occurs when staffing changes.  This approach can result in better code development, including knowledge and experience on a given task from two developers versus one, while also ensuring that institutional knowledge stays within the organization.

Managers should think about test-driven development (TDD), which encourages developers to solve a problem twice, and then work with the optimal of the two solutions.  Sundberg notes this can result in at least the doubling of code quality.

Sundberg continues that living with small errors will eventually lead developers to accept larger ones, building in technical debt in the process. The first time a developer says, “I’ll fix that later,” he/she is creating new technical debt.

Ensuring there’s discipline in the refactoring process will help wring out technical debt as well. Sundberg encourages developers to run all tests, seek out the simplest solutions to fix problems, then run all tests again and only when all tests pass should developers run checkin. Sticking with this approach will decrease technical debt.

The Goal Line: Solutions for Technical Debt

Sundberg notes a five-step method to reduce technical debt:

  1. Change the working environment, since technical problems are often symptoms of process programs
  2. Continuously strive for greater knowledge
  3. Refactor relentlessly
  4. Visualize technical debt as specific tasks to address to help the process of reducing it
  5. Automate testing, having computers test everything as often as possible.

Finally, Sundberg concludes by commenting that you pay down technical debt the same way you eat an elephant – one bite at a time. Such simple ideas could spell the winning formula for reaching state of reduced reduced technical debt and optimal structural application quality - the "Super Bowl of Software."

Get the Pulse Newsletter  Sign up for the latest Software Intelligence news Subscribe Now <>
Open source is part of almost every software capability we use today. At the  very least libraries, frameworks or databases that get used in mission critical  IT systems. In some cases entire systems being build on top of open source  foundations. Since we have been benchmarking IT software for years, we thought  we would set our sights on some of the most commonly used open source software  (OSS) projects. Software Intelligence Report <> Papers
In our 29-criteria evaluation of the static application security testing (SAST)  market, we identified the 10 most significant vendors — CAST, CA Veracode,  Checkmarx, IBM, Micro Focus, Parasoft, Rogue Wave Software, SiteLock,  SonarSource, and Synopsys — and researched, analyzed, and scored them. This  report shows how each measures up and helps security professionals make the  right choice. Forrester Wave: Static Application Security Testing, Q4 2017  Analyst Paper
This study by CAST reveals potential reasons for poor software quality that  puts businesses at risk, including clashes with management and little  understanding of system architecture. What Motivates Today’s Top Performing  Developers Survey
Jonathan Bloom Writer, Blogger & PR Consultant
Jonathan is an experienced writer with over 20 years writing about the Technology industry. Jon has written more than 750 journal and magazine articles, blogs and other materials that have been published throughout the U.S. and Canada. He has expertise in a wide range of subjects within the IT industry including software development, enterprise software, mobile, database, security, BI, SaaS/Cloud, Health Care IT and Sustainable Technology. In his free time, Jon enjoys attending sporting events, cooking, studying American history and listening to Bruce Springsteen music.
Load more reviews
Thank you for the review! Your review must be approved first
Rating
New code

You've already submitted a review for this item

|