The process of building software is one that can be defined as both an art and a science. All software needs to be structurally sound and functional, but should also demonstrate elegance in its design. How an application becomes all of these things is as individual as the developer.
What most developers agree upon is that choosing a methodology for a software development task should depend upon the project and not the other way around.
Daryl McMurray, senior programmer analyst at DNI Systems in Parry Sound, Ont., said the process of choosing a methodology should be based on a number of different elements.
“Methodology changes depending on a lot of things like the style of application that you’re writing, who it’s for – yourself, as an in-house application, or for a third-party client – plus constraints on time and budget. All of this changes the way that you approach things and the time that you spend in research versus pure development,” he said.
Variables such as language, development environment and required documentation also play roles in determining which methodology will work best, McMurray said.
Eugene Nizker, a developer at Custom House Currency and Exchange in Vancouver said it is equally important that the chosen route fits the developer as well as the project.
“I would tend to say that it does make sense to embark upon a project making sure that you use a methodology that is suitable to you. But I usually tailor the methodology to my needs or the team’s needs or the project’s,” Nizker said.
While this process of tailoring a methodology to a project’s requirements seems like common sense, some players involved in the development process don’t always see things in the same way.
Scott Ambler, president of software consulting firm Ronin-International in Newmarket, Ont., which specializes in improving the software development process, said that some companies choose one methodology for all of its development processes because management prefers a streamlined and easily identifiable way of doing things. This, he said, is a huge error.
“It’s a fundamental mistake for an organization to find one official process and stick with it – it’s the kiss of death. It will never, ever work out for you. It’s a serious and common mistake,” Ambler said. “If you want to be a software professional, you’ve got to understand the basics of the job, and one of the basics is knowing what approach to take.”
Methodologies range from the very rigid to the very flexible, and each developer has his or her favourite flavour. Like in anything else, software development methodologies come in and out of vogue, with both developers and project managers.
The waterfall model, for example, in which one phase has to be finished before the next phase begins, is often popular with management because it is simple to describe. Because the model is set up with analysis preceding design, which precedes coding and testing, managers can easily plot milestones and predict timeframes. But many developers see this model as outdated and an exercise in frustration.
Nickolas Landry, chief software architect at Montreal-based dotBlox, argued that the waterfall model is appropriate for many types of development, but software is not one of them.
“If you want to build a sidewalk, use waterfall, but if you want to build software, you cannot. If you’re building a sidewalk, you can expect to have 40 per cent of the sidewalk to be built when you’re 40 per cent along in your schedule. If you’re building software, being 40 per cent along in your schedule doesn’t mean that 40 per cent of the application will be built,” he said.
Part of the reason this model doesn’t work is that changes always occur during the development process, and waterfall doesn’t allow for this.
According to Ambler, waterfall has a notorious failure rate in the software development industry, and he said he’s puzzled as to why it is still used.
“Regardless of how you crunch the numbers – if it has a 50 per cent or a 90 per cent failure rate – it’s bad. If you went to a dentist with a 50 per cent failure rate, you’d be pretty upset about it,” he said. “The problem is that this stuff isn’t working, yet some organizations are still pushing it down developers’ throats. It’s the definition of insanity: doing the same thing over and over again and expecting different results.”
But Nizker doesn’t completely rule out waterfall as a methodology, going back to his point that the model should fit the application.
“It’s unpopular today, and if anyone asks if you’re using it you say that you don’t, but it does occasionally make sense for small projects,” he said.
Alternatives to the Waterfall Model
V-shaped model: Similar to waterfall, but each test phase matches each development phase. Requirements are paired with system testing, high-level design is paired with integration testing and detailed design is paired with unit testing.
Prototyping model: Helps designers and users to clarify the requirement of the system. A throw-away prototype is developed for users to evaluate so that designers can better understand the system and improve the prototype.
Incremental model: Software is developed in stages to enable the early delivery of the product. At each phase, developers have a goal to deliver certain features to the customer.
Spiral model: An iterative approach that takes risks into account. Designers develop a small part of the project and evaluate risks. For each iteration there are six steps: determine objectives, alternatives and constraints; identify and resolve risks; evaluate alternatives; develop deliverables and verify that they are correct; plan next iteration; commit to an approach for next iteration.
Agile model: An approach that is designed to be understandable to its intended audience through simplicity, accuracy, consistency and detail. Includes methodologies such as extreme programming, crystal methodology and scrum.
