There are many measures of code that are objective and metrics driven, but there are others that are more subjective and taste based. I can’t tell you from a quick glance how many afferent couplings there are in a given piece of code, but I do have an almost immediate sense of how elegant the code is. In my mind elegance is all about solving complex problems with simple solutions. That’s the art rather than the science of computer programming.

When I read some code and get that gut feeling that the solution isn’t elegant, one of the first pointers is often how long each method or function is and how deeply indented they get. If you open a class and it just contains a handful of methods that are short (no more than 2 to 4 lines in each) and reasonably named, I breath a natural sigh of relief and know that the class is going to be pretty easy to understand. If on the other hand, there’s some crazy-long Dostoevskian beast of a method that I can’t fully see without scrolling up and down, then I start quaking like an intellectual weakling knowing that I’m going to endure much pain trying to grok what was in that coding genius’ mind when they wrote it. Then once I’ve worked out what they were trying to achieve I’ll have to go and figure out what they actually achieved … in long complicated methods the implementation often diverges from the intent!

Much of this complexity is immediately evident in how the code is nested and indented. Every indentation is the site of some kind of logical fork in the possible pathways through that method. Put in other terms there is a close correlation between the cyclomatic complexity (CCN) of a method and the amount of nesting and indentation. Or explaining this classic metric for complexity another way: each indentation is an invitation to extract a method into a beautiful, small, testable, readable and well-encapsulated unit.

When you’ve spent time living in a codebase where people vigorously accept these invitations to refactor that are offered up by our friend white-space then you tend to have a gut response of pain, horror and loathing when you see a heavily indented chunk of code.

The differences between these two styles of coding is clearly visible in the profile of the first non-whitespace characters on each line. If you look at the code and blur your eyes a bit this profile can look rather like the little LEDs on a graphic equalizer. The profile of indentation within a given source file composes a revealing signature that can be interpreted as a sound wave. Imagine hooking up a music player that could read these patterns. The heavily refactored codebase would purr gently at you with soothing sussurations, while those deeply nested and psychotomatically complex methods would scream at you like a shrill and brain-scrambling siren on a police car.

So step up please you gurus of mashing up Eclipse plugins with Garageband and create me a little plugin that will sing a song of source code whenever I open a file. But before you do that, maybe I should reach for the earmuffs.

The mailing lists at ThoughtWorks have been running hot since Jay Fields stoked the flames of the dynamic versus static language schism. His basic point is summarized in the opening line:

“Given a good test suite the return on investment simply does not justify the use of static typing”

Basically he’s saying that statically typed languages have benefits, but there is an associated cost – anyone who’s seen object definitions disappear off the screen with Java 5 generics will understand this. The benefits definitely exist – modern IDEs (auto-complete, refactoring, etc), compiler optimizations, basic verification and clarity in communicating integration requirements – but there is also a cost incurred in terms of complexity and inflexibility. Neal Ford has started calling this the “static type tax”. Jay’s solution is, rather than relying on static typing for partial protection, rely on tests for full protection.

Work to rule

This pain or tax associated with static types reminds me of the parody of union rules gone bad – “I can’t plug that in, I’m a carpenter, you need an electrician”. These rules start out having important uses (protecting workers against abuse and ensuring quality results), but can end up just causing pain and making the jobs they’re trying to protect less secure by making the industry less responsive. There is an obvious correlation with the trade-offs between dynamic and statically typed languages: it’s nice to know from an integration and tooling perspective exactly what type of object a method requires; it’s also nice just to be able to give that same method any object that can respond to the messages it will be sent.

In strong and statically typed languages, like Java, the method signature is a shorthand explicitly stating what type of object is required for the method to work. In a dynamic or weakly typed language, like Ruby or JavaScript, you have more flexibility about what you can pass into the method, but less visibility into whether it will work or not – you have to check (visually or through tests) that the object you pass in can respond sensibly to the instructions it’s given.

One of the pains of the statically typed method signature is that various different requirements tend to get bundled up together. A method may well require a parameter to be of type (implement interface) X, where interface X defines 10 methods, even though the method will only call one of those declared methods. Ideally you would define a new interface for each combination of methods you want to call so you can keep the contract as simple to fulfill as possible, but this in itself would be a burden as the amount of interfaces would explode.

Risk assessments

The arrival of complexity and restriction in the name of preventing accidents (passing an object that can’t react to the messages sent to it) reminds me of how school trips have become harder and harder to organize because of the ever more stringent “risk assessments” required:

“Endless lengthy risk assessments and fears of being blamed if anything goes wrong have put teachers off taking children away on trips and led to youngsters being cooped in classrooms instead.”

I remember loving some fairly wild school or youth club trips as a kid. Rock scrambling was one of my favorites, which involved climbing, jumping, swimming, hopping and whooping round sections of coastline like the beautiful Lulworth Cove. Sure there were risks involved, but learning to handle yourself in those risky situations lead to really important lessons and personal growth. Risk breeds responsibility.

I have similar feelings about using dynamic languages – with great power comes great responsibility. Programming itself is inherently risky (when was your last zero-defect release?) so programmers have to make decisions about how to act responsibly. One way is to impose risk assessment forms on every method call through static typing; another option is to force objects to act responsibly and be good citizens. This is the route that interests me more. Testing definitely plays an important role in acting responsibly, but it’s not the end of the story.

Team collaboration : object collaboration

Coming back to the analogy of objects as workers on a job, rather than using strict role definitions in an attempt to control quality, I would much prefer to use the example of self-organizing Agile teams. On an Agile development team there is an expectation that people can work in a cross-functional manner with common ownership of the code-base. This means that team members should be interchangeable and comfortable in a variety of areas – just like in dynamic languages there is no type checking before picking up tasks (“sorry I only do JavaScript / Java / SQL”). This leads to highly flexible and productive teams, but there are a few techniques needed to make it work. Some of these techniques are conceptually transferable to working responsibly with dynamic languages:

• communication
• simplicity
• responsibility

Explicit and clear communication is the biggest of these – the others can be derived from this principle. The importance of communication in teams is fairly obvious, but it can also be important at the code level in areas like explicit tests, clearly named methods and transparent intentionality.

Simplicity aids communication and also lowers risk. The simpler the routine is, the easier it is to understand, the easier it is to see what is required of collaborating objects and the less likely it is that bugs will creep in.

Responsibility underpins this all. In teams it means talk to people if you’re not sure, or tell people if you’re going to do something strange; in objects it means testing your interactions, handling errors appropriately and checking compatibility where necessary.

Managing Ant target dependencies

“depends” are great, until your build file gets bigger than a couple of screenfuls. You can end up with a crazy spaghetti monster of dependencies very quickly. On a few builds I’ve worked on we’ve had a basic rule:

Targets can either have depends or a body, but not both.

So you end up having two types of targets:

• “functional targets” that actually do the work, carrying out small individual tasks
• “flow targets” that tie the functional targets together

<target name=”the.lot” depends=”compile,test,jar,report” />
<target name=”compile”>
…
</target>
<target name=”test”>
…
</target>

Public vs Private targets

I’ve built build files using the public and private target idea (affix a “-” to private targets so they can’t be called externally).

It can work in some situations and makes it reasonably clear what’s going on. It can also work in conjunction with the “functional and flow” targets described above. (Functional targets are private; flow targets are public).

My main issue with this approach is that as a build engineer you often want to call internal / private targets to run just a small step in the build (particularly while developing new features) – you can’t do this if the targets are private. so you end up creating a second, public, target that calls the private target … and you end up doubling the size of your build files.

I prefer just to have the main entry point targets (your flow targets) at the top of the build file so it’s obvious to anyone who opens the build file what they can use.

You can also differentiate your public (API) targets by only allowing them to have description attributes. These will be the only targets listed when your run “ant -p”.

Macrodefs with closures

Macrodefs are great and should be used to reduce duplication wherever possible.

An extra-powerful feature of macrodefs, which I only came to understand recently, is the ability to pass arbitrary ant elements into macrodefs – think closures / ruby blocks.

We now have expressive parts of our build scripts looking a bit like the following:

<for-each-module>
<compile module=”@{module}” />
</for-each-module>

<for-each-module>
<test module=”@{module}” />
</for-each-module>

<macrodef name=”for-each-module”>
<element name=”action” />
<sequential>
…. do some stuff …
<action />
…. do some more stuff …
</sequential>
</macrodef>

I’d be interested to hear if anyone has other suggestions for keeping Ant from spiraling out of control.

The good people at MIT have put together scratch a visual tool allowing kids to do drag-n-drop coding. The help screens give a good idea of how it works. Basically differently shaped blocks are put together (lego style) to form programs: a loop looks like a capital C and holds all the nested statements; booleans are pointy ended and only fit in pointy slots – likewise numbers are round and only fit in round slots … a nice simple introduction to strongly-typed languages. It actually fits pretty closely with how I visualise blocks of code, so it looks like a great way to introduce children to the coding mind-set. The welcoming colourful blocks are non-threatening and simple to understand.

If that all seems too point-n-clicky then there are also efforts to get kids using Ruby. It’s a simple hosted and sandboxed service giving children the chance to write real programs – like a blog in just 6 lines.

This block caught my attention:

WHITHER ART THOU, BASIC??

In the 1980s, a language called BASIC swept the countryside. It was a language beginners could use to make their computer speak, play music. You could easily draw a big smiley face or a panda or whatever you like!

I’m interested in their choice of Ruby as the simple “gateway” language (the first one’s free, tell your mates), since there have been various discussions about whether Ruby is too complex or powerful for many inexperienced QA and dev teams to be *trusted* with.

It’ll be interesting to see how these kinds of tools are adopted. Either way I think some people at my current client could use a more pointy-clicky programming language …

I’ve seen some demos of Mingle and it looks great, but of equal interest to me is the choice to release it on JRuby. This seems to be another step along the road of Java moving down the stack. Java was selected as the delivery platform because corporate IT understands how to deploy, integrate, support and optimize it; Ruby was chosen as the development language because of the productivity and expressiveness of the language.

I don’t want to knock Java – it’s provided my bread and beer for 10 years, but there are many strong arguments for using more concise and expressive languages to encode business logic.

So it looks as though Java is moving more into the space of an OS rather than a language for building business logic. Our illustrious founder, Roy, suggested that Java’s legacy will be the JVM – years have been spent optimizing it and making it run on many platforms. I would add to that the ecosystem of libraries integrating with a panoply of databases, messaging formats and middleware.

JRuby allows Ruby to leverage this whole ecosystem. Operations teams are completely comfortable managing Java installations – they don’t tend to care too much what’s in your WAR or EAR as long as they can monitor and configure the JVM, datasources, queues and other resources.

One question that springs to mind is whether this is just a temporary stage while the Ruby deployment stack matures or whether it will be a lasting situation. It would seem odd to need all the extra infrastructure, but the current situation is that even though many apps are deployed on highly expensive Java containers (think IBM and BEA) most of them will still sit behind Apache. They do this because Apache is more trusted to manage security, redirection, static content delivery and various other web fundamentals.

So maybe the new stack will be:

• Apache handling the HTTP piece
• A Java container handling the Integration piece (with or without a captial E in front)
• Ruby (or other languages leveraging JSR 223) to handle business logic

It will be interesting to see where this goes, but I can’t help feeling there’s one too many pairs of hands in that stack.