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 www.eclipse.org and www.netbeans.org

*** 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.

http://gcc.gnu.org GNU Compiler Collection (C, C++, Java, ...)

http://grandtestauto.org - GrandTestAuto is a tool for unit testing Java applications

http://jedit.org - jEdit Open Source programmer's text editor

http://mckoi.com/database - An Open Source Java SQL Database System

http://ozone-db.org - Java Object Database Management System (ODBMS)

http://sources.redhat.com/sourcenav/index.html - Red Hat Source Navigator multi-language source management

http://testbed.simscomputing.com - Framework for writing unit tests against Java code

http://www.dms.at/kopi/ - Kopi java-based development environment for database applications

http://www.informatik.fh-wiesbaden.de/~turau/DB2XML/index.html - DB2XML transforms data from relational databases into XML

http://www.jahia.org - Content management software

http://www.javaexchange.com - Servlet-based technologies for Java

http://www.nakedobjects.org - Java development framework

http://www.rpbourret.com/xmldbms/index.htm - XML-DBMS is middleware for transferring data between XML documents and relational databases

http://www.xl2.net/odb/index.html - OODBMS with persistent references to scale Java Object Serialisation

Special section on CORBA middleware

http://www.cs.wustl.edu/~schmidt/TAO.html - TAO: C++ real-time and general purpose ORB

http://jacorb.inf.fu-berlin.de - Java general purpose ORB

http://www.mico.org - C++ general purpose ORB