The Agile Executive

Making Agile Work

Posts Tagged ‘Java

How Technical Debt Ties to Cloud, Mobile and Social

leave a comment »

http://en.wikipedia.org/wiki/File:West_Side_Highway_collapsed_at_14th.jpg

Many years ago, when I came to the US, I was shocked to the core seeing the collapsed West Side Highway in New York City. I simply could not believe that a highway would be neglected to that extent amidst all the affluence of the city. The contrast was too much for me.

Nowadays I often have a deja vu sensation in various technical debt engagements in which I find the code crumbling. This sensation is not so much about what happened (see The Real Cost of a One Trillion Dollars in IT Debt: Part II – The Performance Paradox for an explanation of the economics of the neglect of software maintenance during the past decade), but about the company for which I do the assessment giving up on immense forthcoming opportunities.

Whether you do or do not fully subscribe to the vision of the Internet-of-Things depicted in the figure below, it is fairly safe to assume that your business in the years to come will be much more connected to the outside world than it is now. The enhanced connectivity might come through mobile applications, through social networks or through the cloud. As a matter of fact, it is quite likely to come through a confluence of the three: Cloud, Mobile and Social.

http://en.wikipedia.org/wiki/File:Internet_of_Things.png

In the context of current trends in cloud, mobile and social, your legacy software is like the West Side Highway in New York City. If you maintain it to an acceptable level, it can become the core of two major benefits of much higher connectivity and connectedness in the not-too-far future:

  • Through mobile and social your legacy software will enable you to flexibly produce, market and distribute small quantities of whatever your products might need to be in niche markets.
  • Through cloud it will enable you to offer these very same products and many others as services.

Conversely, if you consistently neglect to pay back your technical debt, your legacy code is likely to collapse due to the effects of software decay. You certainly will not be able to get it to interoperate with mobile and social networking applications, let alone offer it in the form of cloud services. Nor would you be able to wrap additional services around decaying legacy code. Take a look at the warehousing and distribution services offered by Amazon to get a sense of what this kind of additional services could do for your core business: they will enable you to transform your current business design by adding an Online-to-Offline (O2O) component to it.

What is the fine line differentiating “acceptably maintained” code from toxic code? I don’t think I have conducted a large enough sample of technical debt assessments to provide a statistically significant answer. My hunch is that the magic ceiling for software development in the US is somewhere around $10 per line of code in technical debt. As long as you are under this ceiling you could still pay back your technical debt (or a significant portion of it) in an economically viable manner. Beyond $10 per line of code the decay might prove too high to fix.

Why $10 and not $1 or $100 per line of code? It is a matter of balancing investment versus debt. An average programmer (in the US) with a $100,000 salary would probably be able to produce about 10K lines of Java code per year. The cost of a line of code under these simplistic assumptions is $10. Something is terribly wrong if the technical debt exceeds the cost per line. They call it living on margin.

Action item: CIOs should conduct a technical debt assessment on a representative sample of their legacy code. A board level discussion on the strategic implications for the company is called for if technical debt per line of code exceeds $10. The board discussion should focus on the ability of the company (or lack thereof) to participate in the business tsunami that cloud, mobile and social are likely to unleash.

____________________________________________________________________________________________________

Considering modernization of your legacy code? Let me know if you would like assistance in monetizing your technical debt, devising plans to reduce it and governing the debt reduction process. Click Services for details.

____________________________________________________________________________________________________

Advertisements

What 108M Lines of Code Tell Us

with 16 comments

Results of the first annual report on application quality have just been released by CAST. The company analyzed 108M lines of code in 288 applications from 75 companies in various industries. In addition to the ‘usual suspects’ –  COBOL, C/C++, Java, .NET – CAST included Oracle 4GL and ABAP in the report.

The CAST report is quite important in shedding light on the code itself. As explained in various posts in this blog, this transition from the process to its output is of paramount importance. Proficiency in the software process is a bit allusive. The ‘proof of the pudding’ is in the output of the software process. The ability to measure code quality enables effective governance of the software process. Moreover, Statistical Process Control methods can be applied to samples of technical debt readings. Such application is most helpful in striking a good balance in ‘stopping the line’ – neither too frequently nor too rarely.

According to CAST’s report, the average technical debt per line of code across all application is $2.82.  This figure, depressing that it might be, is reasonably consistent with quick eyeballing of Nemo. The figure is somewhat lower than the average technical debt figure reported recently by Cutter for a sample of the Cassandra code. (The difference is probably attributable to the differences in sample sizes between the two studies). What the data means is that the average business application in the CAST study is saddled with over $1M in technical debt!

An intriguing finding in the CAST report is the impact of size on the quality of COBOL applications.  This finding is demonstrated in Figure 1. It has been quite a while since I last saw such a dramatic demonstration of the correlation between size and quality (again, for COBOL applications in the CAST study).

Source: First Annual CAST Worldwide Application Software Quality Study – 2010

One other intriguing findings in the CAST study is that “application in government sector show poor changeability.” CAST hypothesizes that the poor changeability might be due to higher level of outsourcing in the government sector compared to the private sector. As pointed out by Amy Thorne in a recent comment posted in The Agile Executive, it might also be attributable to the incentive system:

… since external developers often don’t maintain the code they write, they don’t have incentives to write code that is low in technical debt…

Congratulations to Vincent Delaroche, Dr. Bill Curtis, Lev Lesokhin and the rest of the CAST team. We as an industry need more studies like this!

Technical Debt Assessment, Sterling Barton LLC and the Moussaka

with one comment

A few month ago Chris Sterling and I were carrying out a Cutter Technical Debt Assessment and Valuation engagement for a venture capitalist who was considering a certain company. We discovered various things in the code of this company. More noteworthy, my deep domain expertise led to Chris discovering the great Greek dish Moussaka.

I have eaten a lot of good Moussakas over the years. Even against this solid gastronomic background I can’t forget how the eyes of Chris lit up when he took the first bite. It took him only a tiny little time to get on his iPhone and tweet on the culinary aspects of our engagement. I then knew it was going to be a very successful engagement…

The relationship with Chris deepened since this episode. For example, in collaboration with Brent Barton Chris contributed a great article to the forthcoming issue of the Cutter IT Journal on Technical Debt. In this article Chris and Brent  demonstrate how technical debt techniques can be applied at the portfolio level. They make the reader step into the shoes of the project portfolio planner and walk him through their approach to enhancing the decision-making process by using the software debt dashboard.

Chris has just published an excellent post entitled “Using Sonar Metrics to Assess Promotion of Builds to Downstream Environments” in Getting Agile and was kind enough to suggest I cross-post it in The Agile Executive. Here it is (please note that the examples given below by Chris have nothing to do with the engagement described above):

“For those of you that don’t already know about Sonar you are missing an important tool in your quality assessment arsenal. Sonar is an open source tool that is a foundational platform to manage your software’s quality. The image below shows one of the main dashboard views that teams can use to get insights into their software’s health.

The dashboard provides rollup metrics out of the box for:

  • Duplication (probably the biggest Design Debt in many software projects)
  • Code coverage (amount of code touched by automated unit tests)
  • Rules compliance (identifies potential issues in the code such as security concerns)
  • Code complexity (an indicator of how easy the software will adapt to meet new needs)
  • Size of codebase (lines of code [LOC])

Before going into how to use these metrics to assess whether to promote builds to downstream environments, I want to preface the conversation with the following note:

Code analysis metrics should NOT be used to assess teams and are most useful when considering how they trend over time

Now that we have this important note out-of-the-way and, of course, nobody will ever use these metrics for “evil”, lets discuss pulling data from Sonar to automate assessments of builds for promotion to downstream environments. For those that are unfamiliar with automated promotion, here is a simple, happy example:

A development team makes some changes to the automated tests and implementation code on an application and checks their changes into source control. A continuous integration server finds out that source control artifacts have changed since the last time it ran a build cycle and updates its local artifacts to incorporate the most recent changes. The continuous integration server then runs the build by compiling, executing automated tests, running Sonar code analysis, and deploying the successful deployment artifact to a waiting environment usually called something like “DEV”. Once deployed, a set of automated acceptance tests are executed against the DEV environment to validate that basic aspects of the application are still working from a user perspective. Sometime after all of the acceptance tests pass successfully (this could be twice a day or some other timeline that works for those using downstream environments), the continuous integration server promotes the build from the DEV environment to a TEST environment. Once deployed, the application might be running alongside other dependent or sibling applications and integration tests are run to ensure successful deployment. There could be more downstream environments such as PERF (performance), STAGING, and finally PROD (production).

The tendency for many development teams and organizations is that if the tests pass then it is good enough to move into downstream environments. This is definitely an enormous improvement over extensive manual testing and stabilization periods on traditional projects. An issue that I have still seen is the slow introduction of software debt as an application is developed. Highly disciplined technical practices such as Test-Driven Design (TDD) and Pair Programming can help stave off extreme software debt but these practices are still not common place amongst software development organizations. This is not usually due to lack of clarity about these practices, excessive schedule pressure, legacy code, and the initial hurdle to learning how to do these practices effectively. In the meantime, we need a way to assess the health of our software applications beyond just tests passing and in the internals of the code and tests themselves. Sonar can be easily added into your infrastructure to provide insights into the health of your code but we can go even beyond that.

The Sonar Web Services API is quite simple to work with. The easiest way to pull information from Sonar is to call a URL:

http://nemo.sonarsource.org/api/resources?resource=248390&metrics=technical_debt_ratio

This will return an XML response like the following:

  248390
  com.adobe:as3corelib
  AS3 Core Lib
  AS3 Core Lib
  PRJ
  TRK
  flex
  1.0
  2010-09-19T01:55:06+0000

    technical_debt_ratio
    12.4
    12.4%

Within this XML, there is a section called  that includes the value of the metric we requested in the URL, “technical_debt_ratio”. The ratio of technical debt in this Flex codebase is 12.4%. Now with this information we can look for increases over time to identify technical debt earlier in the software development cycle. So, if the ratio to increase beyond 13% after being at 12.4% 1 month earlier, this could tell us that there is some technical issues creeping into the application.

Another way that the Sonar API can be used is from a programming language such as Java. The following Java code will pull the same information through the Java API client:

Sonar sonar = Sonar.create("http://nemo.sonarsource.org");
Resource commons = sonar.find(ResourceQuery.createForMetrics("248390",
        "technical_debt_ratio"));
System.out.println("Technical Debt Ratio: " +
        commons.getMeasure("technical_debt_ratio").getFormattedValue());

This will print “Technical Debt Ratio: 12.4%” to the console from a Java application. Once we are able to capture these metrics we could save them as data to trend in our automated promotion scripts that deploy builds in downstream environments. Some guidelines we have used in the past for these types of metrics are:

  • Small changes in a metric’s trend does not constitute immediate action
  • No more than 3 metrics should be trended (the typical 3 I watch for Java projects are duplication, class complexity, and technical debt)
  • The development should decide what are reasonable guidelines for indicating problems in the trends (such as technical debt +/- .5%)

In the automated deployment scripts, these trends can be used to stop deployment of the next build that passed all of its tests and emails can be sent to the development team regarding the metric culprit. From there, teams are able to enter the Sonar dashboard and drill down into the metric to see where the software debt is creeping in. Also, a source control diff can be produced to go into the email showing what files were changed between the successful builds that made the trend go haywire. This might be a listing per build and the metric variations for each.

This is a deep topic that this post just barely introduces. If your organization has a separate configuration management or operations group that managed environment promotions beyond the development environment, Sonar and the web services API can help further automate early identification of software debt in your applications before they pollute downstream environments.”

Thank you, Chris!

Forrester on Managing Technical Debt

leave a comment »

Forrester Research analysts Dave West and Tom Grant just published their report on Agile 2010. Here is the section in their report on managing technical debt:

Managing technical debt

Dave: The Agile community has faced a lot of hard questions about how a methodology that breaks development into short iterations can maintain a long-term view on issues like maintainability. Does Agile unintentionally increase the risk of technical debt? Israel Gat is leading some breakthrough thinking in the financial measures and ramifications of technical debt. This topic deserves the attention it’s beginning to receive, in part because of its ramifications for backlog management and architecture planning. Application development professionals should :-

  • Starting captured debt. Even if it is just by encouraging developers to note issues as they are writing code in the comments of that code, or putting in place more formal peer review processes where debt is captured it is important to document debt as it accumulates.
  • Start measuring debt. Once captured, placing a value / cost to the debt created enables objective discussions to be made. It also enables reporting to provide the organization with transparency of their growing debt. I believe that this approach would enable application and product end of life discussions to be made earlier and with more accuracy.
  • Adopt standard architectures and opensource models. The more people that look at a piece of code the more likely debt will be reduced. The simple truth of many people using the same software makes it simpler and less prone to debt.

Tom: Since the role I serve, the product manager in technology companies, sites on the fault line between business and technology, I’m really interested in where Israel Gat and others take this discussion. The era of piling up functionality in the hopes that customers will be impressed with the size of the pile are clearly ending. What will replace it is still undetermined.

I will be responding to Tom’s good question in various posts along the way. For now I would just like to mention the tremendous importance of automated technical debt assessment. Typical velocity of formal code inspection is 100-200 lines of code per hour. Useful and important that formal code inspection is, there is only so much that can be inspected through our eyes, expertise and brains. The tools we use nowadays to do code analysis apply to code bases of any size. Consequently, the assessment of quality (or lack thereof) shifts from the local to the global. It is no more no a matter of an arcane code metric in an esoteric Java class that precious few folks ever hear of. Rather, it is a matter of overall quality in the portfolios of projects/products a company possesses. As mentioned in an earlier post, companies who capitalize software will sooner or later need to report technical debt as line item on their balance sheet. It will simply be listed as a liability.

From a governance perspective, technical debt techniques give us the opportunity to carry out consistent governance of the software process based on a single source of truth. The single source of truth is, of course, the code itself. The very same truth is reflected at every level in the organization. For the developer in the trenches the truth manifests itself as a blocking violation in a specific line of code. For the CFO it is the need to “pay back” $500K in the very same project. Different that the two views are, they are absolutely consistent. They merely differ in the level of aggregation.

Technical Debt Meets Continuous Deployment

with 11 comments

As you would expect in a conference entitled velocity, and in a follow-on devops day, speeding up things was an overarching theme. In the context of devops, the theme primarily manifested itself in lively discussions about the number of deploys per day. Comments such as the following reply to my post Ops Driven Dev were typical:

Conceptually, I move the whole business application configuration into the source code…

The theme that was missing for me in many of the presentations and discussions on the subject was the striking of a balance between velocity and quality. The classical trade-off in process control is between production rate and product quality (and safety, but that aspect [safety] is beyond the scope of this post). IMHO this trade-off applies to software just as it applies to mechanical or chemical processes.

The heart of the “deploy early and often” strategy hailed by advocates of continuous deployment is known deployment state to known deployment state. You don’t let the deployment evolve from one state to another before it has stabilized to a robust state. The power of this incremental deployment is in dealing with single-piece (or as small number of pieces as possible) flow rather than dealing with the effects of multiple-piece flow. When the deployment increments are small enough, rollback, root cause analysis and recovery are relatively straightforward if a deployment turns sour. It is a similar concept to Agile development, extending continuous integration to continuous deployment.

While I am wholeheartedly behind this devops strategy, I believe it needs to be reinforced through rigorous quality criteria the code must satisfy prior to deployment. The most straightforward way for so doing is through embedding technical debt criteria in the release/deploy process. For example:

  • The code will not be deployed unless the overall technical debt per line of code is lower than $2.
  • To qualify for deployment, code duplication levels must be kept under 8%.
  • Code whose Cyclomatic complexity per Java class is higher than 15 will not be accepted for deployment.
  • 50% unit test coverage is the minimal level required for deployment.
  • Many others…

I have no doubt whatsoever that code which does not satisfy these criteria might be successfully deployed in a short-term manner. The problem, however, is the accumulative effect over the long haul of successive deployments of code increments of inadequate quality. As Figure 1 demonstrates, a Java file with Cyclomatic complexity of 38 has a probability of 50% to be error-prone. If you do not stop it prior to deployment through technical debt criteria, it is likely to affect your customers and play havoc with your deployment quite a few times in the future. The fact that it did not do so during the first hour of deployment does not guarantee that such a  file will be “well-behaved” in the future.

mccabegraph.jpg

Figure 1: Error-proneness as a Function of Cyclomatic Complexity (Source: http://www.enerjy.com/blog/?p=198)

To attain satisfactory long-term quality and stability, you need both the right process and the right code. Continuous deployment is the “right process” if you have developed the deployment infrastructure to support it. The “right code” in this context is code whose technical debt levels are quantified and governed prior to deployment.

Using 3σ Control Limits in Software Engineering

with 2 comments



Source: Wikipedia; Control Chart

The  July/August 2010 issue of IEEE Software features an article entitled “Monitoring Software Quality Evolution for Defects” by Hongyu Zhang and Sunghun Kim. The article is of interest to the software developer/tester/manager in quite a few ways. In particular, the authors report on their successful use of 3σ control limits in c-charts used to plot defects in software projects.

To put things in perspective, consider my recent assessment of the results accomplished by Quick Solutions (QSI) in two of their projects:

One to one-and-a-half standard deviation better than the mean might not seem like much to six-sigma black belts. However, in the context of typical results we see in the software industry the QSI results are outstanding.  I have not done the exact math whether those results are superior to 95%, 97% or 98% of software projects in Michael Mah‘s QSMA database as the very exact figure almost does not matter when you achieve this level of excellence.

A complementary perspective is provided by Capers Jones in Estimating Software Costs: Bringing Realism to Estimating:

Another way of looking at six-sigma in a software context would be to achieve a defect-removal efficiency level of about 99.9999 percent. Since the average defect-removal efficiency level in the United States is only about 85 percent, and less than one project in 1000 has ever topped 98 percent,  it can be seen that actual six-sigma results are beyond the current state of the art.

The setting of control limits is, of course, quite a different thing from the actual defect-removal efficiency numbers reported by Jones for the US and the very low number of defects reported by Mah for QSI. Having said that, driving a continuous improvement process through using 3σ control limits is the best recipe toward eventually reaching six-sigma results. For example, one could drive the development process by using Cyclomatic complexity per Java class as the quality characteristic in the figure at the top of this post. In this figure, a Cyclomatic complexity reading higher than 10.860 (the Upper Control Limit) will indicate a need to “stop the line” and attend to reducing complexity before resuming work on functions and features.

Coming on the heels of the impressive results reported by David Joyce on the use of statistical process control (SPC) techniques by the BBC, the article by Zhang and Kim is another encouraging report on the successful application of manufacturing techniques to software (and to knowledge work in general). I am not at liberty to quote from this just published IEEE article, but here is the abstract:

Quality control charts, especially c-charts, can help monitor software quality evolution for defects over time. c-charts of the Eclipse and Gnome systems showed that for systems experiencing active maintenance and updates, quality evolution is complicated and dynamic. The authors identify six quality evolution patterns and describe their implications. Quality assurance teams can use c-charts and patterns to monitor quality evolution and prioritize their efforts.