The Agile Executive

Making Agile Work

Archive for the ‘Software Costs’ Category

Your Investment in Enterprise Software – Guidelines to CIOs and CFOs

with 6 comments

The overall investment associated with implementing and maintaining a suite of enterprise software products could be significant. A 1:4 ratio between product investment and the corresponding investment over time in related services is not uncommon. In other words, an initial $2M in licensing a suite of enterprise software products might easily balloon to $10M in total life-cycle costs (initial investment in perpetual license plus the ongoing investment in associated services).

I offer the following rule-of-a-thumb guidelines to assessing whether the terms quoted by a vendor for an enterprise software suite of products are right:

  1. Standard maintenance costs: Insist on a 1:1 ratio between license and standard maintenance over a 5 year period. If standard maintenance costs over this period exceed the corresponding license costs, chances are: A) the vendor is quite greedy; or, B) the vendor’s software accrued a non-negligible amount of technical debt. Ask the vendor to quantify the technical debt in monetary terms. See Technical Debt on Your Balance Sheet for an example how to conduct such quantification.

  2. Premium customer support costs: Certain premium customer support services could be quite appropriate for your business parameters. However, various “premium services” could actually address deficits or defects in the enterprise software products you license. If the technical debt figure is high, the vendor you are considering might not be able to afford the software he has developed. Under such circumstances, “premium services” could simply be a vehicle the vendor uses to recoup his investment in software development.
  3. Professional services costs: Something is wrong if the costs of professional services exceed licensing cost. Either the suite of products you are considering is not a good fit for your business parameters or the initiative you are aspiring to implement through the software is overly ambitious.

To summarize, the grand total of license fees, customer support fees and professional services fees over a 5 year period should not be higher than 3X license fees. Something is out of balance if you are staring at  a 4X or 5X ratio for the software you are considering.

One final point: please do not forget to add End-of-Life costs to the economic calculus. Successful enterprise software  initiatives can be very sticky.

Technical Debt: Refactoring vis-a-vis Starting Afresh

with 2 comments

Only three options are available to you once your technical debt overwhelms the development and customer support teams:

  1. Continue as is.
  2. Start refactoring in earnest to pay back your debt.
  3. Switch to a new code base, either by launching an unencumbered development project or through acquiring new software from another company.

The first option, obviously, does not solve any problem – you simply continue a struggle that becomes more and more difficult over time. As indicated in the post Elbow Room for Handling Technical Debt, the second option is quite difficult to carry out if it is exercised at a late point in the software’s life cycle. This post examines the third option – starting afresh.

The attraction of starting afresh is always tempting. The sins of the past, hidden in layers over layers of technical debt and manifesting themselves in low customer satisfaction and poor customer retention, are (sort of) forgiven. The shiny new software holds the promise of better days to come.

Trouble is, your old sins are there to get you in three nasty ways:

  1. New technical debt: Even if the shiny new software is very good indeed, it will decay over time. Unless you transformed your software engineering practices to ensure refactoring is carried out on an ongoing basis, sooner or later you will accrue new technical debt.
  2. Migration: Good that the new software might be, it is not likely to provide all the functionality the old software had. Migrating your customers will require a lot of hard work, particularly if your customers developed elaborate business processes on top of your old software.
  3. Critical race between old and new: For a period of time (say a couple of years) the old software is likely to run alongside the new software. Any significant new regulatory requirement will force you to update both the old software and the new software. Ditto for security. Any nifty new technology you might want to embed in your new software is likely to be equally desirable to customers who still use your old software. You will be pressed to incorporate the new technology in the old software, not just in the new software.

Before opting for new software (in preference to refactoring the old software), I would recommend you compare the economics of the two option. My rule of a thumb for the calculus of introducing new enterprise software to replace legacy software is straightforward:

For a period of about two years, assume the run rate for dev/test/support will be 150% of your current investment in development, test and support of the old software.

Please note that the 150% figure is just the expected run rate for running the new software alongside the legacy software. You will need, of course, to add the cost of acquiring/producing the new software to the economic calculus.

You might be able to reduce the ‘150% for two years’ investment by applying some draconian migration measures. Such measures, of course, will affect your customers. In the final analysis, your decision to acquire new software must be viewed as the following simple question:

What value do you place on your customer base?!

Enterprise Product: $50,000 and 8 months – You must be kidding!

with 7 comments

With the successful release of Enterprise Profile Management 1.0, I asked Nick Beaugeard – Founder and Managing Director of HubOne – to capture and share with us his Agile development experience. Some of the threads he describes might have been mentioned in other posts in this blog. Others, like “Invest in your method and tools before you hire people, not after you hire people!”, appear for the first time. Whether mentioned here before or not, the ‘secret sauce’ is Nick’s ability to pull so many threads together. The power of so doing is nicely expressed in Nick’s guest post below. 

Nick’s been involved in Tech for 27 years (if you include the games he wrote for the Apple II aged 9) and has been involved with companies like Microsoft, CSC, JP Morgan and many others. He’s also ran a number of start-ups, from web 2.0 to services to solutions companies and has been successful with a number of those. Nick has a passion for all things Agile, but prefers to design the methodology to suit the purpose, rather than rely on a one size fits all method. Notwithstanding this, Nick has some notoriety within Dimension Data for passionately changing solution development from failing waterfall to a test based development approach, suiting solutions and services.
 
Nick lives on Sydney’s northern beaches with his wife, four kids, two mice and a framed copy of the fabled W.W. Royce “waterfall” speech to the IEEE.

Here is Nick:

I’ve ran start-ups before. I’ve even managed the development of products before, but this is the first time I’ve set up a start-up with the sole goal of developing a product and bringing it to market. Thinking back on the last 8 months, I’m not sure I’d have taken the challenge on in retrospect, but we did, and we succeeded and so in this post, I’d like to share with you how a micro-startup with a budget of $50,000 can design, develop, release and certify an Enterprise quality product without going both broke or mad….

 

During my career, which spans everything from support, through solutions and has a great deal of focus on Systems Management, I’ve been constantly frustrated by something which should be really simple, how to find people with specific skills or responsibility. Seeing that the problem still existed, I set out to build a solution which would attempt to solve such a problem.

 
The first step on the road was to meet with potential customers. At this stage, I had barely a germ of an idea. It could be written in 20pt type on a single piece of paper. Nevertheless, I met with over 20 different potential customers and attempted to pitch the “solution” to them. The feedback I got was extensive, but the main and core piece of information was that the solution had value and merit and if we could deliver then these customers might just buy the software. I even went as far as to ask them how much they’d pay for such a solution and got a fairly consistent figure of about $20 per year per user.

 
I realised at once that the problem I was trying to solve was not a database problem. In fact it was a directory problem so I set about investigating whether I could produce a solution using an LDAP directory.

 
Right at the beginning, though, I made an investment in tools. I implemented great source control, issue management, task management and a build platform, just like I was in a huge team.

 
I also made sure I adhered to issue and task management and made sure that I was forced to complete the criteria for each check-in. I know that sounds stupid, and it must have seemed so… The CEO of a start-up assigning himself issues only to resolve them on check-in.  However I believed it to be easier to implement the processes I wanted before I had a team on board, demonstrate me using them and it would be WAY easier to get the team to use them!

 
To test if my architectural hypotheses was correct, I wrote a very, very basic API. This small piece of code was able to perform some CRUD (Create, Retrieve, Update and Delete) operations on my own custom directory objects.

 
Let’s read the above again… See I had no spec, some interesting comments from customers and just went ahead and wrote a prototype API. Next I wrote some Unit tests which exercised the API and went back to my customers to see if I was on the right track.

 
That bit was tough. It takes a fair amount of imagination to see a simple set of unit tests and then extrapolate that to a completed product. However my friendly customer s were very patient as I explained that a response of “Passed” actually meant what I just explained had happened.

 
Once again that feedback helped and I felt confident enough to prototype most of the API and almost completely complete the schema. Once again I created a bunch of unit tests, but this time I focussed on the core scenarios as discussed with our customers.

 
Still at this stage, we had spent almost nothing, had a good, working and testable prototype API and a schema which worked.

 
It was then time to go and get a couple of developers. I knew a couple of my close colleagues had just resigned from another company so I asked them if they’d come and work for me, at a vastly reduced rate, for some stock in my new start-up. 

 
Just the stage for a spec, huh? We’ve now got more than one developer so obviously need to write down then entire goal of the solution…

 
I thought not. My API was just a prototype and needed to be secured, consolidated, better documented, globalized and tested for performance and the unit tests demonstrated exactly how things should work. My new, fresh team set to work on tidying up and completing the API, working on issues and tasks and performing check ins. They also got told whenever they broke a build.

 
We were then seriously thinking about building a web services layer. This had several advantages, not the least being that we could support clients on multiple platforms. However, I was still a little uncomfortable with my API hypotheses and really wanted to build a client that exercised the entire API before we invested in SOAP and web services.

 
Therefore we set the challenge and therefore the scope of version 1. Version 1.0 would deliver a server (LDAP with an Installer) and a client (Windows XP and above) which talked to the LDAP server using our API.

 
That made the next challenge was the UI. This is a problem for me as I’m not one for having any design skills at all. However I could have sat down and tediously wire framed every screen and interaction I and my customers wanted.

 
However I knew a better wireframing tool – the IDE we used to write code instead. I sat down and started to craft a UI, using a lot of trial and error. In 7 days, I had a UI which exercised the main aspects of the API and the code base…

 
And that’s how our development stayed, I’d prototype (wireframe with code) a feature and the devs would then go and finish it.

 
We found bugs in the API, sure, but never needed to write new API methods to make the client work.

 
In the final weeks, we just worked on testing and fixing bugs… The test plan you ask? – Well that was the user guide! A full test pass meant running through each page in the user guide and doing everything it said.

 
A recent code review showed there was none of my prototype code left in the platform, but it didn’t matter. We shipped the product and spent less than the $50,000.

 
In conclusion our method was:
·         Speak to your customers. Not lots, all the time!
·         Invest in your method and tools before you hire people, not after you hire people!
·         Make the software function, before you spend time making a UI function.
·         Continuously test, fix and test again and don’t be afraid to throw prototypes away.

 
Last Friday we released version 1.0, go download it, you be the judge of how we did!

Written by israelgat

August 11, 2009 at 7:17 pm

Rusty Automobiles

with 3 comments

No, this post is not about today’s GM bankruptcy filing. Rather, it is about coming to terms with a phenomenon similar to rust – software decay.

An IT application development team I met with recently indicated they reached the point of allocating 80% of their resources to software maintenance.  Various colleagues of mine report similarly worrisome figures experienced in their practices. As a matter of fact, some of  my colleagues consider such figures endemic.

It might indeed be hard to visualize a rusted line of code. Decay, however, applies. To quote Capers Jones:

All known compound objects decay and become more complex with the passage of time unless effort is exerted to keep them repaired and updated. Software is no exception… 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.

Hazardous that software decay is operationally and economically, it is lethal once it becomes embedded as a revenue generator in the business design for enterprise software. In particular, high maintenance costs as part of planned obsolescence  invariably lead to the sorry state of affairs characterized as “Consumer Underworld” in The Myth of Excellence.

If you find this post a bit dramatic, please read Christensen’s recent post on the titanic efforts to turn things around launched by GM when it was already too late. Christensen concludes his post with a very pointed warning:

If you’re curious to know what lies in store for Seattle and Silicon Valley, spend a day walking around Detroit with the Ghost of Christmas Future.

Written by israelgat

June 1, 2009 at 1:24 pm

Timing and Duration of the Agile Roll-out

leave a comment »

A measure frequently considered by executives these days is the introduction of Agile as part of cost reduction initiatives. To succeed in attaining cost benefits through the higher productivity of Agile, the plan for introducing it needs to take into account the slippery slope that repeated cost cutting measures tend to lead to. In particular, the timing of rolling out Agile and the duration of the roll-out need to be carefully considered to avoid a possible cart-before-horse situations.

A cart-before-horse situation is likely to arise as a result of the following pattern:

  1. An executive’s budget is under pressure.
  2. Headcount reduction is carried out. Remaining employees are expected to somehow cope with the load.
  3. Agile, with its promise of higher productivity and possibly hyper-productivity, is introduced as a counter-measure to the reduced headcount.
  4. The remaining development resources are expected to acquire a new set of skills, to master the art of Agile.
  5. The need to acquire Agile skills flies at the teeth of remaining employees needing to regain expertise that was lost by reduction in headcount. In many cases, the remaining development resources are already stretched too thin.
  6. Staring at the choice between acquiring specific domain expertise in a critical area versus developing less concrete expertise in software methods, more often than not the remaining employees and the system around them will opt to concentrate on acquiring domain expertise. For example, if a product fails to satisfy a new security benchmark introduced by key customers, the need to respond to the security benchmark is likely to take precedence over studying estimation techniques for Agile.
  7. Goto #1 above.

To preempt such cart-before-horse situation, the following principles need to be adhered to:

  1. Don’t introduce Agile before “the system” adequately adjusted to a round of headcount reduction.
  2. Do not carry out layoffs during the assimilation phase of Agile. In addition to cart-before-horse situation as described above, headcount reduction could jeopardize two critical pillars of Agile: empowerment and collaboration.
  3. Establish a quantified baseline of productivity before starting an Agile roll-out. Measure Agile progress against the baseline.
  4. Do not bet the Agile roll-out on linear improvement in productivity. A good Agile implementation is likely to improve productivity, but it is quite tricky to predict the shape of the Agile learning curve.

In practical terms, your organization needs to take a strong “medicine” up-front to break the vicious cycle that repeated staff reductions amidst an Agile roll-out are likely to create. The medicine should be strong enough to last through the period of time required for a meaningful assimilation of Agile. A good way to assess how long the period might be is to consider Agile as apprenticeship – one learns by “Agiling” with the masters.

You need to ask yourself the question “Can We Afford the Software We are Developing?” if business circumstances do not allow for reasonable adherence to the principles cited above.

Companies make shoes!

with 2 comments

Peter Drucker made an astute observation which is quite relevant to the current business situation during a September 1998 interview with Fortune:

Securities analysts believe that companies make money. Companies make shoes!

Readers of this blog might have said “software” instead of “shoes.” The point would have been similar to Drucker’s. Good financial management is no doubt  important for your company’s success. It is no substitute, however, to focusing on the business you are in, the technology(ies) that drives the business and the effectiveness of the underlying systems and processes.

The current macro-economic situation gives you an opportunity to soberly assess the viability of your business design (as distinct from doing a lot of financial engineering). With asset inflation corrected, measuring the effectiveness of your business model in terms of the ratio Market Value/Revenues is much more meaningful now then it used to be prior to September 2008. As pointed out by Slywotzky in Value Migration, a market value to revenues ratio lower than 0.8  indicates value outflow for your company and possibly for your industry.

For software companies, the impact of “good enough” Open Source Software should be assessed in conjunction with close examination of the market value to revenues ratio. Twitting from the recent OSBC conference in San Francisco, colleague Andrew Dailey of MGI Research reported “… ERP/CRM are viewed as least susceptible to open source disruption… due to high transaction volumes and high integration needs.” Conversely, Andrew considers office productivity software as ripe [for the picking by Open Source Software]. I am personally of the opinion numerous Application Life-cycle Management tools could be massacred by Open Source Software.

The confluence of the threads highlighted above poses a fairly unique opportunity for the Agilist to convey a major premise of Agile to his/her executives. Like a thriving Open Source Software community, a hyper-productive Agile team can pick a ripe market faster and cheaper than an old fashioned software company could. Moreover, if a company is in one of the markets that are susceptible to an Open Source Software onslaught, Agile can (up to a point) provide defense against such onslaught. Whether you choose to attack or defend, Agile software gives you the advantages of proprietary software at a fraction of the traditional cost.

The Language, The Issues

with 2 comments

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:

A Quip That Says It All

leave a comment »

Readers of the post Can You Afford the Software You are Developing? might recall my grave concern about accruing technical debt. It is like debt on your credit card – you struggle to pay the interest; you rarely manage to pay back the principal.

Reading Esther Derby‘s article  The Three Pillars of  Executive Support for Agile Adoption,  I noticed her independent “verdict” on the subject:

Technical debt is the harvest of cutting corners to meet unrealistic deadlines

I am inclined to think “technical debt” is actually a euphemism for “inadequate investment”

Written by israelgat

March 11, 2009 at 2:24 pm

Posted in Software Costs

Tagged with ,

Why Agile Matters

with 9 comments

Agile matters because it is a critical factor in the techno-economic process. In fact, it fits nicely in both the classical theory of techno-economic cycles, and the latest revisions to the theory. Whichever school of thought you might follow with respect to what the nature of the current macro-economic crisis is and what the implications for your company might be, Agile will serve you well.

Technological revolutions

In Technological Revolutions and Financial Capital, author Carlota Perez views technological revolutions as part of techno-economic cycles. According to Perez, techno-economic cycles are composed of a sequence of events that proceeds in the following way:

  1. A major technological innovation introduces a new infrastructure
  2. The new infrastructure disrupts both industry and commerce (and very possibly society)
  3. Overtime, the new technology gets to be understood; it then gets harnessed
  4. As the new technology gets harnessed, confidence in it grows and it gets used broadly. Consequently, in good time, the new infrastructure itself becomes a stabilizing force
  5. A new technological innovation disrupts the prevailing order and gives rise to start a new techno-economic cycle

Perez identifies five successive technological revolutions between the 1770s and the 2000s:

slide1

To summarize, Perez perceives that technological revolutions are subject to laws of cyclicality. The cardinal law in the cyclicality is that intertia eventually becomes the legacy of successfule innovation.

Has the techno-economic paradigm been disrupted?

In a recent Harvard Business Review article, authors Hagel, Brown and Davison suggest that we are witnessing a profound shift:

The historical pattern – disruption followed by stabilization – has itself been disrupted.

Hagel, Brown and Davison perceive an exponential pace in information and telecommunication. The exponential pace creates a new reality and a new order:

Because the underlying technologies are developing continuously and rapidly, there is no prospect for stabilization. Businesses and social institutions constantly find themselves racing to catch up with and learn the steadily improving foundational technologies…  The core technology infrastructures that once formed the bedrock have turned into plasma.

Choosing between the two theories

The debate about which techno-economic paradigm – the Carlota Perez paradigm or the Hagel, Brown and Davison paradigm – is better suited for the current circumstances is beyond the scope of this blog. Be it as it might, Agile fits well with either paradigm, though in a different manner.

Agile as a low cost input

If you believe the classical techno-economic paradigm a la Perez continues to prevail, you need to think of software produced by hyperproductive Agile team as a low-cost input in the techno-economic system.  If Agile is massively adopted, it will satisfy the four conditions stipulated by Perez for an input to be a key factor in the technological revolution:

  1. Clearly perceived low – and descending – relative cost
  2. Unlimited supply for all practical purposes
  3. Potential all-pervasiveness
  4. Capacity to reduce the cost of capital, labour and products as well as to change them

The potential  implications of Agile software getting to satisfy these four conditions are far reaching. According to Perez, the current technological cycle started in 1971 with the introduction of the microprocessor by Intel. Hence, one might think of Agile software as a “mid-life kicker” to the current techno-economic cycle.

At the micro-economic level, the implications of Agile as a low-cost input for traditional enterprise software vendors are dire. As pointed out in the post Enterprise Software Innovator’s Dilemma, some low-cost input effects are already manifesting themselves through Open Source Software.

 Agile as agile

If you subscribe to the “bedrock into plasma” paradigm advocated by Hagel, Brown and Davison, you need to view Agile from the point of view of, well, agility. Irrespective of whether your business strategy calls for adapting to the market or shaping it, speeding up the business, not “just” R&D, is absolutely of the essence. You need to apply the Agile principles to the way you develop your business and your customers.

The point in nicely illustrated in The Lean Startup presentation by Steve Blank and Eric Ries. The authors are emphatic in their recipe for success:

Winners are those that can move faster than their competition.

To move faster than the competition, Blank and Ries recommend applying Agile principles to customer development. In so doing, they extend Agile beyond the traditional starting point when the (customer) problem is supposed to be known but the (software) solution is unknown. They elevate the paying fields to the level in which customer development is done in  parallel to product development. This kind of uninterrupted flow in the feedback loop between developer and end-user makes Agile extraordinarily powerful. 

For further research

I encouraged you to consider the ramifications of the ideas presented above and to comment on them in this blog and elsewhere. Of the numerous avenues that we can explore in pursuing the boundaries of Agile, the following topics are particularly intriguing:

  • Alan Fusfeld introduced the Technological Progress Function as a tool to quantify technological progress as function of time and scale. The opportunity exists to combine software metrices, the technological progress function, and the techno-economic paradigm in a unified model.
  • As pointed out above, inertia eventually becomes the legacy of successful innovation. Conversely, one needs to overcome inertia in order to introduce successful innovation. Jim Highsmith‘s recommendation to innovate through experimentation a la Agile is very powerful at the project level. It is not fully clear how a similar approach could be facilitated at the policy level.

Batten Down the Hatches

leave a comment »

“As you might expect, we are in a batten down the hatches mode.” These words, taken from an email an executive just sent, prefaced his decision not to go ahead with planned Agile projects due to the need to cut costs. His operating assumption is simple: His company must cut costs now and will somehow manage without  investing in Agile software and consulting.

Real $$ are hidden in your software

In Estimating Software Costs, author Capers Jones quantifies five year cost of software application ownership (for the vendor). He examines three  similar applications, each of nominal size of 1000 function points, as a function of the sophistication of the corresponding projects. The respective life cycle costs are as follows:

  • Lagging projects: $2,316,000
  • Average projects: $1,860,000
  • Leading projects: $1,312,000

Jones goes on to issue the following stern warning:

All known compound objects decay and become more complex with the passage of time unless effort is exerted to keep them repaired and updated. Software is no exception… 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.

Dwindling maintenance revenue streams complicate the situation

Revenues from maintenance services are subject to severe pressures these days as many customers are renegotiating service contracts. Igor Stenmark foresaw and foretold the phenomenon in November 2008.  To quote Igor:

…sacred cows like software maintenance can become hamburger meat if users feel enough of a budget pressure.

Net net, as they say, the exec mentioned above is likely to face rising maintenance costs due to software decay over time. At the same time, revenues from maintenance contracts are bound to fall short of projections due to customers renegotiating their contracts.

The shiny new toy is not a cure

Recognizing the software maintenance conundrum they are caught in, many executives are pushing hard to develop new software to increase sales in order to compensate for the decline in revenues from software maintenance services.

What is missing is a serious commitment to improve the underlying software process. Software developed today might indeed be sold as a shiny new toy tomorrow. But, unless the software process is improved, a little down the road the new software will have similar maintenance problems. The corrosive effect of software decay on the shiny new software will become more and more severe as a function of time. The current business environment, hopefully, will change in a few years. However, the underlying software development and maintenance laws will not. No getting around it.

No better time than now

The numbers from Capers Jones cited above are illustrative of the cost savings you could expect to attain by modest investments in improving software process and practices. You might perhaps have more attractive cost saving alternatives available to you. However, if you don’t, there is no better time to invest in software process and practices than now.

Written by israelgat

February 16, 2009 at 4:09 pm