Key Points dalla CAST CIO CONFERENCE 2015

Giovedì 11 Giugno 2015 ha avuto luogo la IV Edizione della CAST CIO Conference. Ringraziamo i numerosi aderenti alla manifestazione che hanno contribuito al successo di questo evento consentendoci di analizzare, traendo spunto dai più recenti  casi di malfunzionamento di applicazioni “mission critical”, le strategie di prevenzione dei rischi attraverso la misurazione della qualità strutturale degli asset applicativi critici.

Key Points dal 1° Evento Metrico 2015 GUFPI ISMA

CAST ha partecipato al 1° Evento Metrico 2015 organizzato dal GUFPI ISMA, associazione di riferimento nazionale per la misurazione del software in Italia, tenuto a Roma lo scorso 14 Maggio.
La conferenza ha visto la partecipazione di Cast sui seguenti 3 topics:

Computer Glitches Plague Obamacare Launch

More and more evidence is coming to light that the glitch-filled launch of the Obama Administration’s new healthcare marketplace,, was more than simply launch-day traffic overload. Technology experts who’ve gotten access to the site have reported that it appears to be built on a sloppy software foundation full of dead code and improper web-efficiency techniques — hallmarks of a software project rushed to meet a launch deadline.

The government wasn’t the only thing that shut down Oct. 1

In the midst of debt ceiling and government shutdown negotiations on Monday, the Obama Administration launched its new online health insurance marketplace — — where Americans can go to shop for affordable healthcare.
However, it seems even the federal government isn’t immune from technical snags.

Is There a Technical Debt Tipping Point?

This year, 2011, seems to have been the year of discussing, debating and, hopefully, dealing with debt crises. The U.S. Congress’ Super Committee has its deficit reduction recommendations due in three weeks. Meanwhile the Greek government is reconsidering the debt restructuring deal it signed just just last week. It’s pretty clear that in those situations, debt crises have reached a tipping point, but it’s far from clear whether those responsible will “man up” and address them.
It’s with these current events in mind that I read Ilya Bagrak’s post Tuesday calling technical debt “a rabbit hole that goes deep, really deep…” This, combined with seeing Malcolm Gladwell quoted somewhere, made me ask myself – is there a technical debt tipping point? Is there a point up to which technical debt must be “paid down?”
Yes, I think there is, but like technical debt itself, it’s hard to identify and even harder to address.
Tip-Toeing Around Technical Debt
We have defined technical debt as “the cost to fix the structural quality problems in an application that, if left unfixed, put the business at serious risk.” To figure out if there’s a technical debt tipping point and if so, what it is, we have to understand the definitions of “cost” and “risk.”
Cost can mean many things, including the monetary cost to bring in new developers to pay down technical debt, the physical and emotional strain of the extra hours to improve, refactor or otherwise improve code, and actual lost sales to customers and impact on the lead pipeline, to name just a few.
And what about risk? Risks can range anywhere from the inability to complete the product, losing talented programmers, falling behind competitors, damaging the company’s reputation, again, just to name a few.
But where does the tipping point of technical debt become so great that it causes irreversible harm, or as Malcolm Gladwell defines it, “the moment of critical mass, the threshold, the boiling point?” What’s scary is that a tipping point can result from activities with non-intended consequences. When the New York City Police began their zero tolerance campaign against petty crime, such as avoiding subway fares, it wasn’t part of a larger strategy to reduce violent crime. The goal was simply to reduce petty crime. Yet success with thwarting petty crime turned out to significantly reduce violent crime.
And that makes me ask, “What are IT activities that could cause the unintended consequence of going over the technical debt tipping point?” Is it a delay in product delivery? Is it customers backing out of sales and then a couple of developers resigning over concerns for the company and sparking an ongoing exodus of customers and staff? Or, is it a competitor announcing a market-changing new product, causing critical members of a development team to jump ship and resulting in a new product being late further angering loyal customers?
Another contributing factor to where a technical tipping point exists lies with customers themselves. After several lean years, many are competing fiercely to stay in business and the last thing they can afford is an IT provider that fails to deliver. These customers are also aggressively searching for a competitive edge and if they find new IT solutions that replace existing capabilities they will bolt in a flash.
A Hot Tip
But don’t get me wrong, technical debt is here to stay and, in some circumstances, is even necessary. For example, if it is known in the industry that a new solution will soon be available that will improve the process or the code on which you are working, there’s little reason to rush and expend today’s less efficient resources.
But, in my travels, I see far too many companies that don’t have a handle on their technical debt. Far too many treat their technical debt like those in the financial sector who instigated the banking collapse of 2009, preferring to act like the debt doesn’t exist rather than addressing it and paying it down to a healthy point. Just like Lehman Brothers discovered with their debt, technical debt left unaddressed will eventually take you down.
That doesn’t mean every last red-cent of technical debt needs to be addressed. CIOs and heads of application teams should use automated analysis and measurement to evaluate the structural quality of their three to five mission-critical applications. As each of these applications is being built, they can measure its structural quality at every major release. They should also measure their structural quality every quarter after the application software is released.
From there, they need to 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. As shown in the diagram, once a dollar figure on technical debt is ascertained, compare it to the business value (For a framework for calculating the loss of business value due to structural quality violations, we recommend, “The Business Value of Application Internal Quality” by Dr. Bill Curtis.) to determine how much technical debt is too much and how much is acceptable based on the marginal return on business value.
With this formula, IT managers may be able to embrace 2011 as the “year that we started to proactively manage our technical debt.”  It doesn’t roll off the tongue as easily as “2011, the Year of the Rabbit,” but the benefits will “hop” off the financial ledger and pay dividends in the long run.


Curtis Gives Keynote on Technical Debt at Construx

The Construx Software Executive Summit, which opens today in Seattle, WA, provides a forum for top executives to compare, evaluate and improve their Software Development experiences and strategies at the enterprise level. Keynoting this year’s summit will be CAST’s chief scientist, Dr. Bill Curtis, who will present on the topic, “How Governing Code Quality Reduces Business Cost and Risk.”
Curtis’ keynote will focus on how addressing structural quality of application software during pre-production mitigates, and in many cases eliminates, the risk of software malfunctions and outages after deployment, which also significantly reduces a company’s technical debt. He will explain how companies can work with legacy systems to achieve optimal structural quality of application software and thereby reduce their technical debt.
In addition to Curtis, other IT industry notables presenting at Construx include: Steve McConnell, Tom Gilb, James Whittaker, Philippe Kruchten and Ward Cunningham.
Curtis is an industry luminary who is responsible for influencing CAST’s scientific and strategic direction, as well as helping CAST educate the IT market about the importance of managing and measuring the quality of its software. He is best known for leading development of the Capability Maturity Model (CMM), which has become the global standard for evaluating the capability of software development organizations.
Recently elected a Fellow of the Institute of Electrical and Electronics Engineers for his contributions to software process improvement and measurement, Curtis is the director and co-founder of CISQ, an IT industry leadership group comprised of IT executives from the Global 2000, system integrators, outsourced service providers and software technology vendors all of whom are committed to introducing a computable metrics standard for measuring software quality.

Bill Curtis Keynotes CONSEG 2011

This week, Bill Curtis, SVP & Chief Scientist at CAST will be delivering a keynote presentation at CONSEG 2011 in Bangalore, India.
Bill’s presentation, entitled “The Structural Quality of Business Application Software: An Empirical Report on the State of the Practice.” will focus on the conference theme: addressing the aspects of software engineering that impact the quality of system processes and products.
In his presentation, Bill will cover:

The quality problem in externally-supplied software (sourced and COTS/packaged)
Measuring and managing the structural quality of applications
How to measure the impact of software structural quality on business outcomes

Dates: February 17-19, 2011
Location: Chancery Pavilion
Residency Road,
Bangalore 560025, India