In hosting these webinars, our goal is to make common software management issues as real as possible and to offer thoughts and strategies that might be relevant to you in your work. We are also keen to share “war stories” that make the issues come alive. We’re extremely lucky to have Cerner’s Matt Anderson and Ryan McKenna joining us for this webinar. They were both deeply involved in the project to migrate a key product from a legacy system to the .NET framework and the challenges associated with that process.

When I do my own preparation for these webinars I like to find an angle that allows me to open the issues up. For this webinar, I discovered a Department of Defence white paper on Legacy System Migration Guidelines. Since DoD systems contain a substantial amount of legacy software and they have worked with many vendors to carry out migrations, they have evolved 10 guidelines which are built on lessons learned from actual legacy system migrations. On first reading, some of these guidelines are blindingly obvious. For example, guideline #1 recommends that you “Develop a comprehensive strategy with achievable and measurable milestones for each reengineering project”. Indeed — you don’t need to be a rocket scientist to agree with that one!

But some of the guidelines, when matched with the key approaches of the Cerner strategy, are really quite interesting and thought provoking. A couple of weeks ago, I spent a day with Cerner in Kansas City at their Innovation Center. We allocated one session to preparation for the webinar on Legacy System Migration to .NET. I was very struck during the meeting by the “Like-For-Like” strategy adopted by Cerner for the project. It’s not as simple as it sounds. Just think about it — you have a core product with many customers and users. It is a key revenue generator for the company. It has been developed over years. Now you need to move it to a new technology base. You decide on a “like-for-like” strategy, which means matching function for function, feature for feature. An ideal outcome would mean that users are not even aware of the change. But we all live and work in software. We know how products develop, how the outcome can change – sometimes in unexpected ways.

Then compare this decision with guidelines 4, 5 and 6 from the DoD white paper:

Guideline #4: Establish and maintain configuration management control of the legacy system
Guideline #5: There should be a carefully defined and documented process for the elicitation and validation of requirements
Guideline #6: Make software architecture a primary reengineering consideration

These three guidelines raise a ton of questions for me, which make the project, and decision-making around it, come alive. For example,
1. How are requirements for the new system documented?
2. Is the original architecture still valid under the new technology?
3. If not, what needs to change and what implications does it have for the project?
4. Does anything get dropped in the new system? What about the little funky features that wend their way into all products?
5. What about improvements and new features? Do they wait until the migration is done?

During the live webinar on April 14th, I will also ask our guest speakers about DoD guideline #3, which is near and dear to our hearts at InnerWorkings:

Guideline #3: If new technology is used for a project, provide adequate training in both the technical content and the motivation for change

The list of questions could go on – but the point is that these are real migration issues that Cerner grappled with, decided upon, and then executed against.

It is worth noting that Cerner’s migration project is complete now so we will also be able to talk about specific outcomes and lessons learned. The webcast will run for about 40 minutes and we will have a live Q&A after that where you can ask your own questions. So do join us. It promises to be a really interesting session.

As the title suggests, the day was intended to showcase Ireland as a leading research & development hub for the new technologies that will shape the 21st century.

Among the topics discussed were the key factors influencing countries’ competitiveness in this century and the commitment required to fund core R&D, if jobs are to be created and protected in the face of rising global competitiveness.

Last weekend, I watched Fareed Zakaria’s GPS program on How to restore the American Dream (link opens podcast) so I was well primed for the urgency of the main topics. (This, by the way, is a program well worth watching and I will return to it in my next blog. While you’re at it, read his recent article of the same title in Time magazine.)

Ireland, through the IDA, has done a very good job in the past 30 years of attracting large American corporations to establish their European hubs in the country. The incoming companies mirror the latest technology trends — the first wave brought global manufacturing companies like Siemens, Johnson & Johnson and Pfizer; did you know that all the Viagra in the world is manufactured in Ireland?

Technology giants like HP, Microsoft, and Intel came next, followed by global players in the biotech and financial services sectors. Today, companies such as Google, LinkedIn, and Facebook all have a significant presence in Ireland.

The fierce urgency of a small country’s need to stay competitive drives the strategy and is largely unobstructed by the different political philosophies at home. I think it is a good example of what can be achieved across normal political divides and the short-term thinking that drives day-to-day politics in any country.

The overarching vision is held in a government policy document called the Strategy for Science, Technology and Innovation 2006-2013 (link opens PDF) which determines the direction and priorities. Two government agencies, backed by an array of state and private organizations, take the focus for implementing the policy decisions.

One agency, IDA Ireland, goes out to the global innovation centers and tries to attract the top companies to Ireland. A second agency, Enterprise Ireland, works in the opposite direction — connecting young and innovative Irish companies to the global markets.

It is a long-term approach which costs money and has to survive government change. I assume there is wastage in the system but it is impressive in its coherence and in its transparency.

So what were the key themes at the Ireland R&D Showcase? What jumped out for me was the central role of education. We are now moving into an era of highly complex and specialized research — nanotechnology, photonics, next-generation networks, cloud computing and so on.

Nations need to make the financial commitments to fundamental research on emerging technologies and knowledge domains. This research will drive the businesses and jobs of the future.

The next R&D wave is coming, and we all need to pay close attention to stay competitive. It has implications not just for countries but also for companies whose revenues depend on created intellectual property.

I was particularly impressed with the work of two research institutes attached to two Irish universities. One was CRANN, attached to Trinity College Dublin. This institute works across the research spectrum of nanotechnologies, from the development of new nanomaterials with improved mechanical, magnetic, electrical or optical properties to their subsequent application in electronic or medical devices, sensors, or new drug delivery systems.

The second was the Tyndall Institute, attached to University College Cork. The focus here is in the areas of photonics, electronics, and materials, as well as nanotechnologies, and their applications for life sciences, communications, power electronics and other industries. Both are world-class institutes, attracting top scientists from around the world and working closely with international market-leading companies to commercialize the latest research.

It was also impressive to me that Ireland, in the teeth of the biggest economic meltdown in the country’s history, was staying firmly focused on long-term success for its people.

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

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!

“It takes dozens of microprocessors running 100 million lines of code to get a premium car out of the driveway, and this software is only going to get more complex.” ROBERT N. CHARETTE, IEEE

Those of you familiar with InnerWorkings will know that we talk about helping our customers “build great software organizations”. The core elements of our company vision include a focus on developer skills, individual and team productivity, as well as rigorous software processes, with the objective of helping our customers build software of very high quality.

Producing high quality software products requires a high performing organization at every stage of the development life cycle. Inherent in all of this is the notion of “consistency”. Faced with the staggering ubiquity and the complexity of contemporary software implementations, organizations building software need to be consistent on a global scale. They need to have common practices across distributed teams, better means of collaboration, more visibility into their capabilities, and ways of establishing baselines as the basis for measured improvements.

There is just so much software out there now and its footprint will continue to increase over time. The cost of fixing stuff when something goes wrong is horrendous. Just to compete, the standards in software companies need to be higher and higher.

I was reminded of this forcefully while reading the article This Car Runs on Code — my thanks to Paul Kedrosky for bringing it to my attention. Here are some of the key facts stated in this fascinating article:

It isn’t just the automotive industry that is experiencing the effects of software ubiquity, however. This trend is occurring in so many industries today – think about the expanding role of software in the military, aviation, and financial services industries for example. Software is everywhere and its influence is extending into every dusty corner of the modern economy.

In this context, it’s clear (to me at least) that software quality can no longer be treated in an ad-hoc way or left unmeasured as it often is today. There is simply too much economic activity and underlying business value at stake. Every organization, from a small business to a large enterprise, needs to put into place scalable, repeatable and data-driven processes and commit to them. Just to stay alive.

For those of you who don’t know Safari, let me give you a little background. Safari Books Online was created in July 2001 as a joint venture between the publishers O’Reilly Media and Pearson Education. The Safari libraries now contain more than 4,875 titles for programming and IT professionals. As well as the very popular O’Reilly titles, the Safari libraries include titles from Addison Wesley, Sams, Peachpit Press, Microsoft Press, Que, Prentice Hall and many other publisher partners. Most recently, Wiley has been added into the mix.

The content teams here at InnerWorkings take the best and most relevant of these titles and embed them into our drills in a context-sensitive way. This provides you with richer, more extensive reference and support. And,as usual, our thinking is that all of this material is available to you not just while you ‘learn’ but also as you work day-to-day on real projects. Combining the strengths of InnerWorkngs and Safari Books Online continues our committment to bulding the most powerful learning tool for developers everywhere in the world. In the months ahead, you will see further developments between our companies. For now, just enjoy!

much discussion this little indicator provokes. The intention behind it is simple - we want to let you know how much coding time you can expect to spend completing the task. And it is a pretty good measure - as I write this, the average coding time per task when calculated for all tasks in our catalog across our entire customer base is 29.7 minutes. (Thanks to Seamus Brady, our Head of Platform Infrastructure, for this data!)

The discussion arises because of a subtlety in its phrasing. It says “coding” time and that is what it means. It doesn’t try to take into account any other time you might spend on the task. We don’t try to prejudge the amount of time you might spend researching, reading or just thinking about the problem and its solution. This will vary from developer to developer, depending on your knowledge and on your experience level with the material you are working on.

One of the unintended consequences of this is that users sometimes feel under pressure to complete. It is common for us to get feedback indicating that it took much longer to complete the task than the 30 minutes indicated. There are a couple of things I would say about that:

1) That’s fine. This is a learning environment. Take as long as you need to learn. It is not intended to put you under pressure - merely to give you an indication of the amount of coding work involved.

2) Go back a couple of days after you have completed the task and do it again. See how long it takes you. Repeating the task solidifies the learning. This is a practice environment. The goal is to help you master application of the technique you are learning.

However, the feedback provokes a lot of discussion here in InnerWorkings. Opinions vary from changing the message to eliminating it altogether to variations in between. I would be very interested in hearing your thoughts on this.

1. We don’t teach syntax. We assume that you are a working developer, a practitioner. We don’t try to recreate the many resources and methods (classes, books, e-learning courses) that are available for beginners. There are so many great things out there at that level and, anyway, it isn’t really the issue we are interested in. We are VERY interested in the next stage and in the stages after that.

2. It’s not really about ‘passing’ the code judging engine. Of course, at one level it is, but that is not the really significant part. The point is to help you develop your capabilities (and career) by having you solve problems in Visual Studio as you do, day-to-day, on projects. The significant part is the work you do while working on those problems. The outcome is the validation (to yourself or to others) that you can apply the techniques appropriately and efficiently. Building higher levels of performance and problem-solving.

Irrespective of the feedback, we really like to get it. We give it a lot of attention so please keep it coming!