Process makes perfect
Successful software development starts with a methodology that suits your development team and project goalsTechnology has changed significantly during the past 30 years, but the practices by which we create software have progressed very little. It's no wonder that software project failure rates are so high and overall quality is low.
Inasmuch as the pace of business has increased rapidly, the most widely used development practices still approach software development in the same monolithic manner as they did during the 1970s.
In the past few years, several new development methodologies have begun to appear, including XP (Extreme Programming). Proponents of XP seek to improve software quality, to increase efficiency, and to reduce costs. The heightened communications and rapid release cycles that characterise XP may seem chaotic to traditional shops, but they aim to directly boost customer satisfaction and revenue.
Although XP has been in use for more than five years, its successes and failures have not been as visible as those of other, more recent methodologies such as Open Source. The successes that have come out of Open Source are clearly seen in Linux, Apache and a whole host of other widely used business software.
Open Source and XP share some commonalities, chief among which are direct customer input, rapid release cycles, and collective code ownership. These concepts set XP and Open Source apart from traditional development methodologies.
For example, the idea that a group of developers can own and make changes to the same code base is markedly different from traditional approaches in which a single developer usually owns a particular set of code. Proponents of XP and Open Source argue that the more developers there are to look at a set of code, the fewer bugs that code will have.
XP programmers take customer feature requests and break them into bite-sized chunks that can be carried out during short cycles. Programmers choose which tasks they will work on and break off into pairs to work on testing and coding, a practice called "pair programming". This is where XP becomes controversial.
Some critics assert that pair programming consumes too many already scarce IT resources. Others note that XP's pair-programming concept is merely a method designed to teach less-experienced developers at the expense of the productivity of senior-level developers. Many more maintain that pair programming is no longer viable given today's move away from location-based development.
Many of these criticisms may be warranted, considering that most XP projects have been carried out at larger companies with mixed success rates.
By contrast, Open Source developers, although highly communicative and tightly focused on rapid release cycles, seldom meet or see one another while working on code together. The Open Source development methodology leverages Web-based tools and communication techniques to support collective code development. Freed from location-based constraints, Open Source developers around the world work jointly on code, and oftentimes many more sets of eyes are examining the same code than the two sets of eyes defined by XP's pair programming.
Business and IT leaders should examine methodologies such as XP and Open Source as a way to improve quality while reducing costs. Although you may need to adapt portions of these methodologies to match your company's culture and style, leveraging the best practices of these approaches, such as collective code ownership, rapid release cycles, and heavy focus on specific features, can improve the bottom line.
Companies might begin adapting to these methodologies by taking some simple steps. Define the expected outcomes for a smaller project. Break down the tasks required into simple, feature-based deliverables. Try pair programming or collective coding to complete the tasks. Set up and use a mailing list to support developer communication on the project. Define and execute unit tests and user acceptance tests as part of the plan.
Once you've completed this pilot attempt, analyse what worked and what didn't for everyone on your team. Ask all participants for feedback and then consider which elements of these newer methodologies are best for your company.
Profit from programming practices
Leveraging development methodologies such as XP and Open Source can boost efficiency and software qualityBy Tim FieldenSoftware development today is more difficult than it used to be. We're still balancing the same competing goals: We want to produce a reliable, bug-free application that meets the needs of management and end users, but we want to do it as quickly and cheaply as possible.
Ten years ago, enterprise developers typically spent 18 months creating client/server applications that would be used only in-house. Today we have three months to build Web applications that will be exposed to customers and business partners, knowing all the while that delivering faulty applications can strain business relationships and lose revenue.
An ever-slimmer margin for errors and delays in development means that it has never been more important to tailor your development methodology to suit the project at hand. No matter which methodology you choose, the steps you use, remove, replace, or tweak will depend on project size, time constraints, priorities, and the experience and skills of your developers.
Of course, building large, complex applications that incorporate new technologies will require more emphasis on planning, testing, and incremental and iterative development than simple projects that involve familiar technologies and few developers. Lightweight, fast approaches to development, such as XP (Extreme Programming), may need to be extended for complex projects; more structured approaches, such as the Rational Unified Process, may require streamlining for simple projects.
What works for one project doesn't necessarily work for the next. Methodologies boost software quality and lower costs by breaking the development process into manageable chunks, guiding developers through each phase of the project, determining the inputs and outputs of each activity, and preserving best practices for subsequent projects.
THE BOTTOM LINE
Extreme Programming and Open Source
Executive summary: Although software development practices such as XP and Open Source may seem chaotic, they aim to increase customer satisfaction while reducing development costs. Their hallmarks include direct end-user input, collective code ownership, intense communication, and rapid feature-based release cycles.
Test centre perspective: XP and Open Source methodologies are superior to monolithic, all-encompassing product release cycles that typify traditional development practices. Companies should explore how adapting to these methodologies might improve quality and cut costs.
Join the CIO New Zealand group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.