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,
is described as an "agile
dynamic programming language" on its
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
Greeks organize things, Romans organize people, Barbarians barely organize anything.
Greek methodologies are informal, Roman ones formal, Barbarian ones nonexistent.
Greeks write programs, Romans manage projects, Barbarians leap to coding.
Greeks are motivated by the problem at hand, Romans by group goals, Barbarians by heroics.
Greeks minimize the amount of documentation produced, Romans maximize it,
Barbarians take pride in doing no documentation.
Greeks work in small groups, Romans in large organizations, Barbarians work solo.
Greeks use things as tools, Romans use people as tools, Barbarians avoid tools.
Greeks are democratic, Romans are imperial, Barbarians are anarchists.
Greeks are empirical/inductive, Romans analytical/deductive, Barbarians are unthinkingly emotional.
Greeks are intuitive, Romans logical, Barbarians impulsive.
Greeks are a meritocracy, Romans a "function-ocracy," Barbarians a "fear-ocracy".
Greeks emphasize substance, Romans form, Barbarians lines of code.
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
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
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
Theory 3. An agile language is one that makes programming fun.
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.
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.