Onward and Upward

Blog archive

Agile Gaining Steam

A well-known prediction by Gartner stated that by next year, agile techniques will be used in 80 percent of all sofware development projects. Statistics like that are growing proof that if you're not on board the Agile Train by now, you'd better hurry or risk being left at the station.

It's a sentiment that Ezi Boteach, VP Products for developer testing-tool maker Coverity, shares wholeheartedly. "The problem is that software complexity's growing, and that has a direct impact on things like time-to-market, brand name, customer satisfaction, and overall cost of sofware development," Boteach said in a recent interview.

Those factors are leading companies away from the traditional method of "waterfall" development, which emphasizes process, and hence is slower, more deliberate and far more complicated. Even though agile development is just 10 years old, it's revolutionized the software industry, Boteach believes. There are few shops anymore that waterfall-only. That doesn't mean waterfall is extinct -- only that the benefits of agile can be so overwhelming that it's captured the hearts of many developers.

It isn't hard to see why. "Traditionally, a lot of these companies used waterfall. It was the default methodology. It made sense; you start with the requirement, then you move into the actual coding," Boteach explains. "Once the coding is done you go into testing, and then you go into actual production. The problem is that when you talk about a long-term project, it can take months or years" to bring it to market.

That leads to problems in today's much-faster-paced software development environment, according to Boteach. "With waterfall it's very hard to predict what will happen. You don't know what will happen with people, with the complexity of things. You have a lot of moving parts and a lot of changes are being introduced as time goes by."

Agile lessens the risk involved, Boteach believes.

"The idea behind [agile] was to solve a lot of the problems waterfall had: Predictability, cost, complexity of development. The idea is to go to shorter iterations, and by doing that, you can actually make things much more predictable. Instead of a development cycle that takes months, you can go into something called a "sprint" which usually takes 1-4 weeks. And within that sprint it's a full development cycle. In that situation, or sprint, you're doing requirements gathering, you're doing design, you're doing development and you're doing testing."

It's the concept of "continuous integration," Boteach says. "You have a system that ties to the source control system. You get a preview whenever there's a code change to the source code system, and it automatically creates a build. Then you can tie [in] things like system tests or unit tests or static analysis, which you do for automated code testing, to become part of the automated cycle. By doing that, you're identifying a lot of the defects that otherwise you'd be waiting until the QA phase [to discover]. Obviously, the sooner you fix it, the less money you spend."

Spotting and fixing code problems earlier in the process results in substantial savings. Coverity data estimates that it's six times as expensive to fix a problem in production as it is to fix it in development.

Even with the cost and efficiency improvements, however, Boteach cautions that a move from waterfall development to agile should be done carefully. "I've seen cases where it's been a great success -- and cases where it's been a big failure, because people were thinking "I'm doing agile; I don't need to plan, I don't need to document,'" he says.

Agile development, he continues, is a "Really big change if you do the whole thing overnight. This is why in many cases a lot of companies will start small. The first thing you need to do is get approval and buy-in from all the parties involved. The second thing is you need to identify the areas you want to start with. You don't have to implement agile in the extreme on day one. I've seen customers do that, but it's extremely disruptive."

It's also no panacea. Boteach is fond of saying that agile isn't magical, that it takes an investment in people with the right mindset, best practices, and automation tools to make it work right. "You need to be smart about it and embrace it in a gradual manner." If not, he adds, "You're basically taking a big risk."

Done properly, however, the payoff can be enormous. In fact, Boteach thinks that companies holding to waterfall-only methodologies could be harming themselves. "If you take two organizations roughly the same size, doing the same type of development, it would be extremely hard for the company doing waterfall to get to the same cost-savings and responsiveness" as the agile business, he concludes.

Is your company exclusively waterfall? If so, let me hear from you. And follow me on Twitter.

Posted by Keith Ward on 08/08/2011


comments powered by Disqus

Featured

  • Compare New GitHub Copilot Free Plan for Visual Studio/VS Code to Paid Plans

    The free plan restricts the number of completions, chat requests and access to AI models, being suitable for occasional users and small projects.

  • Diving Deep into .NET MAUI

    Ever since someone figured out that fiddling bits results in source code, developers have sought one codebase for all types of apps on all platforms, with Microsoft's latest attempt to further that effort being .NET MAUI.

  • Copilot AI Boosts Abound in New VS Code v1.96

    Microsoft improved on its new "Copilot Edit" functionality in the latest release of Visual Studio Code, v1.96, its open-source based code editor that has become the most popular in the world according to many surveys.

  • AdaBoost Regression Using C#

    Dr. James McCaffrey from Microsoft Research presents a complete end-to-end demonstration of the AdaBoost.R2 algorithm for regression problems (where the goal is to predict a single numeric value). The implementation follows the original source research paper closely, so you can use it as a guide for customization for specific scenarios.

  • Versioning and Documenting ASP.NET Core Services

    Building an API with ASP.NET Core is only half the job. If your API is going to live more than one release cycle, you're going to need to version it. If you have other people building clients for it, you're going to need to document it.

Subscribe on YouTube