Choosing how to develop an application is almost as much of a personal preference as the type of music you listen to. One programmer might prefer simpler, cleaner methods of writing code such as Python or Ruby while another might prefer more complex, in-depth ones such as Java or C#. Whatever approach is taken, most developers or vendors agree on one thing – meeting the needs of the business is paramount to everything, including the technology itself. Then again, there are nuances or limitations in each language or development method that can make one better-suited to creating certain apps than another. But you can’t strictly do an apples-to-apples comparison of languages in terms of their suitability for a particular application. There are other factors involved, such as what type of infrastructure a business already has in place and the level of education of a business’s employees. Here’s a look at two development models.The agile software development method has become popular recently due to, in large part, to its emphasis on putting the customer at the centre of the development team as opposed to the software itself. The Agile Software Development Manifesto, which was published by a group of software consultants and practitioners in 2001, emphasizes four core values – individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; and responding to change over following a plan.
A Sequential approach
The waterfall methodology, on the other hand, is a sequential software development model in which the development phases – requirements analysis, design, implementation, testing, integration and maintenance – are seen steadily flowing downwards. W.W. Royce, the creator of the waterfall model, however, referred to the development method as an iterative approach to software development, which is actually closer to the agile or extreme programming methods. But the waterfall method came to be associated with his sequentially ordered model. Unlike more dynamic methodologies such as agile, the waterfall method is more rigid and subsequently requires the developer to move on to the next phase only when the previous one is completed.
While the waterfall methodology has been around for decades, the newer agile approach has slowly been gaining ground. Even upper management is starting to talk about it.
Mike Bowler, who founded Ajax, Ont.-based Gargoyle Software Inc., says the agile approach to software development can save businesses time and money compared to often drawn-out software projects. “An agile project is capable of developing something shippable every two to four weeks,” said Bowler, who develops software for his clients using an agile-based method called Extreme Programming or XP.
XP is based around agile principles – communication, simplicity, feedback and coverage.
Longer development time frames could cost them extra money if clients change their strategy, Bowler said. “Instead of building for eight months, you’re only throwing away two weeks of work. Often agile projects come in earlier and cheaper than traditional ones.”
Better adaptation to change also means that more features in agile-based programs are used by the client than traditional software builds. With agile, the development team is always working on the features that are most important for the end user. “They won’t build things that don’t get used,” Bowler said.
Programmers can approach agile through a variety of platforms, including Microsoft’s .Net.
.Net provides developers with quite a bit of flexibility in terms of what kind of language they want to use. Developers, for example, can implement agile-based programs using .Net. But there are cases where .Net might not be as useful. If an independent software vendor has a mandate to write an application that runs on Unix, Linux, IBM mainframe and Windows, then writing in .Net wouldn’t be the framework of choice for it because .Net doesn’t run on the mainframe, said Microsoft Canada’s senior product manager of development tools, Jeff Zado.
In general, Zado said, the software methodology that an organization uses is often team-independent. It’s also largely a function of the skill sets of developers inside an organization. If there isn’t anyone in-house that can maintain the software or a business has to outsource external support, then the project quickly becomes cost-prohibitive. In some cases, companies can be forced to re-write applications or do other development paradigms if the language disappears because of a lack of support to extend it.
That’s history
Despite criticisms from other development camps that .Net isn’t a dynamic framework, Zado said there is an initiative around dynamic programming supported by third-party software vendors and also from inside Microsoft. Like .Net, Sun’s Java has also been criticized for not being a dynamic enough language. “That’s the history,” said Kevin Schmidt, product manager for SOA and business integration platforms, Sun Microsystems. “Java doesn’t have anything that precludes the agile approach.”
The much-hyped service oriented architecture model for building software apps is also helping to change that. SOA is services composed as part of applications, which allow software writers to develop services in a language that makes sense, he said.
Compared to monolithic apps, SOA reduces the amount of maintenance required to keep the software running and allows the IT shop to maintain simple services. Services can also be reused for building new apps, saving time and money on labour and other associated costs with developing software, said Schmidt.
Smalltalk is another approach. Its dynamic nature makes it well-suited to doing agile development. James Robertson, Smalltalk product manager at Cincom, said agile was more or less invented in Smalltalk. “If you have a good team, they can do good work almost regardless of what tools you give them,” he said. “If you have the best-known tools in the universe and you have a bad team, you’re just not going to get anywhere.”
Smalltalk is an object-oriented (OO) approach, said Bob Cherniak, principal of Cherniak Software in Toronto, who is also a member of the Toronto Smalltalk Users Group (TSUG). “It wasn’t uncommon for people setting up C++ or Java shops to be told (that) if you want people to program in an object-oriented way to get the most out of the OO rationale, then start them with six months of Smalltalk,” said Cherniak. “That way, they’ll understand what object-oriented development is all about.”
Smalltalk is most useful in applications where requirements are changing on a rapid basis, said Cincom’s Robertson. “When requirements are not set in stone, when requirements are rapidly changing, Smalltalk is a good fit for that because Smalltalk is malleable,” said Robertson. “You can do an awful lot of things with (Java) but once it’s in its shape, it’s hard to change it.”
That’s why Robertson says Smalltalk is good for cases where a dynamic solution is needed, such as a Web site, since the content on Web pages changes often. With Smalltalk, IT workers can patch servers on the fly without taking down a site.
Other programming languages include Python and Ruby. They are similar to Smalltalk, although Cincom’s Robertson says Ruby is more similar to Smalltalk than Python is. “In both cases you’ve got dynamic languages where you can make changes quickly, where you can modify applications that are running very quickly and easily,” he said, adding that the big difference between those platforms and Smalltalk is that Smalltalk has an environment and tools whereas Python and Ruby have text editors and basic compilers and the debugging tools are kind of basic.
Ease of programming
But because of their simplicity, languages such as Python and Ruby are better-suited to writing small applications. With Smalltalk, the entire language or runtime has to be carried with the application, which can make development slower – though it means the tool’s right there for the developer, said Robertson. This makes the language better-suited to the agile development methodology over the waterfall approach as it is not intended to be a long, drawn-out development process.
Python’s simplicity is what first attracted David Godger to the language. Python’s users range from Web 2.0 heavyweights Google and YouTube to small applications that run on cell phones.
Because Python is an interpreted language, Godger said it is geared towards the efficiency of the programmer. “It’s geared for ease of programming rather than speed or execution.”
But developers aren’t limited to writing in Python if they have more complex parts to add to the program, Godger added. If developers need to look at a specific part of the program, they can take a portion of code that’s slowing things down and rewrite it in a faster language such as C.
When it comes down to starting a software development project, choosing which language for the project has less to do with which one is better and more to do with which one better-suits an organization’s needs at that particular time for that particular project. Businesses should take a look inside their organization and see what they have to work with in terms of skill sets and infrastructure and use those as a guide to selecting the best approach for them.
