Methods & Tools Software Development Magazine

Software Development Magazine - Project Management, Programming, Software Testing


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

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

* Borland Looks for Growth

In the last edition, we wrote about WebGain selling its assets to bigger fishes. This time, the "Consolidation of the Day" section features Borland acquiring smaller companies. At the end of October, Borland signed an agreement to acquire TogetherSoft, the producer of the ControlCenter modelling tool. It is interesting to notice that TogetherSoft acquired WebGain Studio in August. At the beginning of the month, Borland already announced the purchase of Starbase. After these acquisitions, Borland expects 2003 revenues between $355 and $370 millions. Finally, Borland released version 8 of its JBuilder development environment at the beginning of November.

Even if economic conditions do not seem to be favourable for expansion, Borland takes the opportunity to strengthen its franchise in the software development sector, using its good financial health. After a momentary leaps of reason when it tries to evolve with a new name (Inprise) and a new main product (Visibroker), Borland has gone back to its root of producer of solid software development tools. The acquisition of TogetherSoft is particularly positive as it will give Borland a solid UML modelling tool to complete its offer, which is more code-oriented.

Disclaimer: the editor has learned to program with Turbo Pascal and Turbo Prolog... :-]


* The Commercial Face of Open Source Software

Oracle announced at the beginning of this month that it will join the Eclipse board, an IBM-led open-source IDE effort. Besides IBM, current board members include companies like Hewlett-Packard, Borland, Rational, MKS, Sybase, Red Hat or Suse. Oracle will also propose a single API to access multiple vendors Java-based IDE.

Eclipse is an attempt to provide a platform for tool integration. Why do the days of AD/Cycle seem so far away? These times tools will not be integrated in a common encyclopaedia, but as plug-ins for the platform. Sun has its own platform project called NetBeans. Oracle API proposal would like to build a bridge between Eclipse and NetBeans and I think this uncertain effort will take time to succeed. This illustrates also the specific situation of industry-funded open source efforts. These initiatives have more resources and could be more widely accepted by "mainstream" development organisations. On the other end, they are also influenced by commercial strategies.

You should however not dismiss the interest of such tools that will allow specialised companies to propose specific solutions that will work in a framework with clear integration specifications. For more info, look at and

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

IT Small Players

Here are the ranking of some IT related organisations in the 2002 Global Fortune 500 list (based on 2001 figures):

Company Revenues ($million)

1. Wal-Mart Stores 219'812

2. Exxon Mobil 191'581

19. IBM 85'866

70. Hewlett-Packard 45'226

88. Fujitsu 40'043

117. Compaq 33'554

131. Dell Computers 31'168

175. Microsoft 25'296

213. Cisco 22'293

221. EDS 21'543

268. Sun Microsystems 18'250

380. Accenture 13'347

443. Computer Sciences 11'426

464. Oracle 10'859

Source: Fortune Europe Edition, August 19, 2002-11-09

Sure that it hurts poor Larry Ellison that Oracle is only number 464 with 10 billion of revenues. But I think that the biggest pain should come from the fact that Microsoft is number one in profit margin (for 2001) with a hefty 29%. Oracle is not far behind, being number five with 23.6%.

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

* Cautious Agility

I believe that both agile and plan-driven approaches have a responsible center and overinterpreting radical fringes. Although each approach has a home ground of project characteristics within which it performs very well, and much better than the other, outside each approach's home ground, a combined approach is feasible and preferable.

Compared to unplanned and undisciplined hacking, agile methods emphasize a fair amount of planning. Their general view, though, places more value on the planning process than the resulting documentation, so these methods often appear less plan oriented than they really are. Although hard-core hackers can use agile principles to claim that the work they do is agile, in general these methods have criteria, such as Extreme Programming's 12 practices, that help determine whether an organization is using an agile method or not.

Another encouraging trend is that the buzz of agile methods such as XP is drawing many young programmers away from the cowboy role model and toward the more responsible agile methods.

The price that XP pays for this benefit, however, is reluctance by more conservative managers to sanction a method called "extreme".

When you work with premium people, Highsmith and Cockburn's statement that "A few designers sitting together can produce a better design than each could produce alone" rings true. Without premium people, however, you're more likely to get a design-by-committee mess. A significant consideration here is the unavoidable statistic that 49.9999 percent of the world's software developers are below average.

This is not to say that agile methods require uniformly high-capability people. Many agile projects have succeeded with mixes of experienced and junior people, as have plan driven projects. The main difference is that agile methods derive much of their agility by relying on the tacit knowledge embodied in the team, rather than writing the knowledge down in plans.

When the team's tacit knowledge is sufficient for the application's life cycle needs, things work fine. But there is also the risk that the team will make irrecoverable architectural mistakes because of unrecognized shortfalls in its tacit knowledge. Plan-driven methods reduce this risk by investing in life-cycle architectures and plans, and using these to facilitate external-expert reviews. In doing so, however, they accept a risk that rapid change will make the plans obsolete or very expensive to keep up to date.

Although information technology trends are moving us closer to agile methods' emergent requirements and rapid change home-ground characteristics, increasing dependability concerns call for measures best implemented with plan-based solutions. To meet these disparate needs, organizations must carefully evolve toward the best balance of agile and plan-driven methods that fits their situation.

Source: Barry Boehm, "Get Ready for Agile Methods with Care", Computer, January 2002

Interesting comparison... and introduction to our Winter 2002 issue which will be focused on eXtreme Programming :-) Stay tuned!


* Web Development and Software Engineering

The following pieces are extracted from a roundtable on the applicability to "standard" software engineering ideas to internet-based software development. Even if the dotcom fever has largely disappeared, I think these are still valuable opinions on the web-based software development model and the value of software engineering in general.

Tom Demarco: Each time anything new comes along, its advocates trot out the line, "this changes everything, so our old methods no longer apply." There is always a germ of truth here, or it wouldn't be so seductive; new modes, tools, hardware generations, and so on do require adaptation of method. The part requiring adaptation, however, is usually small compared to what remains applicable particularly when applying pre-Web methods to Web development. There is mostly baby here, very little bath water.

Watts Humphrey: The engineering principles of planning before designing and designing before building have withstood every prior technology transition; they'll survive this transition as well.

Ray Johnson: Time-to-market and many other features of Web development are not unique to Web applications. While overhead is a valid concern, it's not a good reason to abandon basic engineering principles. I've seen Web application builders rely on really smart, really hard-working engineers – the brute force method. However, for projects that are too boring to attract the best engineers (most of them), this model quickly breaks down. It would be better to choose a software engineering model suited for the dynamic, fast-paced world of Web application development.

Ben Adida: The problem is fuzzy. We need an approach that allows for more freedom and flexibility as the project changes. It's similar to engineering F16s when all you've done before is make propeller planes. Sure the main difference is that F16s are faster, and the basic principles of aeronautics still hold, but the engineering approach is completely different.

Ellen Ullman: Every technical generation believes its situation is unique. Web developers believe it today, and before them developers of distributed systems, client-servers, interactive systems, re-entrant code, and so on. Each generation was correct by definition: whatever they were doing was indeed different from the software "conventions" that came before. The support tools they were asked to use were always lagging, always based on preceding technology. So to answer your question directly, no, Internet-based systems cannot be engineered in the "conventional" sense, but then no system based on emerging technology can use the previous generation's conventional engineering tools. In the business of making software, an essential tension will always exist between emergent architectures and engineering "correctness"

Tom Demarco: All systems need to be delivered in record time. Web products are no different, with one exception: the Web is full of glitzy eye-candy pages that convey very little real value. And yes, if you're building eye-candy, you'd better do it quickly. Such cases call for nothing more than hacking. But consider a real Web-based system such as Alta Vista or E-Trade or the FedEx dispatch center. Who could argue that such systems don't have to be engineered?

Ellen Ullman: I couldn't agree more. The front end is fluffy, and in some sense it doesn’t matter what tool you use to produce it. Point-and-click baby tools are fine to generate Web-page ephemera. But everything the front end talks to is serious engineering. And since those back-end things are based on older technologies, there are indeed helpful engineering tools to support them. […] I know this is the "right" way to do things, but the start-up companies I work with laugh at me when I suggest something as "bureaucratic" (their word) as a simple bug list. The importance thing to remember about the Web right now is that it's being created by very young people. And if you remember your own youthful ignorance and exuberance (and fearlessness), then you understand why we're having this conversation.

Watts Humphrey: The dynamics of Web-based development allow us to interactively involve users in the requirements process. This could help us quickly develop products that closely fit customer needs. When we can instantly distribute products world-wide, however, we must learn to quickly produce quality products. The current test-based approach to software quality takes too long, and will almost certainly be unacceptable in the Web-based future. Software testing can take months, and even then many defects remain. We should learn from other fields – no other discipline uses testing as the principal way to find and fix product defects. By tracking all defects, determining their costs, and learning how to detect or prevent them, other technologies have improved quality, cut costs, and saved time. […] Ray, of course you must test, but you just can't rely on testing to get quality. With the Web, it is still true that if you don't put a high-quality product into test, you won't get one out.

Ray Johnson: Fred Brooks, in The Mythical Man-Month, points out that the best programmers are almost an order of magnitude better than poor programmers. Twenty years later this still rings true. But if your "exceptional" people do not produce a system that is easy to maintain, you may find yourself starting from scratch when your star engineer gets a new job. We must remember that software tends to hang around much longer than engineers. The cost of having your best engineers follow basic engineering principles, then, would be dwarfed by that of having to rebuild your system because the people who wrote the code are no longer around.

Ellen Ullman: I know you're expressing the received wisdom, Roger, but I strongly disagree with your premise. Every person you hire is (or can be) exceptional for the situation at hand. After the initial development phase, you need a very different sort of exceptional person. When working code exists, "sheer force of will" is a destructive quality, in my opinion. The truly exceptional skills I look for in later-phase work are the ability to communicate with colleagues (while also being a good programmer, a rare enough combination), the ability to read an understand the system developers' "brilliant" code (ability to read code is so rare that it's extra-exceptional, in my experience), and so on. A whole new complex of exceptional skills comes into play when a project matures. It's foolish to think less of your next cohort of hires. It's self-defeating – if you're looking for ordinary people, that's exactly what you'll get.

Source: Roger Pressman (moderator), "Can Internet-Based Applications Be Engineered?", IEEE Software, September/October 1998.

*** Web Siteseeing ******************************************************

* Open Source Software Development Tools (Part II)

Following the list of our previous issue of "News, Facts & Comments", you will find here some more links to open source software development tools sites. Thank you to the readers that have contributed with their interesting suggestions. GNU Compiler Collection (C, C++, Java, ...) - GrandTestAuto is a tool for unit testing Java applications - jEdit Open Source programmer's text editor - An Open Source Java SQL Database System - Java Object Database Management System (ODBMS) - Red Hat Source Navigator multi-language source management - Framework for writing unit tests against Java code - Kopi java-based development environment for database applications - DB2XML transforms data from relational databases into XML - Content management software - Servlet-based technologies for Java - Java development framework - XML-DBMS is middleware for transferring data between XML documents and relational databases - OODBMS with persistent references to scale Java Object Serialisation

Special section on CORBA middleware - TAO: C++ real-time and general purpose ORB - Java general purpose ORB - C++ general purpose ORB

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

The Scrum Expert