As someone who spends many an hour waiting at airport gates for delayed or canceled flights, I have come to appreciate the extraordinary array of free programming available to us all the time.

In the past few years, I have become an avid podcast listener and I’ve compiled a short list of the programs I have been listening to recently:

Could a Team of Trumpeters Really Bring Down the Walls of Jericho?

The Stuxnet Attacks and Cyber Warfare

Roy Blount Jr. on the Marx Brothers’ Duck Soup

The Mysteries of the Brain

War may be a recurring theme with this particular selection – cyber, acoustic and the inimitable Marx Brothers’ variety – but my general intent is to pass on programs I have found interesting, entertaining or amusing.

I will continue to share new listening material from time to time — for those inevitable hours we all spend stuck in transit!

Happy listening,

Fran
InnerWorkings

Add this post to:             

I’m pleased to announce that InnerWorkings is continuing our thought leadership webcast series on Managing Application Development Teams and Software Projects.

Next in the series is a highly anticipated discussion on the Risks & Rewards of .NET Adoption in the Enterprise with one of our key customers, GE Healthcare — it’s scheduled for Tuesday, October 19th at 11 AM Pacific / 2 PM Eastern.

Ever wondered how a large, distributed software organization makes decisions about which development framework to adopt? GE Healthcare will be sharing their experiences of managing over 9 global development locations, and supporting a vibrant mix of programming technologies.

We’ll be discussing how to create an n-tiered, component based software architecture that supports their business vision. We will also explore the issue of preparing developers for .NET adoption in terms of licensing, the software roadmap, and key ramp up mechanisms.

In addition, we’ll be analyzing the risks and benefits of adopting .NET at GE Healthcare — what aspects exceeded expectations and what setbacks were encountered along the way. Lastly, the session will explore the road ahead in planning future .NET projects and taking advantage of the many new features available in C# and .NET 4.0.

It promises to be a fascinating session, so don’t miss out — join the live event on Tuesday, October 19th at 11 AM Pacific / 2 PM Eastern. If that time doesn’t work for you, just register now and you’ll be provided with a link to the on-demand version of the event once it has been archived.

Many thanks to the team at GE Healthcare for participating and we hope you enjoy the webcast.

Add this post to:             

I’ve always been interested in the economic impact of software development. While it can be extraordinarily expensive to build out a commercial software application, successful software products can achieve a scale that is simply staggering.

Think about the original code base for Google’s search service or Apple’s iTunes store, for example. Few could have envisaged the explosive growth that would accompany the development of these software services.

Both examples testify that a pure idea, disruptive in its nature and well executed in software, can go a long way indeed.

Technical debt

But it’s far too tempting to believe that you can build the “Next Great App”, ship it, and kick back to watch the revenue rolling in. As we know, the reality of maintaining, fixing, and updating software to support its lifetime value is a massive undertaking.

But is it possible to quantify this burden of “technical debt” — the cost to fix structural flaws that remain in the code when an application is released?

Software quality study

That’s why I was particularly interested in the 2010 CAST Worldwide Application Software Quality Study (link opens a PDF). CAST Research Labs specialize in the study of custom software development and they have compiled a dataset from over 500 applications.

I was really impressed by the range and depth of this study, involving 75 organizations across 8 industry segments. Data were collected over a period of 3 years and drawn from 288 applications built in North America, Europe, and India — it’s fair to say the results are broadly representative of the software industry as a whole.

For a good summary of the CAST report, I’d recommend the following SD Times article titled CAST puts a number on the cost of fixing code quality. The estimated cost to fix problems in an application once it is operational is particularly revealing, and it puts the cost of ownership for software applications into perspective:

If your organization has an application with approximately 374,000 lines of code, you can expect a technical debt of about US$1 million.

Security scores 

I was not surprised to read that COBOL scored highest in security and robustness, given the demands of financial services systems where mainframes dominate the picture. Clearly, mainframe systems are less open and exposed to the myriad of security threats that face web applications.

Perhaps more worrying was the abysmal security score attributed to .NET, with Java not far behind. Far more work needs to be done educating developers in the best practices of building secure applications — it’s no surprise that our web application security training generates plenty of demand from InnerWorkings clients:

Mainframe-based applications are less exposed to the security challenges posed to Web-facing applications. Nevertheless, the lower security scores for other types of applications is surprising. .NET applications received some of the lowest security scores.

Are developers too reactive?

Another key finding of the CAST report is the prevalence of performance concerns in developers’ minds:

It is not uncommon for end-users to complain vociferously to the development team about slow performance, prioritizing the remediation of performance problems over other quality problems such as poor maintainability.

This reactive approach from developers, while perfectly understandable, can lead to increasing technical debt over an application’s lifetime, as less attention is paid to software maintenance problems.

Perhaps the most telling recommendation from the CAST report is for developers to tackle structural flaws and maintenance problems in the development phase:

Time needs to be built in for remediation and refactoring prior to shipping. If you don’t do something about it now and continue to write code, you’re going to continue to build technical debt.

Consider your software legacy

So this CAST report encourages everyone involved in the software industry to consider the legacy of software applications. Don’t overlook the burdens of maintenance that an operational application must bear in order to be successful over its extended lifecycle.

Lastly, the CAST report cautions that software organizations are often unwilling to tackle cost of ownership or code complexity, particularly when an application appears to be running correctly:

In some cases organizations do not want to reduce the complexity of code that appears to be running correctly, even if cost of ownership and time to deliver enhancements could be reduced by refactoring the code. These observations may also identify the need for continued developer training in best design and coding practices.

Training really matters

So let’s not overlook the central take away from this last part of the CAST report — training in application design and best practices have a measurable impact on an application’s lifetime value and total cost of ownership.

I would argue that software executives reading this report should give serious consideration to setting up formal training programs on object oriented development, application security, and design patterns at a minimum.

Now that recommendation is really music to our ears at InnerWorkings!

Add this post to:             

Back in 1994, the Standish Group produced a provocative report which became famous overnight and has been quoted many times in the intervening years to lament the state of the software industry and the billions of dollars wasted on software projects.

Most software vendors with a solution to make things better (InnerWorkings included!) have quoted the Chaos report extensively in a bid for validation and gravitas. Updates to the original report have been eagerly consumed to assess whether new tools, development processes, or project management methodologies were having significant impact on the numbers. Sadly, they never were.

The key findings in the original Chaos report were as follows:

Scientific researchers, government advisers, software methodology groups, and software vendors all used the data to argue for their particular approach – all, it must be said, with the well-intentioned aim of making a dent in the Chaos report’s shocking numbers.

So I paid particular attention to a recent paper by two researchers at Vrije University in Amsterdam called The Rise and Fall of the Chaos Report Figures (please note, this link opens a PDF). The authors, J. Laurenz Eveleens and Chris Verhoef, used their own data — consisting of 5,457 forecasts of 1,211 real-world projects totaling hundreds of millions of Euros — and applied the Standish definitions to them. They then compared their results to the original Chaos report. The paper doesn’t make for an easy read, but the summary is very clear:

Our research shows that the Standish definitions of successful and challenged projects have four major problems: they’re misleading, one-sided, pervert the estimation practice, and result in meaningless figures.

That’s pretty strong stuff!

Misleading Definitions
The Standish Group identified three project categories as the basis for their report:

One of the problems with these definitions is that they don’t cover all scenarios. For example, a project that’s within budget and on-time, but that has less functionality in the final product, doesn’t fit any category. Secondly, the Standish definitions don’t consider a software project’s context, such as its usefulness, profit, or user satisfaction. Context is highly important, but also variable and complex in its measurable impact on the project outcome. So, the authors argue that the Standish definitions are misleading because they’re solely based on estimation accuracy of cost, time, and functionality.

Unrealistic Failure Rates
The next issue is whether the Standish definitions of estimation accuracy are sound. “They are not”, say the authors. This argument unfolds over a couple of pages — between Boehm’s cone of uncertainty, DeMarco’s Estimation Quality Factor and the median f/a ratio, I suggest you tackle this section over a glass of your favorite beverage. It worked for me. The bottom line is that even using accurate forecast data from real-world projects, the authors got only a 59% success rate when the Standish definitions were applied. In other words, the Standish definitions create a bias which exaggerates the negative and swells those shocking project numbers.

Perverting Accuracy
The Vrije University authors obtained data from a large multinational organization comprising 867 IT-intensive projects that began and were completed in 2005 or 2006. They found that the organization’s forecasts were generally higher than the actual project data. After further discussion, they discovered that the organization adopted the Standish definitions as the benchmark to establish when projects were successful. This caused project managers to overstate their project budget requests to increase the safety margin for success and hence skew the forecasts.

Meaningless Figures
Finally, the authors contend that “the Standish figures are meaningless”. Even if a company doesn’t use the key Standish performance indicators, forecasting biases always exist.

Without taking forecasting biases into account, it’s almost impossible to make any general statement about estimation accuracy across institutional boundaries.

Having worked with software R&D organizations for over 20 years, I would agree with that. There follows more f/a plots and median EQFs (and a second glass of wine on my part) to quantify the bias issue.

Meaningless! That’s a tough word, paradoxically itself full of meaning and implication and consequence.

So what’s a poor CEO to do with all of this? I haven’t quite made up my mind yet but I am looking forward to the Standish Group’s response. For the moment, I think I’ll just hide the Chaos slides in my InnerWorkings presentation deck. And that is such a pity because I really do love those ugly numbers!

Add this post to: