What is an Agile Language?

Python, Ruby, PHP even the old-school languages Lisp and Smalltalk have been called "agile" in blogs. Java not so much. (Agile Language, C2.com, C2.com;What is Python and Why Python?, Sourceforge; Is PHP an Agile Programming Language?, IBuildings) As someone who has studied language design at a Master's Degree level, I wondered exactly makes a computer language "agile"?

This turned out to be a more complicated question than I expected.

There are dozens of different software development strategies. Each strategy provides techniques for designing, building, documenting, releasing and maintaining software (List of Software Development Philosophies, Wikipedia.)

In 2001, a group of developers categorized several of these approaches—some that had been around for decades—under the umbrella term "agile development" (Agile Manifesto). Agile development strategies all exhibit, to some degree, these priorities:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Afterward the term "agile" began appearing all over as an IT buzzword. Then people began using "agile" to describe programming languages. For example, Groovy is described as an "agile dynamic programming language" on its home page. Was this just another buzzword or was there a new revolution in programming languages? So this month I sifted through many Internet postings looking for what made a language agile or not. What I discovered was a huge range of opinions.

Theory 1: An agile language is a language that improves productivity.

To understand this belief, you have to understand how agile development differs from other strategies.

Ancient societies had different approaches to collaborating on large problems. In the book "Software Creativity 2.0", Robert L. Glass draws an analogy of the forces at work in the modern IT shop with Greece, Rome and the Barbarian European tribes that destroyed classical civilization.

1. Greeks organize things, Romans organize people, Barbarians barely organize anything.
2. Greek methodologies are informal, Roman ones formal, Barbarian ones nonexistent.
3. Greeks write programs, Romans manage projects, Barbarians leap to coding.
4. Greeks are motivated by the problem at hand, Romans by group goals, Barbarians by heroics.
5. Greeks minimize the amount of documentation produced, Romans maximize it, Barbarians take pride in doing no documentation.
6. Greeks work in small groups, Romans in large organizations, Barbarians work solo.
7. Greeks use things as tools, Romans use people as tools, Barbarians avoid tools.
8. Greeks are democratic, Romans are imperial, Barbarians are anarchists.
9. Greeks are empirical/inductive, Romans analytical/deductive, Barbarians are unthinkingly emotional.
10. Greeks are intuitive, Romans logical, Barbarians impulsive.
11. Greeks are a meritocracy, Romans a "function-ocracy," Barbarians a "fear-ocracy".
12. Greeks emphasize substance, Romans form, Barbarians lines of code.
13. Greeks do things, Romans plan things, Barbarians break things.

Both Greek and Roman civilization built large projects. True agile development favours the Greek approach: doing is more important than excessive planning, but still plan enough not to break things. However, most companies are actually Barbarian, even when they claim to follow agile practices. (Agile means no documentation - common misconeption, Agile Blog; What don't you like in Agile Development, Stack Overflow.) Most of those Barbarians boast about how productive they are: eliminating all that strategic planning, product testing and communication, they focus on keystrokes and believe they are company stars. "Coding without first planning or thinking through is a programming method known as cowboy coding. Cowboy coders approach work with the mindset of coding without estimating or planning. And they are at a complete lost when the results achieved by their cowboy coding tactics does not meet expectations." (Cowboy Coder or Agile Programmer?,IT Career Coach). See also Conway's Law.

So Uche Ogbuji, lead developer of 4Suite, says an agile language is "characterized by quickness, lightness, and ease of movement; nimble" (Python is an Agile Programming Language, OReilleyNet). A blogger at Brain Bell suggests that an agile language is one that promotes the process qualities of simplicity, automated unit testing, short iterations (Java's New Job Description, Brain Bell). Some believe the language qualities should be simplicity, communication, feedback and (strangely!) courage (Python as an Agile Language). Others are more direct: agile projects will be built faster, making programmers more productive. (The Fast Track From Code to Cloud, TechNewsWorld; Python, an Open-Source Scripting Language). It's all about the speed.

Faster programming is against the belief of many agile practitioners. Although some advocates boast an order of magnitude increase in productivity, most believe that agile development has no increase in productivity at all. An agile approach makes deadlines short-term and realistic, and those deadlines are updated quickly when a change occurs. Deliveries are on-time because deadlines are more accurate, not because the developers are more productive.

What these people are actually talking about is a Barbarian language—a computer language that doesn't require thinking, learning or planning but that allows you to start typing right away and get immediate gratification (Compare with deferred gratification, Wikipedia) and play the solo hero. An agile language, if such a thing exists, should be Greek.

Theory 2. An agile language is a replacement for Java.

The Java language was designed to be a minimalistic, enhanced successor to C++. Most of the functionality was put into object classes and the decision to keep Java extendable meant adding classes upon classes. This overwhelming mountain of data types frustrated even die-hard Java fans. (This problem was so bad that it lead to IDE's with the smarts to walk the class tree for you (Eclipse, Wikipedia).) Thus Java is sometimes called "bureaucratic".

With Java's popularity in schools and universities, it's not surprising that many people with this Java-centric view of the world are looking for a new programming language that is like the Java they're used to.

Some blogs said that agile languages should be object-oriented, reflexive and be interpreted. (Is PHP an Agile Programming Language?, IBuildings). Others say that dynamically typed languages are agile while others disagree (Agile Languages, Niclas Nilsson). While object-oriented really describes Java, these other terms are ways of trying to deal with the class hell problem. Being reflexive answers the question "What class is this?" Dynamic typing means "I don't care what class it is." And using an interpreted language means seeing the results of your class choices faster. Unfortunately, many of these approaches have undesirable side-effects, like more costs when software must be maintained.

These complaints have nothing really to do with agile development. They're a gripe list against certain popular computer languages.

Theory 3. An agile language is one that makes programming fun.

According to a presentation by Paul King at Agile2007, a language is agile when it makes programming fun (Groovy: a language for Agile Development and Testing). Some of the other blogs mentioned here also list "fun" as an attribute.

This is one of the more bizarre definitions of an "agile language" and I'm not convinced that it is a good one. A Barbarian developer would think that a Barbarian language is fun because it doesn't require him to think or plan: his fun is programming for the sake of programming. A developer in a company doing complex design may think big design up front is fun. Or someone who only knows Java may think that languages that look like Java are fun. Fun is affected by the type of project, the development workspace, the personality and background of the developers. The language is only one factor in job enjoyment.

Theory 4. An agile language gives significant advantages to agile development.

This is the most obvious definition: that an agile language is one that's advantageous when using an agile process. For this to be true, the language must have major benefits, not something shaving a few hairs off the edge. The advantages must be obvious, impacting and measurable.

Mr. Durarte's blog says agile languages make changes easy (i.e. code maintenance), partial deliveries possible, and support unit testing. Well, unit testing tools are available to work with all languages. Even bureaucratic languages can do partial deliveries. And so-called heavy languages often list easy code maintenance as one of their strengths. It's not clear to me that any of the most popular languages offer any significant advantage over others in these areas.

The thing about agile development is that it's mainly about how people treat on another. The four qualities of agile that I listed at the beginning have little to do with a programming language. Take the language COBOL, for example. This language was designed so that programs would appear as close to readable English as possible so that product owners could read what the programmers were doing. This is in line with the agile philosophy. But many agile advocates would say that COBOL is one of the most un-agile languages around. Truth is, most product owners have little interest in the realm of computer languages—the manual and technical process of building the product. Agile is about people interacting with people.

I'm hard-pressed to think of any language that (using the list above):

• Inhibits interaction and demands business process
• Prevents working software while forcing the writing of unhelpful docs
• Blocks collaboration with customers and won't function without a legal contract
• Makes change impossible and instead demands compliance with a project manager's schedule

It would be surprising to find any language that had significant advantages for agile development.

Conclusion

So after a month of research into "agile languages", I must conclude there is no such thing. Barbarian coders are constantly looking to increase their speed to build the next new thing. Java developers are frustrated with their language's bureaucracy. Students entering the workforce are disappointed when a programming career is less fun than they imagined. None of these things relate to agile development. I'm not convinced a language could be built that would be a significant advantage to agile development. Software development methods are mainly concerned with people, while programming is about crafting code. They are really two separate problem domains. Anyone claiming a language is agile is trying to deceive you with hype.

October 18, 2010