Overcoming the Need for Greed

by

Developing software, like almost any facet of business, often can be overtaken by some rather sinful thoughts and actions. This is why I really enjoyed a recent post on GigaOm by Magne Land, scrum master and tech lead at RightScale who compares issues within software development to the “Seven Deadly Sins.”

While Land makes a great case for each of the sins, the one that resonates the most is the sin of Greed.

Anyone who ever saw Wall Street knows that every for profit business in the world is pushed by greed. The main character, Gordon Gekko, goes so far as to say, “Greed is good.” But in the development of software, greed is not good. In fact, as Land points out:

The problem is that greed leads to short-term goals, which leads to technical debt and long-term slowness.

Forgive Us Our Technical Debt

When it comes to software, greed equals speed and as I have previously noted in this blog when it comes to software, “Speed Kills.” Nevertheless, companies seem to believe that getting software out the door faster is the financially wise move. In truth, this is probably the wrong move for long-term benefit.

As the 2011 CRASH report released by CAST in December pointed out, applications carry on average $3.61 of technical debt per line of code. Considering that 15% of the applications studied exceeded one-million lines of code, this means a significant portion of the apps studied exceed $3M in technical debt! Why any company would concede $3 million of its IT budget every year just to fix the problems that it felt were not important enough to slow down and fix the first time is beyond me…but it is not beyond those mired in the sin of greed.

Even beyond the financial concession, more than one-third (35%) of the violations identified in the report and which comprise technical debt are the types that would have a direct, significant negative impact on business. These violations fall into the areas of performance, security and robustness (uptime) of applications and provide corroboration that companies must pay greater attention to the structural quality of applications or they are likely to face very costly problems ranging from application lag time to outages to security breaches, all of which can cost organizations money and adversely affect their reputations.

The only reason any company would accept this is because of greed.

Lead Us Not Into Temptation

When it comes to technical debt, a company needs to determine how much, if anything it should put into remediating it.

This is what technical debt does – it puts a monetary figure on application structural quality and enables comparisons that were not possible before between IT costs and potential losses due to failure. The goal is to keep the number of structural quality violations – or more importantly, the cost to fix them – well below the cost the company would incur should they be deployed and a failure ensued.

The most effective and efficient route to identifying technical debt is one that evaluates the structural quality of a company’s most mission-critical applications through a platform of automated analysis and measurement. As each of the applications is built, rewritten or customized, a company measures its structural quality at every major release and when the applications are in operation, it measures their structural quality every quarter.

In particular, companies must keep a watchful eye on the violation count; monitor the changes in the violation count and calculate the technical debt of the application after each quality assessment. Once the company has a dollar figure on technical debt, it needs to compare it to the business value to determine how much technical debt is too much and how much is acceptable based on the marginal return on business value (see graphic depiction above).

Once technical debt is identified and monetized, and a determination of the tipping point is made, companies can turn that identification into an action plan that works to reduce the errors that lead to technical debt in a financially prudent manner. This leaves companies still delivering software on time, but delivering software that is far more structurally sound…and which forgives the sin of greed.

Filed in:
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
Jonathan Bloom Technology Writer & Consultant
Jonathan Bloom has been a technology writer and consultant for over 20 years. During his career, Jon has written thousands of journal and magazine articles, blogs and other materials addressing various topics within the IT sector, including software development, enterprise software, mobile, database, security, BI, SaaS/cloud, Health Care IT and Sustainable Technology.
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

|