A Few Good People Are Better Than Many Less Skilled People

This follows immediately from the idea that People Are The Key To Success, which says that you should always hire the best engineers. This principle says that you are better off allocating just a few good, experienced engineers on a critical task than to put many inexperienced engineers on it. This is Don Reifer's "Management Principle #6." On the other hand, Manny Lehman warns that you can't rely too much on "a few good people"; what if they quit? The best advice is to have the right mix of people on a project and take care not to gravitate towards either extreme. Those people with the most experience are probably closest to retirement. Keep them working with people with less experience so their knowledge isn't lost in the future.


Reference:
Reifer, D., "The Nature of Software Management: A Primer," Tutorial: Software Management, Washington, DC: IEEE Computer Society Press, 1986.

People Are The Key To Success

Highly skilled people with appropriate experience, talent, and training are key to producing software that satisfies user needs on time and within the budget. The right people with insufficient tools, languages, and process will succeed. The wrong people (those with insufficient training, experience, or work ethic) with appropriate tools, languages, and process will probably fail. According to the Constructive Cost Model (COCOMO), the best people are 4 times more productive than others. If the best people cost 4 times the salary, you break even and probably end up with a better product (Great Designs Come From Great Designers). If they cost less, you reduce costs and have a better product. That's a win-win.

When interviewing prospective employees, remember that there is no substitute for quality. Companies often say, after interviewing two people, "Person x is better than person y, but person y is good enough and less expensive." You can't have an organization of all superstars, but, unless you have an overabundance of them now, hire them!


References:
Boehm, B., Software Engineering Economics, Englewood Cliffs, NJ: Prentice Hall, 1984.
Weinberg, G., The Psychology of Computer Programming, New York: Van Nostrand Reinhold, 1971.

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