Know Before You Count

"Know before you count" is a software development management principle simply stated by Gerald Weinberg as, "Before you can count anything, you've got to know something." He is talking about the many people who count things in software but don't know what they are counting. He provides a great example. We have data concerning what percentage of the software industry is involved with maintenance rather than development. But can we recognize maintenance? Is a "new" development that completely replaces an existing system considered maintenance or development? Is a "modification" to an existing system that doubles current functionality and removes 95 percent of old functionality considered maintenance or development?

When selecting metrics for your project, make sure that what you are measuring relates to what you are trying to achieve. This often entails using multiple metrics. Remember: Even if everybody is measuring something one way, that way is not automatically right for you. Think about your metrics. Since everything can be observed (and in most cases measured), carefully select what you want to observe (and measure).


References:
Stark, G., Durst, R., and Vowell, C., "Using Metrics in Management Decision-Making," IEEE Computer, September 1994.

Weinberg, G., Rethinking Systems Analysis and Design, New York: Dorset House, 1988.

Avoid The Impossible

This may seem like obvious advice. One the other hand, many projects commit to delivering their product on schedules that are 100 percent impossible. Barry Boehm has defined the "impossible region" as a relationship between the expected time to develop a product and the number of person-months (PM) to be consumed. Specifically, the elapsed time (T) from writing a software requirements specification to product delivery will not be less than 2.15 times the cube root of person-months, that is,

If you have a project that is estimated to take 5 person-months then this rule says that the project can't get finished faster than 3.7 calendar months.

Ninety-nine percent of completed projects have obeyed this rule. If you think you can do better then here are some ideas to revisit:

• Productivity and quality are inseparable
• Every complex problem has a solution

Reference:

Boehm, B., Software Engineering Economics, Englewood Cliffs, NJ: Prentice Hall, 1981.

Software Cost Estimation Methods

Numerous cost estimation methods are available commercially. Each is based on data collected from a large set of completed projects. Any of these methods can be used to generate ball park estimates for your software development project. To use them to generate more accurate estimates, you must tailor them to your work environment. This tailoring adapts the model to your type of applications and tools. It eliminates variables that are invariant in your environment. It adds variables that are productivity-influential in your environment.

Chapter 29 of Barry Boehm's Software Engineering Economics explains in detail how to tailor the Constructive Cost Model (COCOMO) to your environment. Similar tailoring guidance is provided with other cost estimation methods. You must fully embrace the spirit of such tailoring, or you will end up with dismally inaccurate results.


Reference:
Boehm, B., Software Engineering Economics, Englewood Cliffs, NJ: Prentice Hall, 1981.

Enneagram Test

A year ago I took an online Enneagram test. My top two personality types were:

1. The Achiever
2. The Perfectionist

Is it all mumbo-jumbo? Is it accurate? I don't know but that doesn't mean it can't be helpful. It is a good way to practice some self-reflection. It can act as an aid to give me some points to consider. You might find it fun to read the core values for each of the Enneagram types and consider which you most closely align with. Or try to develop your own core values. Doing so from scratch is a fairly difficult thing to do. There is nothing wrong from taking what you agree with from each of the Enneagram types.

Our beliefs change over time so it is valuable to test ourselves on occasion. I know my political beliefs have changed. The funny thing is that my friends noticed more quickly than I did. We hold onto labels even though our beliefs change and the labels become inaccurate.

Collect Data Unobtrusively

Data collection is extremely important to help with future cost predictions, to assess the current state of a project or organization, to assess the effect of a change in management, process, or technology, and so on. On the other hand, data collection in an obtrusive fashion -- for example, if it requires software developers to do considerable extra work -- is meaningless because its collection affects the data itself. Furthermore, data collected from developers who do not want to provide such data will likely be useless because it is unlikely that an uncooperative developer will provide meaningful data.

The best way to collect data is automatically, with no developer-perceived interference. Obviously you cannot do this all the time for all data, but you should automate data collection whenever you can. However, you must be careful not to cross any lines concerning privacy. Respect your employees privacy and be transparent about what and how you collect.


Reference:
Pfleeger, S., "Lessons Learned in Building a Corporate Metrics Program," IEEE Software, May 1993.