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.