eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
BURLINGAME, Calif.—The current state of the corporate software market could best be described as a train wreck, Brian Behlendorf, the chief technical officer and co-founder of CollabNet, said here Tuesday at the OSDL (Open Source Development Labs) Enterprise Linux Summit.
Industry research shows that some 45 percent of all software development projects in 2003 were canceled, with another 30 percent completed late and/or with reduced features, he said.
“This trend is not headed in a positive direction, and failure rates have risen over the past 10 years. Recently, we have seen huge projects at both the Department of Defense and the IRS fail,” Behlendorf said.
“In fact, Paul Brubaker, the former deputy chief information officer at the Pentagon, once said, referring to software projects, that there are very few success stories.”
What lies behind these failures are slow feedback loops from inception to use, high underlying technology turn, poorly documented prior systems and requirements, the growing difficulty in estimating work, and demotivated developers, he said.
A project-oriented mindset also “kills the community,” Behlendorf said, adding that the life cycle of a software project does not end on a ship date. Teams often throw away the development artifacts they created along the way, or place them in obscure locations.
“As a result of all of these factors, true software reusability is just a myth. While some companies have built asset repositories, they tend to have tarballs of source code and searchable metadata at best,” he said.
Developers also have scant incentives to properly prepare their components for reuse by others or to reuse others work. Software components are not like bricks that are simply stacked on top of one another, he said.
“Essentially, all software has bugs, all software needs adaptation to new platforms over time, new requirements cannot always be wrapped around or above existing code, and APIs are conversations between components and need to evolve over time,” Behlendorf said.
The biggest hurdle to software code reuse is trust, Behlendorf said, turning to examine some of the open-source best practices. These include transparency through the entire process and the fact that forking is allowed but is mitigated by teams working together.
Many corporations still harbor the illusion that the software development model is like an assembly line and that code should simply be cranked out. “But open-source software got a free pass on predictability, as no one gets fired if Apache ships a few weeks late, which has allowed for an interesting experiment,” he said.
The software development process must be seen as an ongoing environment, where interdependence is implicit and allows coordination between projects, thereby stimulating creativity, Behlendorf said.
Discussions and online decision-making—where so much knowledge is created—must be captured, as often the code does not speak for itself and the documents and specifications are incomplete or inadequate, he said.
“This makes everyone think about their words in a way that anticipates future review by people they do not know, which is a good skill and discipline to have,” Behlendorf said.
While personality conflicts are inevitable, they can be resolved by management and coaching, or by removing someone from the project. “This is one of the bigger problems the open-source community has—time and effort are wasted by fruitless argument,” he said.
Measuring a projects success is always critical, and those companies that adopt a more open development approach internally should achieve a more graceful and continuous life beyond the products release, Behlendorf said. This should make it easier to bring in new developers, and there should be fewer conference calls and less of an oral culture, he said.