Columns

Perspective on XML: What is this ‘agility’?

• By Uche Ogbuji
• July 31, 2003

A hot buzzword these days is “agility.” The pitch is that software development can be more like a maneuverable motorcycle than a lumbering locomotive. Locomotives proceed only along the fixed track laid for them and their huge inertia makes any sort of adjustment very difficult. Motorcycles, on the other hand, can start quickly and zip smoothly past obstacles in the road.

Software engineering doctrine advocates heavy process, where analysis feeds design, more design and yet more design, and only then does one contemplate implementation, testing and finally maintenance. Some people call this approach BDUF, short for “Big Design Up Front.” In its strictest forms it is nicknamed “waterfalls,” a term that has become rather derisive.

It’s not easy to come to criticism of BDUF. After all, it brings to the young profession of software engineering the rigor and discipline that have established other engineering disciplines so respectably. No one would commission a skyscraper or build a jet plane without mountains of specifications, models, surveys and procedural rules. It would seem that similar care is the only solution for the bad reputation software has earned for poor quality.

Despite this, there has been a steady movement lately toward “agile” techniques, which contradict BDUF. Agile boosters claim that BDUF is impractical for all but the largest and most mission-critical systems, and causes a lot of problems because inevitable change in requirements and environment are very difficult to accommodate in the process. The track is laid out during analysis and design, and any variation therefrom is a catastrophic derailment. Agile methods focus on flexibility and accommodation of change, including greater involvement of the end user throughout the process.

Agile programming is an umbrella term that has been raised over a variety of tools and practices. The center of the ideology is Extreme Programming (XP). XP emphasizes lightweight process and anticipation of change.

More recently, “agility” is ascribed to certain languages and even used as a debate tactic in the politics of open-source vs. closed-source software. It has been used in observations that technologies like XML defy traditional notions like encapsulation while improving developer productivity. There is a movement toward agile relational database development that attempts to reduce the notorious rigidity of RDBMS. Agile programming languages are those that don’t require a lot of boilerplate for useful code, and that support dynamic behavior and flexible integration of modules. This characterization is, in part, a way to counter the mildly disparaging convention of calling such languages “scripting languages.” My own favorite programming language, Python, is often mischaracterized in this way, so updated terminology that emphasizes its strengths is welcome. However, the danger of such cunning classification is that the term could be seen as a device for developers to justify their pet tools, rather than as a true benefit to all interested parties in the development process.

The appreciation of agile methods has always been a gradual process for me; through most of my career I leaned on my formal training in software engineering and its emphasis on BDUF and programming languages that emphasize strong typing and systems of boilerplate that can be prepared during design and completed during implementation. I had become fed up with the inflexibility of C++ at about the same time I came across IBM’s Rexx programming language in the OS/2 world. I was amazed at how easy it was to code in Rexx, and how the ease of change enhanced productivity. Soon afterward, I gave Java a good try before deciding that it had only modest advantages to offer over C++.

Just when I’d started to become disenchanted with these non-agile languages, and with my Rexx experience in mind, I encountered the likes of JavaScript and Python. I have since come to believe that more traditional languages impose unnecessary burdens and focus too much on the wrong sorts of safety. After all, very few actual real-world problems occur because someone passes an integer to a routine that expects a float. Bugs are typically made of sterner stuff. I became heavily involved in open source at about the same time, and the need for flexibility coupled with the wide variety of deployment environments and use cases that characterize OSS projects taught me that having comprehensive test suites can be far more important than BDUF.

I’ve become a believer in agile techniques in moderation. I do find it hard to buy the fashionable argument that software development is as much art as science. If anything, the world of computers is far more deterministic than the natural world, building on the well-studied model of the Turing machine. (Although Stephen Wolfram’s “New Kind of Science” [Champaign, Ill.: Wolfram Media, 2002] attempts to shake up such perceptions with his theorizing of automata as fundamental models even in the natural world.)

I believe that as our profession matures, programming will indeed become more formulaic, predictable and even automated (the fervent desire of many in business). However, until we have gained enough collective wisdom and experience to establish ourselves at the level of civil and mechanical engineers, agile techniques more naturally reflect the reality of software development and offer a better chance of meeting customer needs at present.

One would be foolish to advocate abandoning locomotives. There are still heavy-load and long-haul tasks for which the motorcycle will never be suited, but given the expense of software engineering resources, we would be wise not to insist on throwing maximum horsepower at every task we face.

To read more columns by Uche Ogbuji, click here.