Understand The Customers' Priorities

It is quite possible that the customers would rather have 90 percent of the system's functionality late if they could just have 10 percent of it on time. The corollary of the principle of communicate with customers/users is quite a bit more shocking, but it could very well be the case. Find out!

If you are communicating with your customers, you should be sure you know their priorities. These can easily be recorded in the requirements specification, but the real challenge is to understand the possibly ever shifting priorities. In addition, you must understand the customers' interpretation of "essential," "desirable," and "optional" and prioritize the requirements accordingly. Will they really be happy with a system that satisfies none of the desirable and optional requirements?


Reference:
Gilb, T., "Deadline Pressure: How to Cope with Short Deadlines, Low Budgets, and Insufficient Staffing Levels," Information Processing, Amsterdam: Elsevier Publishers, 1986.

Don't Believe Everything You Read

As a general rule, people who believe in a particular philosophy search for data that supports that philosophy and discard data that does not. Someone who wants to convince others of a position obviously uses supportive, not unsupportive, data. When you read, "Use method X. You too can achieve up to 93 percent increases in productivity (or quality)," the method may really have achieved such results. But it was probably the exceptional case. In all likelihood, most projects experience far less dramatic results. And some projects may even experience decreased productivity using method X.


Reference:
Fenton, N., "How Effective Are Software Engineering Methods?" Journal of Systems and Software, August 1993.

Good Management Is More Important Than Good Technology

Good management motivates people to do their best. Poor management demotivates people. All the great technology in the world will not compensate for poor management. And good management can actually produce great results even with meager resources. Successful software startups do not become successful because they have great process or great tools (or great products for that matter!). Most have been successful because of great management and great marketing.

As a manager, you have a responsibility to do your best. There are no universally "right" styles of management. Management style must be adapted to the situation. It is not uncommon for a successful leader to be an autocrat in one situation and a consensus-based leader in another, just a few minutes later. Some styles are innate. Others can be learned. If necessary, read books and take short courses on management style.


Reference:
Fenton, N., "How Effective Are Software Engineering Methods?" Journal of Systems and Software, August 1993.

Don't Take Errors Personally

Writing software requires a level of detail and perfection that no human can reach. We should dedicate ourselves to constant improvement, not perfection. When an error is detected in your code either by you or by others, discuss it openly. Instead of castigating yourself, use it as a learning experience for yourself and others.


Reference:
Gerhart, S., and Yelowitz, L., "Observations of Fallibility in Applications of Modern Programming Methodologies," IEEE Transactions on Software Engineering, Sept 1976.

Analyze Causes For Errors

Errors are common in software. We spend enormous amounts of resources detecting and fixing them. It is far more cost-effective to reduce their impact by preventing them from occurring in the first place. One way to do this is to analyze the causes for errors and they are detected. The causes are broadcast to all deverlers with the idea being that we are less apt to make an error of the same type as one whose cause was thoroughly analyzed and learned from.

When an error is detected there are two things to do: 1) Analyze its cause and 2) fix it. Record everything you can about the cause of the error. This is not just technical issues like, "I should have checked the passed parameter for validity before using it" or "I should have found out if I needed to execute the loop n or n-1 times before I gave it to integration testing." It is also management issues like, "I should have desk-checked before unit testing" or "If I had let Ellen check the design to see if it satisfied all the requirements when she wanted to, ..." After collecting all this information, broadcast it, letting everybody know what caused the errors, so that such knowledge can become more widespread and such errors can become less widespread.


Reference:
Kajihara, J., Amamiya, G., Saya, T., "Learning from Bugs," IEEE Software, Sept 1993.

Instrument Your Software

When testing software, it is often difficult to determine why the software failed. One way of uncovering the reasons is to instrument your software, that is, embed special instructions in the software that report traces, anomalous conditions, procedure calls, and the like. Of course, if your debugging system provides these capabilities, don't instrument manually.

Reference:
Huang, J., "Program Instrumentation and Software Testing," IEEE Computer, April 1978.

Rust by Jonathan Waldman

Rust: The Longest War by Jonathan Waldman
My rating: 5 of 5 stars

Rust (corrosion) is a constant companion to all life on Earth. It seems to happen so slowly that we fool ourselves into thinking that we can deal with it later. This book covers corrosion across the range of human experience. It interesting due to how tremendous of an impact corrosion has on modern life. A lot of the book is detailed and filled with facts. It slowed my reading down as I tried to absorb and remember information.

View all my reviews

Who Goes There

Who Goes There? by John W. Campbell Jr.
My rating: 5 of 5 stars

An excellent short book for October as Halloween quickly approaches. A lot of the language describing the shapeshifting alien so much reminds me of how they described and detected for Changelings in Star Trek: Deep Space 9 that I suspect that those writers were also fans.

View all my reviews

Don't Integrate Before Unit Testing

Under normal circumstances components are separately unit-tested. As they pass their unit tests, a separate team integrates them into meaningful sets to exercise their interfaces. Components that have not been separately unit-tested are often integrated into the subsystem in a vein attempt to recapture a lost schedule. Such attempts actually cause more schedule delays. This is because a failure of a subsystem to satisfy an integration test plan may be caused now either by a fault in the interface or by a fault in the previously untested component. And much time is spent trying to determine which is the cause.

If you are managing a project, you can do a variety of things to avoid this situation. First and foremost is to develop an integration test plan early (for example, very soon after high-level design is complete). This plan should specify which components are most important to integrate first and in what order components may be integrated. Once you have written this down, allocate appropriate resources to coding and unit testing of specific high-priority components to ensure that integration testers don't spend an inordinate amount of time idle. Second, as it becomes evident that important components for integration testing are going to be unavailable as needed, have the integration testers start developing temporary scaffolding software to simulate the missing components.


Reference:
Dunn, R., Software Defect Removal, New York: McGraw-Hill, 1984.

Angle of Attack

I've been reading Flying Beyond the Stall: The X-31 and the Advent of Supermaneuverability by Douglas A. Joyce. Very quickly what struck me was that the issue that caused the X-31 to crash in 1995 was incorrect Angle of Attack (AoA) sensor data causing the software to override the pilot and crash the plane. Which was the same thing that happened to the Boeing 737 Max planes that crashed.

Maybe it is because I'm getting older but I'm getting more and more concerned about how the Tech industry forces older engineers out and tries to replace them with entry-level programmers. This isn't an natural issue of passing the baton. This is an issue of trying to replace highly skilled and experienced people with minimally skilled and no experience people.

So many of the software issues that we fight today have already been solved. If we just take the time to learn from the past then we could avoid repeating these mistakes.