Monthly Posts: July
An Interesting Speech on Software Aquisitions
I’ve just read the speach of Paul D. Nielsen, Directorand CEO of the Carnegie Mellon Software Engineering Institutebefore U.S. House of Representatives.
Very interesting for everyone in the softwareindustry, including the 10 reasons for software aquisitionsfailures:
1. Technology key to program success is new to theorganization
2. Software issues are considered too late in thesystem-development process
3. Inadequate planning and estimating
4. Size matters – large projects get into trouble more frequentlythan smaller ones, all projects grow larger over time
5. Software objectives are not fully understood or specified; theychange frequently (and grow) during the project
6. Inadequate experiences and trained project management
7. Inadequate process emphasis and erosion of processdiscipline
8. Inadequate contract incentives to encourage use of provensoftware engineering practices
9. Acquirers and developers lack experience working as a team orthe resources to do so
10. Insufficient senior staff and inexperienced softwareengineering cadre
In the last 10 years I have found these problems in speaches andpresentations, every now and then.
Statistics showed a real improvement in companies that adoptedsolid models and methodologies. A lot more remain to be done.
I quote what I’ve enjoyed most in the speach:
The “unlimited” complexity of software isneither well understood nor well appreciated by many. Software isnot rooted in the physical world like other engineeringdisciplines–civil, aeronautical, electrical, or mechanicalengineering. Without physical constraints, the design space is sovast for large programs that you need strong architecturalprinciples, disciplined processes, and talented people to besuccessful. 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 – theyacquire systems that satisfy requirements. And software isintangible-you can’t touch it or kick its tires. Nevertheless, inmost defense systems, software is critical to the very success ofthe program. The systems just don’t work without software.
I remember one “funny” experience we had recently in dealing withone of our Governement Agencies.
We in Romania have inherited a system in which the company has topaint/ stamp an inventory number on each object it owns. So far sogood, it doesn’t hurt.
But when that Government Agency requested that we have to paintthose 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 stateowned institutions. Usually we dealed with it by presenting to thebureaucrats a CD or diskette or a licence sheet with an inventorynumber painted on it. Here Ladies and Gentlemen is your software!!!
This time we debated if we should refuse to obey. Enough isenough. This aberation, a favorite of old bureaucrats, has to stop.Dear all, software is invisible, intangible, is not an inventoryobject. Give us a break.
Finally, we gave up. Fighting bureaucracy was too much timeconsuming. We made however a technological progress. At the agencyrequest, we put a label on a computer.
Ladies and Gentlemen, beware, BIS software isinside!