I can think a few reasons for “why not”, from the executive’s point of view. Not wishing to have too much of a negative spin on this, I think there is at least one good instance where companies should share software process data.

1. Dashboards vs. Scorecards.
2. Executives swamped with information.
3. Pension funds considering working environment of employees.
4. Usual cultural obstacles of any measurement program.
5. Know your strengths.
6. Company to Company Use.

1. Dashboards vs. Scorecards
I suspect dashboards would just too lower-level of detail for public company executives and shareholders. The executive of a public company is probably more concerned with a consolidation for all projects, to evaluate the portfolio’s/program’s alignment with things like business objectives and business performance requirements. I’ve seen Scorecards in big corporations that get used to relate of all a company’s business areas to annual objectives. And as messrs Kaplan & Norton say “scorecards should be balanced to avoid local optimization of only one target”. (Sounds like “avoiding local optimums” from Eli Goldratt’s Theory Of Constraints.)

2. Executives Swamped with Data/Information
Maybe the executive of the aforementioned public company is already drowning in data? There’s an article by Andy Kelly on “Performance measurement: the new crisis” in the three inch thick “Financial Times Handbook of Management” (p.260). This article claims too much is being measured in organizations. It discusses the work by Price Waterhouse Coopers on its value reporting initiative (www.valuereporting.com).

3. Effects of Pension Funds and Their Purchase of Shares
So, the executive is drowning in data and the shareholder (with a portfolio of shares to spread financial risk) is not going to notice an extra page in the several 100 page annual reports. Is there any hope? It would appear, according to the Gallup Organization, that institutional investors such as the California Public Employees Retirement System who “define the agenda for the business world” are now beginning “to pay much closer attention to how companies treat their people”. Imagine if public companies did start to publish application development data which showed their knowledge workers worked in a more stress-free environment because of new technology introduced which reduced the amount of rework and other time wasting activities? Might attract one of these trillion dollar stock market investors, who do read annual reports from cover to cover.

4. Usual Cultural Obstacles of any Measurement Program
There is a plethora of “soft issues” to take into account with any measurement program implementation.
e.g. starting a measurement program is very difficult, as it implies culture change towards visibility and accountability for results. (Often measurement programs fail because middle and senior management is not capable dealing with the visibility gained and trust needed to make metrics successful.)

Many of these “traps for young players” can be overcome by learning from best practices embedded in ISO/IEC 15939 : Software Engineering - Software Measurement Process. This is a standard for help in implementing a software measurement process.
For more info, see http://www.psmsc.com/ISO.asp

5. Know Your Strengths
Just digressing here. On the subject of “soft issues”, there’s a book by Gallup called “Now, Discover Your Strengths”. It states so many people have overcome weaknesses by being incredibly talented & strong performing in other areas. Consider the history of the playwright Cole Porter; he bet if he kept on polishing his strengths as a song writer, very soon the audience simply wouldn’t care that his plots were weak and his characters stereotypical.

I wonder if unit testing becomes so effective with Agitar’s technology it overcomes other weaknesses in the rest of the software development process?

6. Company to Company Use
Sharing of test-related data could work between one public company and another public company. One instance of where such practice is needed is on those large systems engineering projects. (Typically where there’s one software-intensive sub-system.) Test data from a principle contractor should be shared with a prime contractor. The prime contractor in turn would share this with the client. All in the name of “confidence boosting”.

Terms of Use