The world of software development has come a long way from the days of programming for mainframe systems, with the evolution to distributed and web-based systems requiring a new, more rapid approach. Agile software development is a direct response to these changing needs, and while it's not everybody's cup of tea or relevant to every situation, it's certainly gaining prominence. Agile is the maxim embraced by custom software development specialist Thoughtworks, which has progressed this cause by releasing its Go continuous delivery toolkit to the world as an open source system. This follows the development of the tool for its internal use, after which it was made available as a commercial product. The company's principal consultant Jez Humble said in a statement that releasing Go as open source is intended to make continuous delivery standard practice across the industry. The delivery of updates to software and platforms is common practice with giants of the internet such as Facebook, which pushes new iterations of its system as often as twice a day. Managing that workflow in a manner that avoids complete failure is no mean feat. The announcement in March that Facebook has developed its own coding language, aptly named Hack, speaks to the challenges of maintaining such an enormous system using conventional methods.
Pros and cons
Despite the advantages of the agile and continuous delivery methodology, it's not for everyone and probably a lot less so for mission-critical enterprise systems.
Walter Norris of Izazi Solutions, which specialises in core banking systems, notes that agile, as with other methodologies, has its pros and cons. "Any methodology you use is about the process," he says. "If you have a system (such as Go) that enforces a process, you have more control and people will behave as you expect. You're relying on the knowledge in people's heads as to how they should be interacting with each other. With any system that enforces a process, you're taking that out of the picture."
This question of limiting the human factor is especially important in custom or hybrid methodologies, an area in which Norris has first-hand experience from working with one of South Africa's big four banks that has developed its own, unique development approach. "Whenever you adopt a methodology that no one else knows, you have to train people on it. New team members may assume one thing, but are actually required to do something else. A person used to the waterfall approach, for example, is accustomed to working on only one phase of that development lifecycle," he says. "If it's a well-known methodology or established industry standard, then the training isn't so difficult. As soon as you go down the custom methodology path, the onus rests solely on the organisation to train its people, and it's a mission," Norris says.
Greater visibility
Thoughtworks' Go system eliminates this to a certain extent, on condition that development is based on agile methodology, of course.
Sett Wai, a consultant developer in the company's Johannesburg office, says Go is a tool that allows teams to automate the development pipeline. This automation simplifies the traditional development lifecycle that runs from development to quality assurance to deployment, he says.
"The problem with the conventional lifecycle is there's a lack of context between the deployment and development teams because they may not know what the features need to do. What we're trying to do with continuous delivery is to break down the silos so the entire team has shared responsibility," he says.
This promotes greater visibility across teams throughout the development lifecycle.
Norris concedes that the simplification of the process through this type of automation and visibility would certainly have advantages for enterprise developers rooted in, or adopting, agile development.
"A lot of the large organisations are realising, however, that to be competitive, they have to buy best-of-breed software - they can't develop in-house," he says. "It's a bitter pill to swallow because over the years, they've invested millions of rands in the in-house systems that are built to their specifications. Now they realise that to be competitive in the market, they have to be agile from a business point of view, not a software development point of view."
What we're trying to do with continuous delivery is to break down the silos so the entire team has shared responsibility.
Sett Wai, Go
This is particularly relevant in the financial services sector where quicker response to market demand, or innovations from competitors, means they cannot wait for IT to develop the back-end systems needed to activate the necessary functionality.
"For banks, creating a new product used to be a big IT project. But the business can't be agile if they're relying on their 30-year-old legacy systems that have business rules 'hard-coded' into the software. If the sales and marketing team sees an opportunity in the market to target a product at a specific segment, they require true business agility."
He says the solution has been to standardise on ERP systems that require configuration more than bespoke development.
Wai says that although enterprises of this ilk may not see the benefits offered by Go, the system certainly has a place in the toolset of organisations developing on the agile methodology. Equally, it can be applied by smaller teams looking to streamline their development lifecycle.
Go is available for download at www.go.cd/download for those wishing to incorporate the toolset in their workflow, or development teams wanting to test the agile development waters.
First published in the May 2014 issue of ITWeb Brainstorm magazine.
Share