Small, Powerful Teams
Much has been written about the many ways Ruby on Rails makes developers more efficient in terms of business features produced per unit of time, or line of code. Syntactic sugar in the language. Nary a line of boilerplate code anywhere. A plethora of plugins and gems to do the dirty work and keep you focused on higher-order features.
It seems that far less has been written on the consequences that hyperefficiency can have in an organization. On the surface, it’s obvious – teams are more efficient, so they create features more quickly, and projects get done faster. Sure, that’s true – but dig a little deeper and things get more interesting.
Most would agree that like so many things in life, the raw talent of IT professionals, in aggregate, is distributed along a bell-shaped curve, and that accordingly there are precious few “rock stars” out there. In traditional IT shops, the best and brightest, in order to have the most impact on an organization, tend to be surrounded by large teams, and spend their time creating designs, helping to solve problems others bring to them, and generally dispensing wisdom. There’s an economic reason for this – given the tools, languages and frameworks we have all been using, there is no way that even a small team of elite minds could produce any software of real significance in a timeframe that matters to the organization. So we have large teams, populated with people from both halves of the bell curve, with the “outliers” leading the way.
But that is changing. With high productivity language/framework combinations like Ruby on Rails, people are discovering a new way to leverage the best and brightest. Suddenly, significant software can be developed by two or three developers in two to three months. Sprinkle in a bit of engineering discipline (DRY, TDD, etc.), and the software that emerges at the end of one of these projects will be a shining example of what software can be – code that actually realizes business and design goals, and does so elegantly and efficiently. The iPhone of the software world.
Sadly, in traditional environments, this almost never happens. Through brute force and much testing and debugging, most applications come close to meeting business goals, but they are so inelegant and internally compromised that they are very costly to maintain, and difficult to adapt to changing business requirements. Why? In old-school leverage, the visionaries could realize their ideas in real software only by describing that vision to the people who were actually writing the code. And depending on the communication skills of the visionary and the ability of the development team, the degradation of that vision might range from severe to only mild. Can you imagine what Beethoven’s Ninth Symphony might have sounded like if he could only hum the theme and describe the countermelodies, and have a group of scribes do the rest of the work?
But put that visionary (or small group of them) in front of keyboards and let them have at it, and you have a whole new ballgame. Not only is there far less time spent communicating the vision, but those who see it most clearly are able to express it directly in code.
This, more than anything, is why I’m excited about RoR and similar languages and frameworks.
A little Groovy magic – Lists and Property Accessors
Dynamic languages like Groovy and Ruby are all about productivity. Not only do they eliminate the need to write tons of boilerplate code, they also contain all sorts of “syntactic sugar” – language features that let you accomplish a tremendous amount of work with very little code.
Most of these features – closures, ultra-convenient collection-oriented operators like the spread-dot (*.), etc., are well-documented. Some, however, are a bit more arcane, and not realizing they exist can actually cost you a lot of time if you stumble into them inadvertently.
The feature I have in mind at the moment is a very convenient but somewhat surprising bit of collection behavior in Groovy. I’ve been working with the language for quite a while, and have dutifully pored over books and language reference documents to become familiar with all of the groovy goodness at my disposal, but somehow I missed this one until someone on my project team found it – quite by accident.
Here’s the magic find. In Groovy, if you have a list of objects, you can access, on the list itself, properties that belong to objects within the list. The result, somewhat intuitively (but somehow quizzical at the same time), is a list of values of that property across all the members in the list. Here’s an example to illustrate what I mean – just copy this and run it as a Groovy script.
class Player {
def name
def teams
public String toString() {
"${name} - played for ${teams}"
}
}
def players =
[
new Player(name: "Greg Maddux", teams: ["Cubs", "Braves"]),
new Player(name: "Ron Santo", teams: ["Cubs", "White Sox"]),
new Player(name: "Billy Williams", teams: ["Cubs", "Athletics"]),
new Player(name: "Bruce Sutter", teams: ["Cubs", "Cardinals"]),
new Player(name: "Lou Brock", teams: ["Cubs", "Cardinals"]),
new Player(name: "Gary Gaetti", teams: ["Twins", "Cubs"]),
new Player(name: "Ron Cey", teams: ["Dodgers", "Cubs"]),
new Player(name: "Ryne Sandberg", teams: ["Cubs"]),
new Player(name: "Mark Grace", teams: ["Cubs", "Diamondbacks"]),
new Player(name: "Goose Gossage", teams: ["Athletics", "Yankees", "Cubs"]),
new Player(name: "Sammy Sosa", teams: ["Rangers", "White Sox", "Cubs"]),
new Player(name: "Larry Bowa", teams: ["Phillies", "Cubs"]),
new Player(name: "Rick Monday", teams: ["Dodgers", "Cubs"]),
new Player(name: "Dave Kingman", teams: ["Rangers", "Mets", "Cubs"]),
new Player(name: "Joe Girardi", teams: ["Cubs", "Cardinals", "Yankees"])
]
def playerNames = players.name
println "Here, amazingly enough, is a list containing the names of all those players:\n $(playerNames)"
Once you know this behavior exists, it’s pretty easy to find situations where it’s an insanely convenient feature. If you don’t know it exists, you can get some pretty confusing results. In our case, we were running a GORM query to retrieve a domain object using an alternate ID (expecting a single result), and incorrectly used the list() method (we should have used get(), which returns the domain object, whereas list() always returns a list).
In our code, after querying for the domain object, we accessed properties of the object, and were puzzled when instead of getting Strings and Integers and Dates, we were getting single-member lists of Strings and Integers and Dates. Each list contained the value we expected, inexplicably embedded in a List instance. It took a little head-scratching before we figured out that the root cause was that our query was returning a list containing our domain object, and our code that accessed the properties, which would have failed miserably in Java if attempting to treat a List as though it were a domain object, was happily drilling through the wall of that list and getting at its contents.
Syntactic sugar? Definitely. Violation of the principle of least surprise? Maybe. Will I use it, now that I know it’s a tool at my disposal? Absolutely.
Stay Groovy, my friends…
