Posts Tagged ‘Carlota Perez’
I Never Even Spoke with Anyone from the Occupy Wall Street Movement
Full disclosure part I: a month ago, while on my way to a business meeting, I saw a few OWS folks “camping” in front of the Federal Reserve Bank on Market street in San Francisco. I did not even have the time to take a picture with my iPhone, let alone chat with someone. This is the closest I ever got to touching, or being touched, by anyone in the movement.
So, I do not even know whether folks in the movement will agree or disagree with my simple interpretation of their overarching message:
- Our financial system is badly broken.
- Rather than letting it continue with business as usual, the Federal Reserve Bank should take over the banking system.
- Many of the services provided today by banks can be provided (once the Fed takes over) through devices such as iPhone just as they do in rural India.
- Substitutes could and should be developed for the services that can’t be carried out through iPhones or similar devices.
- Developing such services is no different from developing alternative sources of energy or health care services.
- Once the government puts in the appropriate policies (to encourage development of such services), a ton of entrepreneurs will jump at the opportunity.
I have no doubt that there are zillion details that I am not aware of that need to be figured out. I am a software engineer, not a banker.
But, I believe that at a very high level bullets 1-6 above capture some aspects of the message folks in the Occupy Wall Street movement are trying to get across. Hence, I am really surprised at the question I see cited so often “But what do they really want?!” IMHO they simply want a major reform of the financial system. The details for so doing are better left to experts.
Full disclosure part II: I have to admit my blood boiled today when I saw the videos from UC Davis. As I said in a tweet an hour or so ago, it starts feeling like the brutality inflicted on the Bonus Army in 1932. Tim O’Reilly goes one step further in his post in which he brings up the loaded topic of Banality of Evil.
So, I might be writing this post with some strong emotions. But, I think the thesis I pose is directionally correct.
You don’t need to take my word for it. Just read Technological Revolutions and Financial Capital by Carlota Perez.
The Real Cost of One Trillion Dollars in IT Debt: Part II – The Performance Paradox
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 [1] 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 [2]. 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 [3] 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.
Footnotes:
[1] 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.
[2] See Hagel, Brown and Davison: The Power of Pull: How Small Moves, Smartly Made, Can Set Big Things in Motion.
[3] As distinct from the core issue at the national level.
The Hole in the Soul and the Legitimacy of Capitalism
In a January 13, 2010 post entitled The Hole in the Soul of Business, Gary Hamel offers the following perspective on success, happiness and business:
I believe that long-lasting success, both personal and corporate, stems from an allegiance to the sublime and the majestic… Viktor Frankl, the Austrian neurologist, held a similar view, which he expressed forcefully in “Man’s Search for Meaning:” “For success, like happiness, cannot be pursued; it must ensue, and it only does so as the unintended consequence of one’s personal dedication to a cause greater than oneself . . ..”
Which brings me back to my worry. Given all this, why is the language of business so sterile, so uninspiring and so relentlessly banal? Is it because business is the province of engineers and economists rather than artists and theologians? Is it because the emphasis on rationality and pragmatism squashes idealism? I’m not sure. But I know this—customers, investors, taxpayers and policymakers believe there’s a hole in the soul of business. The only way for managers to change this fact, and regain the moral high ground, is to embrace what Socrates called the good, the just and the beautiful.So, dear reader, a couple of questions for you: Why do you believe the language of beauty, love, justice and service is so notably absent in the corporate realm? And what would you do to remedy that fact?
Hamel’s call for action is echoed in the analysis of the double bubble at the turn of the century by Carlota Perez:
The current generation of political and business leaders has to face the task of reconstituting finance and bringing the world out of recession. It is crucial that they widen their lens and include in their focus a much greater and loftier task: bringing about the structural shift within nations and in the world economy. Civil society through its many new organisations and communications networks is likely to have a much greater role to play in the outcome on this occasion. Creating favourable conditions for a sustainable global knowledge society is a task waiting to be realized. When – or if – it is done we should no longer measure growth and prosperity by stock market indices but by real GDP, employment and well being, and by the rate of global growth and reduction of poverty (and violence) across and within countries.
As if these words were not arousing enough, Perez adds one final piercing observation:
The legitimacy of capitalism rests upon its capacity to turn individual quest for profit into collective benefit.
IMHO Hamel and Perez identified the very same phenomenon (“hole in the soul”). The only difference is at the level they discuss the phenomenon. Hamel makes his observation at the business/corporate level; Perez at the socio-economic level.
Marauder Strategy for Agile Companies
Colleague Annie Shum sent me the URL to a recent post by Clayton Christensen in The Huffington Post. In this post Christensen characterizes “disruption” in the following manner:
Disruption is the causal mechanism behind the “creative destruction” that [economist Joseph] Schumpeter saw so pervasively at work in capitalist economies. [Links added by IG]
Christensen’s post is largely about the automobile industry. It, however, ties nicely to an email exchange Jeff Sutherland and I had about Agile as a disruption inside the company vis-a-vis its intentional use as a disruptive methodology in the market. To quote Jeff:
We are starting to see organizations like yours that can use Scrum to disrupt a market. There is a tremendous amount of low hanging fruit out there. Dysfunctional companies that can’t deliver. I’ve been recommending a “Marauder” strategy to the venture group. Find a company who has a large amount of resources. Set them loose like pirates on the ocean and they seek out slow ships and take them out.
Carlota Perez, who has been often cited in this blog (click here, here and here), is a disciple of Schumpeter. I really like the way the “dots” are connected: Schumpeter –> Perez –> Christensen –> Schumpeter. Their theories of disruption and constructive destruction express themselves nicely in the business design proposed by Jeff.
A Note on the Macro-Economic Crisis
Re-reading Technological Revolutions and Financial Capital: The Dynamics of Bubbles and Golden Ages by Carlota Perez, I was struck by the following paragraph:
So, once again, the amount of money available to financial capital has grown larger than the set it recognizes as good opportunities. Since it has come to consider normal the huge gains from the successful new industries, it expects to get them from each and every investment and will not be satisfied with less. So rather than go back to funding unsophisticated production, it develops sophisticated instruments to make money out of money. [Italicized and highlighted by IG]
Perez published the book in 2002. Her words of wisdom seem to be appropriate today even more than they might had been then.
(Click here and here for related discussions of Agile in the context of the current macro-economic crisis.)
The Language, The Issues
Colleague Clarke Ching asked me about the language I use in interacting with executives on Agile topics. To quote Clarke:
Obviously the language one uses with a developer is quite different from the language one uses with a program manager. Likewise, the language you [Israel] use in discussing Agile with executives must be quite different. What language do you use? In particular, what language do you use amidst the current economic crisis?
What language do you use amidst the current economic crisis?
I view the economic crisis as part of life. Having grown up in Israel, I still clearly remember:
- The 1956, 1967 and 1973 wars;
- Various economic crises;
- Any number of measures taken by the government to cope with financial crises. For example, devaluing the currency on many occasions.
We all survived and the country moved forward in leaps and bounds. We simply learned to accept dramatic changes as inevitable, to continue doing what we believed in. We, of course, changed tactical plans in response to disruptions such as a change in the value of the currency, but continued to do the right things strategically. Such turbulence, and possibly worse, has been characteristic of much of the world for many years now. Just think of Eastern Europe, Latin America or Africa.
Fast forwarding to 2009: I try to put the economic crisis in perspective. I have discussed the techno-economic cycle along the lines articulated by author Carlota Perez in her book Technological Revolutions and Financial Capital: The Dynamics of Bubbles and olden Ages. In my recent post Why Agile Matters, I stated:
- The fifth techno-economic cycle started in 1971 with the introduction of the Microprocessor;
- This cycle has been characterized by software going hand-in-hand with miniaturized hardware. We are witnessing pervasive software on unprecedented scale;
- Furthermore, software is becoming a bigger piece in the contents of just about any product. For example, there are about 1 million lines of code in a vanilla cell phone;
- Agile software significantly reduces the cost of not “only” software, but the cost of any product containing software;
- And, Agile software enables us to respond faster and more flexibly to changes – in the software, in the business process that is codified by the software, in the product in which the software is embedded.
In short, I speak about software as an important factor in the bigger scheme of things – the techno-economic cycle.
What language do you use in your conversation with executives?
I describe the benefits of Agile in the business context. For example, when I meet an executive of a major financial institution, I discuss with him/her issues of compliance and risk his company is facing. For a global financial institution I typically discuss the critical needs during transfer of trade from London to Wall Street. A lot of things need to work seamlessly in order to ensure smooth transition. If things do not work well within the short transition window, the implications are dire:
- Unacceptable risks. Billions of $$ could be lost if a global financial company cannot start trading on time in Wall Street;
- Severe compliance issues. The executive with whom I speak and his/her company could get in serious regulatory trouble due to a failure to reconcile trades and keep the required audit trail.
The ties of these business imperatives to Agile are straightforward:
- Higher quality code reduces the risk of a ‘glitch’ in the transition of trade from London to Wall Street;
- Should a financial institution suspect a glitch might happen, Agile usually enables Application Development and Operations to fix the code faster than traditional methods;
- And, using virtual appliance technology enables deploying the fix in minutes instead of months.
I usually cite the examples of Flickr and IMVU to demonstrate how fast one can deploy software nowadays. I make it crystal clear that I do not expect a global financial institution today to be able to deploy every thirty minutes or every nine minutes as Flickr and IMVU do. However, I stress that the software industry is clearly heading toward a much shorter cycle between concept or problem identification and deployment. I point out that he/she has an opportunity to be ahead of the power curve, to gain competitive advantage in the market through superior velocity in both development and deployment. Obviously, a faster introduction of a new hedging algorithm could make a big difference for a financial institution.
What do I typically hear from the executive in such a conversation?
The responses I usually get tend to reflect the alignment (or lack thereof) between the financial strategy and the operational strategy a company follows:
- The “cut costs by cutting costs” variety: the discussion revolves around the need to continue to carry out layoffs on a quarterly basis. In this case I stress the life cycle costs of software, asking the executive I am speaking with to answer a tough question: Can you afford the software you are developing? This question often leads the executive to reexamine the balance between the two strategies (financial versus operational).
- The “cut costs by systemically improving the underlying system” variety. The conversation with executives of this mindset usually converge quickly on what is most important to the business: time-to-market, quality or productivity. It is a small step from here to getting into the “hows” of Agile roll-out.
The Agile Executive 