In the latest episode of a storied saga, Borland spun off its developer tools division into CodeGear, a wholly-owned subsidiary. It also released JBuilder 2007, now based on the Eclipse platform. Artima spoke with Michael Swindell, CodeGear's VP of products, and JBuilder product manager Joe McGlynn about the new company and JBuilder 2007.
Borland is among the strongest brand names in developer tools, but the company's business has suffered in recent years as high-quality open-source tools and competition hurt its market share. Now Borland hopes to find its renaissance in a new company, CodeGear. CodeGear is a result of spinning off Borland's tools division into a new business unit, giving that division undivided focus on developers.
Coinciding with the launch of the new company, CodeGear released JBuilder 2007, the JBuilder based on the Eclipse platform.
Artima spoke with Michael Swindell, CodeGear's vice president of products, and JBuilder product manager Joe McGlynn about the new company and JBuilder 2007.
Frank Sommers: Borland is one of the most recognized names in the developer community. Why is there a need for a new company with a new name?
Michael Swindell: Over the years, Borland has meant a few different things. Developer tools are one of things it's been known for. The tools themselves carry very strong brands with them, and our customers recognize the tools brands probably more than they do Borland. The Delphi, JBuilder, C++ Builder, and InterBase brands are very strong with our customer base, as is the Turbo brand that we brought back earlier this year.
But the company has other products, too. We announced in February that we were looking at separating the developer tools from the application life-cycle management, or ALM, side of Borland. We found that these were two very distinct disciplines. They represent different interests, different concerns, and a different type of customer.
When [Borland CEO] Ted Nielson came on board earlier this year, he made a decision to ensure that these product lines had individual focus. From February on, CodeGear has been operating as a separate business unit within Borland. We announced this separation now formally. CodeGear is an independent operating company of Borland, with a separate executive team, a separate sales, separate development. All the strong developer brands I mentioned are coming with CodeGear.
Frank Sommers: Why the name CodeGear?
Michael Swindell: We wanted something that very obviously connected with developers, that was about programming. We were looking at names that centered around things like source code and languages and programming. We did internal name development, and also fielded submissions from our community. One name came up on top was DelphiGear, meaning that we were making gear for Delphi developers. Since we are more than just about Delphi, we eventually came up with CodeGear, and it really resonated well both internally and with key customers.
Frank Sommers: With agile development practices, isn't there more need to integrate application life-cycle management with developer tools, instead of thinking of ALM as distinct from what developers do?
Michael Swindell: We all use life-cycle tools in some capacity, but a company focused on life-cycle tools is spanning outside developers, and across the entire organization.
The difference for CodeGear is that we're focused completely on developers. When we approach life-cycle problems, we completely approach them from the perspective of the developer.
A good example of that is our own development team that built the new JBuilder we're launching this week. They approached this release of JBuilder not just as a major change to [using] open-source and a new platform [Editor's note: Eclipse], but also in the way they wanted to use a more agile methodology. They chose a best of breed suite of open-source tools to build this version, and then invented a lot of the features in JBuilder to help them with that agile process.
Frank Sommers: How does JBuilder 2007 assist in agile development?
Joe McGlynn: What we were doing before was more a waterfall model. We wanted to start with a clean sheet of paper and make sure we had the best tools to fit the way we wanted to work. As we did that, we encountered the same issues everyone encounters when they set up new tools, getting them to install, and configure them to work together, and getting them to really support a life-cycle around the development process.
We have two major feature sets in JBuilder 2007, Project Assist and Team Insight. ProjectAssist is about eliminating the barriers to setting up a complete developer tool stack. As we looked around and chose different tools, especially open-source tools, we had to address installation and configuration, especially configuring those tools for use with a project.
If you want source control, bug tracking, requirements planning, project planning, continuous integration, a full development tool stack would have about twenty or twenty-five different tools. A lot of them require installing several different pieces—a database server, running database scripts, installing the code, installing Apache, Tomcat. One tool can be compatible with Tomcat 5, some won't be. Just to get up with a basic life-cycle tool stack could take days or even weeks.
Once you've got the individual pieces, you have to provision projects across all those tools, and having the tools to work across those projects is additional work. When things are checked into source control, the right things should happen, such as running a continuous integration build, running unit tests, running code metrics, aggregating code metrics over time so the team can see a trend around code quality, and generate metrics that are important for their project.
And you normally don't have a single place to go to get that information. Instead, you have to open each tool and work in that tool, then jump out and into some other tool. Even if those tools are all hosted inside Eclipse, they are discrete.
With Project Assist, a team runs through a simple admin tool, and with one click installs the entire stack, deploys the entire project, and then gives each developer on the team an XML file that configures Eclipse for work on the project. Developers don't have to know URL endpoints, access codes, or project names. It's all bundled up for them. They just open one file, and can immediately pull code, check in code, and are up and running.
When you create a new project, JBuilder creates your source control check-in, bug tracker check-in, your XPlanner project. You don't have to set up five different projects. We also test out that all those tools work together, and that you don't have conflicts between the versions of libraries those tools use, for instance. At this point we're planning to provide quarterly updates, and in the future, more frequent ones.
Project Assist also handles the communication between those tools, and that leads to the second new feature in JBuilder 2007, Team Insight. Team Insight is about productivity for the team so that developers can gain a measure of confidence in the project and in the direction the project is going, and where they are in [meeting] their goals.
Instead of having to go to each tool to gain project information, you have a project portal that aggregates information from all those tools. You have trend graphs on bugs, for instance. You also have aggregated code base metrics so you can see, for example, if the amount of cut-and-paste code in the project is increasing or decreasing, or if test coverage is increasing or decreasing,. You also have burn-down charts, details about participants' individual features, the status of the build system.
Frank Sommers: Besides Project Assist and Team Insight, what other productivity features will developers find in JBuilder 2007?
Joe McGlynn: We have the Java LiveSource technology that originally came from Together. It allows us to understand source code and then provide different visualizations of that source code without having to rely on code generation or magic files. And it's two-way, round-trip editing. You can either develop in the visualization environment or in the source code, and the changes are always reflected in the other view, too.
We also deploy with JBuilder a complete UML modeling tool that has all the sequence diagrams, and can traverse to any depth in the code you want. We have a new EJB graphical designer that looks at annotation and descriptor files so that you can model [EJBs] and visually create them. That's pure source-based, and works with all the tools Eclipse provides to build J2EE applications. We've done the same thing for Web services: you can create Web services from POJOs, EJBs, or WSDLs, and edit them in a round-trip fashion, either in code or in a visual environment.