email article printer friendly

Making Development Agile
From enhancing products gained by acquisition to an impending IDE divestiture, Borland throws down the gauntlet for optimized software delivery.
by Terrence O'Donnell

July 27, 2006

Borland Software employees have been talking quite a bit over the last two years about the company's push to optimize software development for organizations through its Software Delivery Optimization (SDO) approach and SDO's role within the company's overall Application Lifecycle Management (ALM) strategy.

As director of developer solutions, one of Rob Cheng's many responsibilities is to evangelize agile development and continuous integration capabilities for the developer and development processes and show how they can be achieved through optimization of the infrastructure, tools, processes, and platforms. In a recent meeting at Borland headquarters between some of their executives and FTPOnline editors, Cheng spoke at length about these quality management issues and touched on the progress of SDO and the company's commitment to the Eclipse platform.

Borland has built a solid reputation on IDE product environments such as Delphi, JBuilder, C++Builder, C#Builder, and others, but the company's evolution to a higher-level approach that more effectively integrates what are perceived as development process silos into a seamless, end-to-end system of software delivery reflects a drive to better support the complexities of team development environments.

As Cheng put it, "Developer and IDE are not synonymous. Obviously a developer's world has a lot to do with the activities inside an IDE, but there are also a lot of other things that touch a developer's life—dealing with pressure by management to do scoping on projects, having to report up to requirements, having to make sure that what you are creating is tested by the QA department and is acceptable to end users and customers."

An Agile Breed
In today's development environments, according to Cheng, requirements management, source code control, modeling capabilities, and so on are all processes that developers touch on a daily basis. In addressing these lifecycle management responsibilities for software development and delivery, Borland has made several key acquisitions that support these specific, process responsibilities and is integrating these products and services into its ALM fabric.

And while there is a lot of excitement in Cupertino around these efforts, there is also a lot of anticipation at Borland around the impending announcement for the tools side of the business. After a long selection process for a suitable investor, Borland will be spinning off a separate, newly named company that will continue to enhance, maintain, and support the many developer IDE tools that have been recognized in the industry for many years.

Cheng will remain a Borland employee, following the IDE divestiture, to focus on quality issues through continuous testing and continuous integration capabilities within the company's evolving ALM strategy. One of the biggest hurdles that Borland has in delivering its ALM message, according to Cheng, is a general misconception around the terms process and ALM.

"If you look at a company that is developer-centric, that is bottom-up, that focuses on what developers want," Cheng said, "you find that left to their own devices, developers create their own processes. If you look at the rise of more iterative or agile development methodologies, if you look at the rise of continuous integration, these are very much grass-roots, bottom-up, developer-focused processes that developers realized were pain points. With agile [development] the feedback loop from customer acceptance of what we are doing, to us writing code, takes too long and there's too much chance for us to go off path."

The concept behind continuous integration, Cheng said, is that the developer has already created the problem, but the developer doesn't know about it until it's time to integrate the code into the larger application space. The key to fixing the problem, he said, is putting the multiple developers' builds together often so that there is sufficient time make the fix.