Methods & Tools Software Development Magazine

Software Development Magazine - Project Management, Programming, Software Testing

 

Methods & Tools - News, Facts & Comments Edition - May 2002

*** Companies ***********************************************************

* Some Vikings for Breakfast

Microsoft has announced at the beginning of this month that it will acquire the Danish business software house Navision for $1.3 billion. Navision has 1'300 employees in 30 countries. It is specialized in enterprise resource planning (ERP) and customer relationship management (CRM) applications. In December 2000, Microsoft already acquired Great Plains Software, a US company also active in the ERP area. This acquisition is the second largest in Microsoft's history.

In its quest to fuel growth without alarming antitrust authorities, Microsoft is currently targeting two main areas:

- gaming with the Xbox machines and associated software

- business software for small and medium sized companies

With the acquisition of Navision, Microsoft is entering the European ERP market where Great Plains has little presence. This could be explained because a European company is more aware of the multiplicity of languages, currencies and tax issues related to a fragmented marketplace. I believe that integration and synergies in this area will take some substantial time. Navision's products will however surely benefit from the financial and marketing strength of its new owner. It is another reminder for all developers of Windows-based applications that their cooperation with Microsoft can turn into competition very rapidly. Their only hope is that their market remains small enough... so that the Redmond giant is not interested in entering it!

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

* Hewlett-Packard Compacted

After eight months of preparations and legal battles, the merger between Hewlett-Packard and Compaq has been legally closed, despite the strong opposition from the Hewlett family. Its HP Services group will have a workforce of around 65'000 employees worldwide.

The size is impressive and should make the new HP a serious competitor for other global IT services companies like IBM, EDS or Accenture. Service is considered the high margin/fast growing segment of the IT industry and the keyword to offer "solutions" instead of just "boxes". This is one of the main reason why HP merged with Compaq that had already bought Digital Equipment Corporation (this seems soooooo far away in time...:-]) I think however that HP is lighter than its competitors in the business side of services. I will not be surprised if HP will acquire in a near future large or small "pure" consulting companies.

*** Numbers *************************************************************

* Software Metrics Best Practices

The KLCI Research Group recently published the results of its annual survey focused on the usage of metrics in software development. The study offers interesting numbers on the practice of "Best Practices" organisations. These are respondants (45%) that rate metrics as either an important or an integral part of their software development activities.

Here are some results differencing "Best Practices" organisations from others:

Best Practices  Others
CMM Level 2 or above 56% 27%
Spending on measurement
(% of IT budget)
 4.2%  1.8%
Positive impact of metrics  90% 47%
Important part of metrics in decisions 81%  34%
Number of measurements 7.7 3.7
Number of metrics tools used 2.1 1.4

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

August 2019
June 2019
May 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
November 2009
October 2009
August 2009
May 2009
April 2009
February 2009
January 2009
November 2008
October 2008
August 2008
May 2008
April 2008
February 2008
January 2008
November 2007
October 2007
August 2007
May 2007
April 2007
February 2007
January 2007
November 2006
October 2006
August 2006
May 2006
April 2006
February 2006
January 2006
November 2005
October 2005
August 2005
May 2005
April 2005
February 2005
January 2005
November 2004
October 2004
August 2004
May 2004
April 2004
February 2004
January 2004
November 2003
October 2003
August 2003
May 2003
April 2003
February 2003
January 2003
November 2002
October 2002
May 2002
April 2002
February 2002
January 2002
November 2001
October 2001
May 2001
April 2001
February 2001
January 2001
Winter 2000
Fall 2000

Software Testing
Magazine


The Scrum Expert