"The Simplest Thing that Could Possibly Work"...or not

In a recent blog post, Jay Fields argues that the canonical (at least in the agile world) "Simplest Thing that Could Possibly Work" tenet might need some caveats:

Often the emphasis of the phrase is like so: the simplest thing that could possibly work. However, recently Ian Robinson was discussing the idea that the emphasis should be: the simplest thing that could possibly work. The difference is only emphasis, but it's a change worth considering.

I'd suggest that we go one further, and emphasize it as the simplest thing that could possibly work. When you think about it, what does it mean to work?

• To successfully compile?
• To run without crashing?
• To be well-designed?
• To be easily maintainable?
• To please users?

All these could be used as criteria for "working", given a particular context.

In my mind, ultimately the most important question to ask in applying this maxim is, "how do I define 'work'?"

Groovy Thoughts

I've been diving into Groovy lately...I just started a new job a few weeks ago at McAfee, and most of our application is written in Java. As a dynamic-language lover, it chaps me to think of spending all my time writing tests in Java. Writing tests (in this case, white-box tests aimed at business logic level functionality) has always seemed to me to be ideally suited to scripting languages.

I've looked at Jython and JRuby, and, as much as I love both those languages, it would seem to me that I want to leverage the Java knowledge as much as possible that exists here. Hence, I'm looking at Groovy. I'm reading Venkat Subramaniam's "Programming Groovy", and love the language so far. It seems to bring much of the dynamic language features (dynamic typing, optional semicolons, closures, automatically importing a bunch of Java classes) that I'm looking for. And it's a much easier sell to a Java shop than trying to get them to bite on a language (such as Java or Ruby) that's a total departure from what they have invested in.

It would seem we are exactly the type of Java users Groovy is aimed at. I'll blog more on my thoughts of Groovy (and I'll write a review of Venkat's book) in future posts.