Posts Tagged ‘CEO’
Some of the business ramifications of the $1 trillion in IT debt have been explored in the first post of this two-part analysis. This second post focuses on “an ounce of prevention is worth a pound of cure” aspects of IT debt. In particular, it proposes an explanation why prevention was often neglected in the US over the past decade and very possibly longer. This explanation is not meant to dwell on the past. Rather, it studies the patterns of the past in order to provide guidance for what you could do and should do in the future to rein in technical debt.
The prevention vis-a-vis cure trade-off in software was illustrated by colleague and friend Jim Highsmith in the following figure:
Figure 1: The Technical Debt Curve
As Jim astutely points out, “once on far right of curve all choices are hard.” My experience as well as those of various Cutter colleagues have shown it is actually very hard. The reason is simple: on the far right the software controls you more than you control it. The manifestations of technical debt  in the form of pressing customer problems in the production environment force you into a largely reactive mode of operation. This reactive mode of operation is prone to a high error injection rate – you introduce new bugs while you fix old ones. Consequently, progress is agonizingly slow and painful. It is often characterized by “never-ending” testing periods.
In Measure and Manage Your IT Debt, Gartner’s Andrew Kyte put his finger on the mechanics that lead to the accumulation of technical debt – “when budget are tight, maintenance gets cut.” While I do not doubt Andrew’s observation, it does not answer a deeper question: why would maintenance get cut in the face of the consequences depicted in Figure 1? Most CFOs and CEOs I know would get quite alarmed by Figure 1. They do not need to be experts in object-oriented programming in order to take steps to mitigate the risks associated with slipping to the far right of the curve.
I believe the deeper answer to the question “why would maintenance get cut in the face of the consequences depicted in Figure 1?” was given by John Seely Brown in his 2009 presentation The Big Shift: The Mutual Decoupling of Two Sets of Disruptions – One in Business and One in IT. Brown points out five alarming facts in his presentation:
- The return on assets (ROA) for U.S. firms has steadily fallen to almost one-quarter of 1965 levels.
- Similarly, the ROA performance gap between corporate winners and losers has increased over time, with the “winners” barely maintaining previous performance levels while the losers experience rapid performance deterioration.
- U.S. competitive intensity has more than doubled during that same time [i.e. the US has become twice as competitive – IG].
- Average Lifetime of S&P 500 companies [declined steadily over this period].
- However, in those same 40 years, labor productivity has doubled – largely due to advances in technology and business innovation.
Discussion of the full-fledged analysis that Brown derives based on these five facts is beyond the scope of this blog post . However, one of the phenomena he highlights – “The performance paradox: ROA has dropped in the face of increasing labor productivity” – is IMHO at the roots of the staggering IT debt we are staring at.
Put yourself in the shoes of your CFO or your CEO, weighing the five facts highlighted by Brown in the context of Highsmith’s technical debt curve. Unless you are one of the precious few winner companies, the only viable financial strategy you can follow is a margin strategy. You are very competitive (#3 above). You have already ridden the productivity curve (#5 above). However, growth is not demonstrable or not economically feasible given the investment it takes (#1 & #2 above). Needless to say, just thinking about being dropped out of the S&P 500 index sends cold sweat down your spine. The only way left to you to satisfy the quarterly expectations of Wall Street is to cut, cut and cut again anything that does not immediately contribute to your cashflow. You cut on-going refactoring of code even if your CTO and CIO have explained the technical debt curve to you in no uncertain terms. You are not happy to do so but you are willing to pay the price down the road. You are basically following a “survive to fight another day” strategy.
If you accept this explanation for the level of debt we are staring at, the core issue with respect to IT debt at the individual company level  is how “patient” (or “impatient”) investment capital is. Studies by Carlota Perez seem to indicate we are entering a phase of the techno-economic cycle in which investment capital will shift from financial speculation toward (the more “patient”) production capital. While this shift is starting to happens, you have the opportunity to apply “an ounce of prevention is worth a pound of cure” strategy with respect to the new code you will be developing.
My recommendation would be to combine technical debt measurements with software process change. The ability to measure technical debt through code analysis is a necessary but not sufficient condition for changing deep-rooted patterns. Once you institute a process policy like “stop the line whenever the level of technical debt rose,” you combine the “necessary” with the “sufficient” by tying the measurement to human behavior. A possible way to do so through a modified Agile/Scrum process is illustrated in Figure 2:
Figure 2: Process Control Model for Controlling Technical Debt
As you can see in Figure 2, you stop the line and convene an event-driven Agile meeting whenever the technical debt of a certain build exceeds that of the previous build. If ‘stopping the line’ with every such build is “too much of a good thing” for your environment, you can adopt statistical process control methods to gauge when the line should be stopped. (See Using 3σ Control Limits in Software Engineering for a discussion of the settings appropriate for your environment.)
An absolutely critical question this analysis does not cover is “But how do we pay back our $1 trillion debt?!” I will address this most important question in a forthcoming post which draws upon the threads of this post plus those in the preceding Part I.
 Kyte/Gartner define IT Debt as “the costs for bringing all the elements [i.e. business applications] in the [IT] portfolio up to a reasonable standard of engineering integrity, or replace them.” In essence, IT Debt differs from the definition of Technical Debt used in The Agile Executive in that it accounts for the possible costs associated with replacing an application. For example, the technical debt calculated through doing code analysis on a certain application might amount to $500K. In contrast, the cost of replacement might be $250K, $1M or some other figure that is not necessarily related to intrinsic quality defects in the current code base.
 See Hagel, Brown and Davison: The Power of Pull: How Small Moves, Smartly Made, Can Set Big Things in Motion.
 As distinct from the core issue at the national level.
In just about a week I will be sharing the latest and greatest in technical debt techniques through a Cutter webinar in which colleague John Heintz and I will be speaking . In a little over a month a special issue of the Cutter IT Journal [CITJ] on technical debt will be published. And, in a couple of months Jim Highsmith and I will deliver a workshop on the subject in the Cutter Summit.
Shifting from the process to its output (i.e. the code) is the common thread that runs through the three events. Rigorous that your implementation of the software process is, the proof of the pudding is the quality of the code your teams produce. The technical debt accrued in the code is the ultimate acid test for your success with the Agile roll-out and/or with any other software method you might be using.
Another important thread in all three events is a single source of truth. The technical debt data seen by the developer in the trenches, his/her project leader, the mid-level manager on the project, the vice president of engineering and the CFO/CEO represents different views of the realities of the code. Each level sees a different aggregation of data – all the way from a blocking violation at a specific line of code to the aggregate $$ amount required to “pay back” the debt. But, there is no distortion between the five levels of the technical debt data – all draw upon the code itself as the single source of truth.
Here is the announcement of the first event – the Reining in Technical Debt webinar scheduled for August 19, 12:00PM EDT:
Do you really govern the software development process in your IT organization or do its uncertainty and unpredictability leave you aghast? Do you manage to bake in quality in every build? Can you assess the quality of your software in a way that quantifies the risk?
Recent developments in software engineering and in software governance enable you to tie quality, cost, and value together to form a simple and effective governance framework for software. This webinar will provide you with a preliminary understanding of how to assess quality through technical debt techniques, will familiarize you with state-of-the-art tools for measuring technical debt, and will demonstrate the effect on value delivery when technical debt is not “paid back” promptly.
Israel and John will also introduce a governance framework that ensures you can rigorously manage your software development process from a business perspective. This framework reduces a large number of complex technical considerations to a common denominator that is easily understood by both technical and non-technical people — dollars.
Get Your Questions Answered
Don’t miss your chance to get specific advice from Cutter’s experts on technical debt and toxic code. Join us on Thursday, August 19 at 12:00 EDT (see your local time here) to learn how both your software development process(es) and the corresponding governance process can be transformed in a manner that will make a big difference to your software developers and testers, to key stakeholders in your company, and to your firm’s customers.
Register to attend so you’ll have the opportunity to have your specific questions answered. We’ll send you the login instructions a day prior to the webinar.
As always, this Cutter Webinar is not vendor sponsored, and is available to Cutter clients and our guests at no charge. Register here.
Pass this invitation along!
Be sure to extend our invitation to your CIO, CFO and the other senior business-IT leaders and trainers in your organization who you think could benefit from this discussion.
If you have any questions prior to the program, please contact Kim Leonard at email@example.com or call her directly at +1 781 648 8700.
Can’t Make the Live Event?
You won’t miss out — the recording will be added to the webinarsonline resource center for client access, along with the rest of these past events.
Consider the following scenario: You are a venture capitalist. One of your portfolio companies has been working for a few years on a promising software application. Various surprises with respect to schedule and functionality have been sprung on you along the way. The company now asks for one last shot-in-the-arm in order to get the product out the door, market and sell it. Should you open your wallet one more time to fund this alleged last push?
It is a familiar scenario not only for venture capitalists, but for CEOs, CFOs, general managers and M&A executives. A renowned CEO once told me the following when I pushed my luck with respect to project funding:
Israel, I have a warehouse of software products that never generated a dime for me.
Believe me, this CEO was neither amused nor philosophical…
Code analysis techniques have progressed to the point that the answer to the software investment question for object-oriented code can to a certain extent be determined through quantifying technical debt. For example, assume the following circumstances:
- A company expects to ship 500K lines of code in 6 months.
- The company asks for additional $2M to complete development and make a significant resound in the market.
To assess the investment decision, apply the code analysis techniques described in Using Credit Limits to Constrain Development on Margin to quantify the technical debt. Assuming a debt of $2 per line of code has been identified, the overall technical debt amounts to $1M (2X500K).
The investment decision then is not an incremental $2M decision. It is actually a $3M ($2M+1M) investment decision when the technical debt is taken into account. The technical debt might not need to be paid overnight, but it will have to be paid back over a period of time. The team might not hire additional resources to reduce/eliminate the technical debt, but the team resources dedicated to reducing technical debt will not be available to carry out other assignments. Hence, the opportunity cost ($1M) is real, relevant and should be taken into account.
If you are hesitant to continue investing in this software/team, you stare at a tricky question:
- What will it take to start afresh?
If you decide to make the $3M investment, two operational questions pose themselves:
- How should work on reducing/eliminating technical debt be interleaved with other pressing work such as new functions and features?
- Given a $1M debt on 500K lines of code, can the company indeed ship as expected in 6 months?
We will address these three questions in forthcoming posts in The Agile Executive.
Buying (stocks) on margin is broadly recognized as a risky investment strategy. Funding long-term investments with short-term debt exposes the investor to margin calls as he/she might not be able to secure more financing when needed. The resultant margin call is never pleasant.
The accrual of technical debt in the course of aggressively developing functions and features is quite a similar phenomenon. The CTO is betting the functionality he/she is developing will pay off before the need to “pay back” the technical debt becomes imperative. The temptation to do so is particularly strong due to the lack of credit limits on technical debt. For all practical purposes the CTO is “developing on margin.”
In his comprehensive studies of the economics of software, Capers Jones has actually put a 3-5 year ceiling on the economical viability of developing on margin:
Indeed, the economic value of lagging applications is questionable after about three to five years. The degradation of initial structure and the increasing difficulty of making updates without “bad fixes” tends towards negative returns on investment (ROI) within a few years.
As the CEO leading a company, or the venture capitalist funding it, you can restrain development on margin by establishing credit limits. Use a combination of static code analysis with dynamic program analysis to calculate the amount of accrued technical debt in $$ terms. (An illustration of such calculation as well as a breakdown of the technical debt is given in the Sonar chart above). Set a limit (say $0.25 per line of code) on the amount of permitted technical debt. Once the limit is reached, developers are not allowed to continue developing new functionality – they have to first reduce (and hopefully eliminate) their technical debt.
A very simple “Lacmus test” is available to the CEO/VC until the code is instrumented and the analytics illustrated above generated. Ask your CTO about unit test coverage. If the coverage is low (say <30%), chances are the technical debt is high. Whether the CTO realizes it or not, low unit test coverage is a good indicator of technical debt of all kinds. Moreover, the investment required to develop a full-fledged suite of unit tests is often the largest component of the technical debt to be paid back.
“I don’t care about Agile; I care about money!” These words, said to me not too long ago by an executive with whom I was discussing the roll-out of Agile in his division, are the impetus for this post. Whether you are or are not in R&D, Agile can have a significant impact on you and on your company, including the bottom line.
To keep things simple, listed below are a few “front lobe” considerations for CXOs – CEOs, CFOs, CIOs, CMOs, COOs and CTOs. The listed considerations are neither “good” nor “bad” – they are what they are. They are rendered here for the thinking when an Agile topic comes up in the domain(s) you are responsible for.
Some of the considerations for CXO’s are linked to posts, articles or books that already address the subject to some degree. As additional related posts will get rolled out on this blog, they will be linked to the bullets below. In other words, the Agile Considerations for CXOs post will evolve, serving as a quick index for an eclectic list of Agile CXO considerations.
- Business designs to utilize the power of Agile methods
- Market disruption by competitors who adopt Agile
- The Agile enterprise
- Efficiency; Lean; cost structure of the corporation
- Capitalization of (Agile) software
- Agile contracts
- Agile Business Service Management
- IT modernization
- Bridging the chasm between product development, deployment and operations
- Effective use of Agile in the data center
- Guidelines for BSM Investments
- Reconfiguring the business
- Agile portfolio management
- Off-shoring strategy vis-a-vis near-shoring vis-a-vis captive US teams; Distributed Agile
- Can your company afford the software it is developing?
- How many product generations should the support policy cover?
- Application life-cycle management
- Enterprise software considerations