The most commonly used metrics are schedule metrics (59%), lines of code and requirement metrics (49% each). Microsoft Excel is the tool used regularly by most of the respondents (63%) to capture and analyse data.

To download the complete report, go to www.klci.com

*** In Other's Words ****************************************************

* Mars and Venus in Software Development

"There is antagonism and distrust between product and process engineers, and they frequently work at cross-purposes to each other. Product engineers can drive process engineers crazy with comments such as the following:

- We thought up some cool new features and added them over the week-end

- We'll fix the bug in beta

- We don't have time to test

- We're behind schedule, we don't have time for team meetings

- We're going to start coding the stuff we know and design the rest on the fly

- We could make the current schedule if we could add five new developers

Likewise, process engineers can drive product engineers crazy with questions such as:

- I know this is short notice, but can we schedule an ISO audit with you next week?

- Can you fold time for training the developers for an IPI-CBA?

- Can you show me all your quality records?

- How many KPAs have you implemented?

- Can you show me all your meetings minutes over the last year?

- What is your quality policy?

What appears glaringly obvious to one group leaves the other's members shaking their heads, wondering what planet they came from.

However, a company's survival depends on both groups' contributions. Product engineers focus on building the product and "present" goal of getting that product out the door. Process engineers tend to focus on engineering the product development effort, assessing the "as is" activities with the goal of finding opportunities to improve the process in the near future. You can see how these two groups might annoy each other. Product engineers find the process work irrelevant and distracting, and process engineers find product engineers arrogant and evasive.

To help these two groups work more cooperatively and constructively, each group must understand the other's perspective. No one would argue the product developer's ultimate value. Most companies wouldn't exist without products. Product engineers are frequently under incredible time pressure to hit a market window or a specific deadline. Having time to step back and engineer the development process seems like a wasteful luxury. If a developer's management doesn't value process engineering and improvement, it's a nearly impossible task for a process engineer to engage with the product engineers simply because it's not rewarded behavior. On the other hand, the process engineer's value is not as self-evident."

Source: Karen Mackey, "Mars versus Venus", IEEE Software, May/June 2000

Based on the same approach the best-selling book "Men are from Mars, Women are from Venus", I think this text in an interesting basis to think about the quality of the software development process.

-------------------------------------------------------------------------

* People first

"Question: Process is a hot topic in the software development community at present. We have RUP, Open, Catalysis, XP [eXtreme Programming] etc., all of which seem to offer something of a contradictory view of the world. What is the average software developer or manager supposed to make of this? Is there such a thing as a right and a wrong approach to software development?

Answer: Yes, there is. The right approach is the one that gets the job done with a minimum of fuss. Kent Beck makes an astute observation about processes. Process is about managing fear. We put processes in place because we are afraid. If our fear is large, we put big processes in place. If our fear is small, we put little or no process in place. The process that is right for a given team is the process that balances their fears against their ambitions.

XP is a process for the ambitious team that wants to get to market fast. XP manages fear by using people methods rather than paper methods. In XP, the fear of speed is mitigated by working in pairs, writing lots of tests, communicating with the customer on, at least, a daily basis.

Question: So lack of process is not the reason for software failures that have motivated larger process. Where would you pin the blame then?

Answer: The processes in use today focus upon paper rather than people. Paper can't think. Paper can't solve problems. Paper can't adapt to change. We can schedule all the reviews we want. We can produce all the analysis and design documents we want. We can coordinate and cross check and plan all we like. But as long as people are considered second order elements of the process, the process will fail.

Alistair Cockburn says it best. Process is a second order effect upon success. The first order is people. XP focuses upon people. It provides a framework within which people can communicate effectively. As Kent Beck says, XP is an attempt at making it OK to tell the truth."

Source: Mark Collins-Cope, "Interview with Robert C. Martin - eXtreme Programming", ObjectiveView number 4, www.ratio.co.uk

Another contribution to the "people versus process" debate. Our Fall 2002 issue will present some articles from the process viewpoint.

===========================================================

The content of this publication cannot be reproduced without prior written consent of the publisher - Copyright ã 2002, Martinig & Associates