Extreme programming, or XP, has enhanced the company’s approach to software product development

An alternative to traditional, sequential software development, XP has fragmented the former year-long progression of planning, coding, and testing prior to release and exchanged it for a series of two-week iterations marked by intense customer involvement, far greater flexibility, and significantly less time spent on features that don’t really matter.

From its start more than 30 years ago, Canonsburg-based engineering simulation software maker ANSYS, along with most other specialty software producers, used a discipline for product development that followed a familiar path. Over a period that would typically span anywhere from 12 to 18 months, the process would begin with defining customer requirements. It would then lead, in sequential fashion, through the steps of product planning, coding and development, beta testing, product launch, and finally marketplace feedback, before the next iteration could begin. 
Over the years, industry-wide acceptance of these cascading stages in software development gave both producers and their customers a certain measure of comfort in the outcome of the process. But, according to ANSYS Product Marketing Director Barry Christenson, it was often at the expense of flexibility, particularly in its final phases. 

“If you’re in the commercial software industry today, your marketing or product management group is defining the requirements and list of features. It’s typically 100-200 items long, more than you could possibly complete in that cycle,” Christenson told an audience at a recent Forum of the Pittsburgh Product Strategy Network. “The development group makes a plan, goes to development, and conducts beta testing. Then we launch the product and get feedback back into the development process. It’s very much a cascading kind of a process. 

“But once you start, it’s hard to change. The further down the development process you go, the higher the cost of change becomes. As you get closer, and finish up beta testing and are ready to release, if you find that something went wrong, or that a significant customer needs a new set of functionalities before you release, it’s a real fire drill to get that in; it ends up costing a lot of money.” 

Locked in

In any technology business, long-range vision may be laudable, but the fact is, it often misses the mark. “The traditional approach has a lot of upfront planning,” he said. “You’re trying to define exactly what will come out at the end of the process, so you prioritize all these requirements. But if that plan is changed, you’re penalized in terms of resources not being available for allocation somewhere else; you’re penalized in terms of features dropping off the plan.” You are also in a sweat to flush out and fix any bugs early on because the cost of doing so at the end can be very high. 

However, with customer needs evolving more quickly than ever and the drumbeat of change accelerating in market after market, the long cycle of traditional software development became less and less well matched to the real requirements of software users. For ANSYS, that meant applying its philosophy of continuous improvement to finding ways of speeding the turnaround of its sophisticated engineering simulation software, reducing the cost of making last-minute changes, and assuring itself of ongoing customer involvement in the company’s product development process. That’s when it discovered XP, shorthand for Extreme Programming. 

Unlike the lengthy, stage-by-stage cascading waterfall process of traditional software development, XP breaks the effort into two-week iterations. Customers, particularly ‘proxy customers’ – development partners who, in addition to being actual customers, also serve as stand-ins for other users – are intimately involved in setting priorities and in driving many of the programmers’ day-to-day actions. 

Lean code

Minimizing lines of code, removing waste and redundancy, emphasizing reusable software components and dramatically shortening release cycles are all major strategies of the XP method. XP also places a premium on postponing decisions – on waiting until development is well underway before finally deciding whether a specific feature or function really has to be included; if it doesn’t, so much the better. Less is more. 

Beyond that, XP puts a premium on seeking feedback from customers and colleagues just as soon as new code is written. It mandates far more communication among all participants – including any other software development firms that the code will eventually interface with. And it scraps the cherished notion of beta testing as the primary form of early customer feedback. In fact, it scraps beta testing altogether. 

In effect, XP takes conventional programming concepts and turns them upside down. It requires mastering new tools and new terms. And there are plenty of challenges in the implementation phase as well: developing a sustainable pace, code sharing, organizational changes, and more. 

“One of the premises of XP is that all development starts at a very high level, based on a theme, and boils down into a path level that people can really work from,” he said. “At the theme level, you have these very broad categories. Proxy customers really manage those themes. So when we take a theme to develop for the next release, the proxy customers are going to guide the organization to develop new features for that theme.”

“A lot of people in the organization are involved in prioritizing these themes: product management, sales, and others. But once we’ve agreed on those themes, it’s up to the proxy customer to take those themes and write up a story explaining how a customer is really going to use our solution related to those themes.” 

Implementing XP can also be anxiety-producing. “The idea of changing customer requirements late in the process is scary to a lot of people,” Christenson acknowledged. “The idea of having software you can post online and let a customer try out at any point in the development process is scary too, because you never know what they’ll see.” 

“But it does evolve into more of a predictable process,” Christenson said. “You have the opportunity to control and re-prioritize as things go on. What you get is a very efficient way to keep track of what’s going on: What’s the status? What’s the commercial readiness of the code? How are all these features being developed? Or are they being overdeveloped? 

Hitting the mark

“We went from a 12-month development cycle, that sometimes stretched to 18 months, to a very regimented 6-month development cycle,” he said. “Two times a year we release software. It was a big change, but it was part of a process that delivered more value to our customers. 

“Customers get excited about this, especially once you demonstrate you can really sustain it. Because they can count on the fact that you’re going to deliver some new features, they have the opportunity to take an active role in your development. When they can give you live feedback, they see a great process. Now we’re hitting the mark of our customers’ requirements. And we’re able to really maximize the amount of useful features we’re delivering”.