Process or programming?
Tim: So let's take a step back. Borland's success was originally built on what I would describe as better tools for programming, so you had Borland C++, Turbo Pascal, Delphi. Borland now seems to be moving away from that to products that are more concerned with process than programming.
Dale: Absolutely not. We’re just launching Delphi 2005. Borland’s success is that we’ve started down at the base line of the code. If that doesn't work, it's dead. So the developer productivity, and the tools for that, the integration of those, are crucial to this being successful. Our ALM strategy integrates those tools. Then built upon that is the SDO aspect of getting business viewing into that. CASE tools over the years have come out, where it’s top-down management process, "You will build it this way." And the guy at the bottom goes, "No I won't". It's a push-down, waterfall methodology and that has never worked. The same thing with the business process, it's got to go real-time both up and down. At the individual developer level, he will understand the business value-add that he is putting into this, and not just the expertise of writing a piece of software.
Tim: Going back to the raw coding tools versus other more architectural or process-oriented tools, there’s a concern among some of your core customers that despite Delphi and JBuilder 2005, they’ve seen RAD C++ Builder disappear and Kylix frozen, while Borland is doing all this Enterprise stuff. There’s also concern that modeling and process-oriented tools can add an overhead that makes the developer’s task harder rather than easier. How do you convince such customers that you are not adding to their workload for no purpose?
Dale: As the level of complexity of applications increases, the sophistication of the collaboration amongst many people has to increase as well. If you are developing a project where you are the DBA, you are the application specialist, and you are the developer, it is easy to manage. When you add complexity, when you have 45 different projects and pieces being put together, it’s a different level of complexity. We don’t believe one tool solves all problems. A developer that has tried the methodology process as you just described, then found it tough, gone back to code, and solved the problem – that’s great.
Our toolset says you can go through the code as a developer, you can code, but all these other groups that have to see this stuff, that have to be part of it, to view it, can actually see it in their language. An architect can see what you just created in a model. You don't have to create the model, then create the code. You can actually create the code and the model is created. The requirements get extracted out of that so the business guy can say, "Oh, I understand what's happening." Because what have seen time and time again is that developers will create things and they don't go back and document what's been created. And two years from now, someone has to go back and fix that up and do something with it, and they scratch their heads and go, "What were they trying to do?"
Nigel: In terms of the standalone developer, Borland is still committed. We just brought out JBuilder 2005. There's a new version of Delphi coming out. There's a new version of C++BuilderX coming out. Even within this strategy, Borland is still committed to the developer.
Dale: And you mentioned Kylix. I’m still waiting for a Kylix developer to say, "I want to buy that."
Tim: So leaving aside Kylix, what are you offering customers who want cross-platform apps for Windows and Linux? You’ve got C++BuilderX but it’s not a RAD tool.
Dale: Eventually you’re going to see C++Builder being part of Delphi, you’re going to see the ability to have more RAD lookalike stuff in JBuilder, and eventually you’re going to have a development environment that will target whatever language you want. That’s the wave of the future.
Tim: Can I clarify what you’ve just said? You said C++Builder part of Delphi ... but as I understood it Delphi uses "Galileo", the IDE for Windows, and then there's the JBuilder "PrimeTime" IDE which is also used for C++BuilderX. Are you saying C++Builder might move back to Galileo?
Dale: Maybe Delphi might move to PrimeTime. There’s a lot of things that could happen. The goal is to be more customer-centric, which is saying regardless of what internal engine we use, the customer can say “I want to use a Windows-based RAD development type Framework, and I want to output it in Java, or I want to put it in C++, or I want to put it in Turbo Pascal, or I want to put it in C#.” The goal is to be able to select that later, to be in the environment of the language and framework that you know how to use, but able to target any rich environment that you want
Today we don’t have that, no-one has that. But that’s where we want to get to. I’m not saying that it’s next year, I’m not saying it’s the year after, it may be three years away.It's the same thing with our ALM strategy. The idea is that I can start creating requirements and the model starts being created for me. I’m not an architect, but I'm seeing this model. And then all of a sudden I see code forming. So I become a developer even though I’m just a business person. Then I can bring in my developer and say, "Hey, how do you make this happen?" And he can go work on the real magic part, the creative part of that. And all the mundane part is already done by me as the business guy.
Tim: What about 64-bit development? Will we see a 64-bit VCL and a 64-bit Delphi compiler? Or a 64-bit C++ compiler from Borland?
Dale: We have been investigating all of those things over the last 6 months. I don’t have an answer for you on exactly what you’re going to see from us regarding that. We're also talking to AMD and Intel about their processors. You will most likely see something from us, I just don’t know what form it will take yet.
Tim: Are you getting to the point where you reckon Intel, for example, can do good compilers for its processors, so there’s no point in Borland doing its own compilers, you can just do the tools.
Dale: If we clearly see the value we can add into that. Otherwise, we're trying to stay at the business abstraction layer.
Click here for the final part of this interview
Copyright Tim Anderson October 15th 2004