I’ve just read the speech of Paul D. Nielsen, Director and CEO of the Carnegie Mellon Software Engineering Institute before U.S. House of Representatives.
Very interesting for everyone in the software industry, including the 10 reasons for software acquisitions failures:
1. Technology key to program success is new to the organization
2. Software issues are considered too late in the system-development process
3. Inadequate planning and estimating
4. Size matters – large projects get into trouble more frequently than smaller ones, all projects grow larger over time
5. Software objectives are not fully understood or specified; they change frequently (and grow) during the project
6. Inadequate experiences and trained project management
7. Inadequate process emphasis and erosion of process discipline
8. Inadequate contract incentives to encourage use of proven software engineering practices
9. Acquirers and developers lack experience working as a team or the resources to do so
10. Insufficient senior staff and inexperienced software engineering cadre
In the last 10 years I have found these problems in speeches and presentations, every now and then.
Statistics showed a real improvement in companies that adopted solid models and methodologies. A lot more remain to be done.
I quote what I’ve enjoyed most in the speech:
The “unlimited” complexity of software is neither well understood nor well appreciated by many. Software is not rooted in the physical world like other engineering disciplines–civil, aeronautical, electrical, or mechanical engineering. Without physical constraints, the design space is so vast for large programs that you need strong architectural principles, disciplined processes, and talented people to be successful. The larger the program, the more important this is-and,as you are aware, many defense programs are very large.
Additionally, software is invisible; people don’t buy code – they acquire systems that satisfy requirements. And software is intangible – you can’t touch it or kick its tires. Nevertheless, inmost defense systems, software is critical to the very success of the program. The systems just don’t work without software.
I remember one “funny” experience we had recently in dealing with one of our Government Agencies.
We in Romania have inherited a system in which the company has to paint/stamp an inventory number on each object it owns. So far so good, it doesn’t hurt.
But when that Government Agency requested that we have to paint those inventory numbers on our software, we gasped, and laughed,and choked and got nervous and exploded.
We’ve had this stupid request for years and years in several state owned institutions. Usually we dealt with it by presenting to the bureaucrats a CD or diskette or a licence sheet with an inventory number painted on it. Here Ladies and Gentlemen is your software!!!
This time we debated if we should refuse to obey. Enough is enough. This aberration, a favorite of old bureaucrats, has to stop.Dear all, software is invisible, intangible, is not an inventory object. Give us a break.
Finally, we gave up. Fighting bureaucracy was too much time consuming. We made however a technological progress. At the agency request, we put a label on a computer.
Ladies and Gentlemen, beware, BIS software is inside!