Scott Ambler’s The Discipline of Agile on DDJ deconstructs a myth surrounding agile development, namely the fiction that agile development or XP is for undisciplined cowboys. Perhaps my favorite part of the article is the checklist at the end which helps identify cowboy coders and actual agile teams:
- Take a test-driven approach to development.
- Work very closely with their stakeholders on a daily basis, and the stakeholders have active roles on the team.
- Produce working software on a regular basis and can show a clear track record of doing so throughout the project.
- Work in an open, collaborative, and self-organizing manner.
As I read, I started to wonder if one huge disagreement between up-front processes and agile processes is in where they expect discipline to avoid nasty surprises. Processes with plenty of up-front requirements and design and little flexibility for change within the development, integration, and testing processes try to prevent change from occurring and put the discipline on the process to deliver the right software by enforcing adherence to the process.
Agile development puts the discipline on the participants, expecting their professionalism and desire to succeed to help them pay attention to feedback, react to change, and work together in a disciplined way to create the right software.
It’s easy to draw a parallel between certain programming languages and these styles too. Java’s easy to pick on because of deliberate design decisions made to limit the damage of bad programmers — no operator overloading (sorry scientific programmers, your numeric analysis libraries are going to have lousy APIs), no multiple inheritance (and no, Java interfaces don’t solve the interesting problems in genericity and code reuse), and don’t even ask about the use of final in the standard library (no one could possibly think of anything to do with String that Sun’s coders hadn’t already identified in 1994).
Throw in the absolute necessity to use IDEs and other large tools to manage codebases, as well as the community process which rushes to standardize any possible solution into a huge standard library whether anyone but the vendors even wants or supports the API or framework, and you have suddenly a lot of jobs open for a lot of programmers who can’t do much damage because all they’re doing is gluing library A to library B lather, rinse, and repeat.
That’s not to say that you can’t write good code in Java, nor that agile teams can’t use Java, nor that no one who writes Java is a good coder. It’s just that the language and the culture and the libraries and the platforms and the tools seem to encourage one single style of coding that lets large teams of barely-competent monkeys churn out unhideous projects.
Contrast that to the dynamic (or as I like to call them “agile” languages) which offer a lot more flexibility in everything from syntax to code organization to personal style. They may not always have the kind of tool support that lets you press Ctrl-K and then pick from a drop-down list the exact method you think you want to call at that point, and you may have to learn exactly how much boilerplate you don’t have to write rather than having your IDE generate screen after screen of repetitive accessor code for you, but they often offer a rapidity of development and feedback that lets disciplined coders write code and experiment and deliver very quickly.
Again, that’s not to say that a barely-competent monkey can’t bang out some hideously ugly Perl (or Ruby or Python or Haskell… well maybe not Haskell) code that suddenly thinks that the year is 19100 instead of 2000 or offers a spam gateway through a simple web contact form, but bad coders will write bad code in any language, with any process — and Scott Ambler’s rules for identifying good agile teams are a pretty good start for identifying good coders.
Maybe it’s worth considering relaxing the constraints of language, platform, tools, and development style along with relaxing the up-front demands of process.
Funny, I have never heard Scientists complaining. In fact, NASA is poised to jump headlong into the Java world. Not that I "love" Java (I reserve that feeling for Perl) but Java makes tradeoffs just like every language does.
When you say "dynamic" languages, are you implying that the only "Agile" languages are dynamically typed languages? And why is it that flexible syntax/code organization/personal style makes a language "offer a rapidity of development and feedback"? Isn't that more an aspect of the "chattiness" of a language?
In other words, what does Ruby have that OCaml doesn't that makes Ruby an "Agile" language and OCaml not?
The intent behind closing of class String is not to close it to extension (although this is a side-effect) but to preserve its value-semantics: it's impossible to change the value of a String, an essential property for its use as a hash key.
@Robert Fischer, perhaps that is a sloppy use of terms. I suppose that, when pressed, I'd give a more formal definition of "dynamic" with terms that include late-binding and generic programming without recompilation. (I'm flexible on late binding as well; Haskell supports pretty decent genericity with its extensible type system without, at least in my modest experience, requiring that you recompile or, worse, re-edit existing code.)
I haven't used OCaml, so I can't compare it.
I mentioned flexibility of syntax as a placeholder for saying "Wow, Java is verbose and doesn't allow much in the way of syntax-level abstractions." The ultimate example of syntax malleability is Lisp, but Perl and Ruby are flexible with regard to their syntax, and Haskell allows you to define new infix operators as well.
@Stephen, I'm not sure I understand. I would think that making strings immutable at least with regard to the VM would serve that purpose. I would think that allowing users to subclass
Stringwouldn't harm that goal, at least for code that follows Liskov.Perhaps I'm misunderstanding what you mean.