David Intersimone: There are some pieces to think about. We do some testing, in what we call the performance assurance area, but then we rely on integration with Mercury Interactive or Segue to do the load testing. That's something that especially large enterprise customers want.

Do you think that the average enterprise development team is appropriately organised? User interaction experts like Alan Cooper and Jakob Nielsen argue for a division between those designing user-facing aspects of applications and the programmers building functional code. Do you think that approach has merit?

I don't have a problem with any kinds of expertise areas, but nobody works in a vacuum. They may do web graphics, say, but ultimately it all comes together in an application. Those members have to come together all the way through, starting from the requirements. And as things change, everyone on the team needs to be alerted. Whether I'm a designer or a coder, I want to be notified as things change. Now in a small team, you can do that through human interaction; maybe through instant messaging. You can collaborate, on small efforts. But not when you're doing enterprise level development. There's more digital artefacts, there's more pieces that have to come together. So we don't take away the skills of team members, we just allow them to work together in a more productive and integrated way.

Easy-to-use scripting languages have come to the fore in recent years. How has this changed the average application in terms of, say, reliability?

I always separate out reliability from what it is you're trying to build. Reliability is something everyone has to work towards, regardless of what you're implementing with. The choice is really about how you want to do development, how you visualise the business need. So scripting has its place, especially in web application development. But if you look at, say, [Microsoft's] ASP.Net, scripting can actually be compiled-on-the-fly chunks of code, where you can use the language you're familiar with rather than having to use another language or scripting language. So it's really up to members of the team to say, what are we going to use? If there's something like validating input on the client side, it makes sense to use scripting. But the heavy lifting of enterprise computing is always done on the server side, and today it's almost always going to be done in a dot-Net language, or J2EE.

But there is a trend towards tweaking pre-built components with scripting, isn't there?

Today's economy says you have to reuse everything, to resurface functionality you already have. That's what web services are about. It's easier not to rewrite a back-end but just leave it where it is, and serve it up in a more modern way. Web services is one way to do that. Some people are saying, no, we're going to rewrite, but many don't have the time, the money or the people.

Whatever happened to the goal of development without coding? Is it a realistic notion that you might draw diagrams to create programs, as envisaged a decade ago with CASE (Computer Aided Software Engineering) tools?

There's two aspects to that. There will always be some customised coding somewhere. But there is an area that we've spent a bunch of time on called model-driven development, where you can define the model and have it generate a platform-independent set of functionality. We ship that technology in our Delphi product today on Windows and .Net. And we'll roll that out to Java and to other languages in the future as well. That's based on the OMG MDA [Object Management Group Model-Driven Architecture]. So for certain apps that are back-ended by databases, where you can specify the model and the business logic, using UML [Universal Modelling Language] and OCL [Object Constraint Language], you can render an application and the reasonable objects. So we do that today and there's more work going on in the MDA space. In the past everyone had their own solution, whether it was some 4GL [Fourth Generation Language], or some CASE tool and so on. But using an industry standard like UML, where you can agree the models, import and export models, and take pieces of other models from other applications and use them to create model driven applications - for some kinds of applications that works nicely. And the fact that MDA is supported by more and more vendors means that it will become easier for applications and models to interact with each other. There'll still be classes of applications that need to be built using other architectures. SOAs [Service Oriented Architectures] are coming and web services are the way to integrate everything together.

Is supporting MDA development a significant part of Borland's business?

It's just emerging now. We've been shipping MDA-based technologies for about 18 months now, with a good following. Since it relies on models you have to find customers that are committed to modelling, and keeping models up to date. Some use models just as a way to describe or to document an architecture. Some use models for reverse-engineering: to show what a piece of old C++ code is doing so that it can be understood. But if you're going to do model-driven development you have to be committed. As the applications get more complex, or as more people get involved - especially if you're doing distributed development - efficiently sharing requirements and changes, things like that, become more and more important to success. We have large banks that have developers all over the world, and they're just building teams all over the place. You see that in almost every major bank. They're either doing their own development all over the world, or they're doing some parts that are outsourced to a major services company like Capgemini or EDS, or they're doing mixed development with smaller shops as well.

More...