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.
Ruby on Rails: Serious Software?
As a veteran of two and a half decades of this battleground we call Information Technology, I’ve seen a lot of technologies come and go, and I’ve seen a lot of companies fail to embrace technologies that could have made a significant difference in their ability to deliver software quickly and efficiently. Sadly, in far too many cases, IT leadership (management and senior architects) adopt a play-it-safe approach, opting to “ride it out” with tried-and-true technology stacks while their competitors (often smaller, newer and more nimble) embrace and fully exploit modern advances in technology.
Fifteen years ago, this often meant opting to continue to build mainframe-based applications using stalwarts like COBOL and CICS rather than upstarts like Java. Today, it means avoiding modern languages and frameworks like Ruby on Rails, favoring the safety of the familiar – Java and C#.NET.
In recent months, I’ve had the privilege to conduct “architecture assessments” for three very different companies – two large, established firms with large IT groups and well-established architectures, and a new, small firm with almost no permanent IT staff and a “do what makes sense” attitude toward technology.
The differences among these companies is striking. The largest and most established of these companies, coming from a strong J2EE background, was busy rebuilding a set of customer-facing applications, purportedly to increase reuse of components among them, and to reduce the ongoing cost of maintenance. This project, which was having some serious challenges, was not only using dated J2EE technology, but was piling an incredibly heavy, layered architecture on top of it – resulting in application code that – reuse benefits aside – is going to be as difficult to maintain as anything they currently have in production.
The smallest of these companies, in stark contrast, decided to throw away a VB.NET application that was only six years old, replacing it with a lightweight application my company built for them in Ruby on Rails, which is easily, without exaggeration, fifty times simpler to customize and maintain than the application it replaced.
This set of experiences has had me thinking lately. How much could be accomplished in large, established companies – which tend to have sizeable groups of talented software engineers – if they were to cling to the safety of the past a little less tightly, and more aggressively seek to harness the power of modern languages and frameworks?
Having personally built applications in technologies ranging from COBOL/CICS to PowerBuilder to J2EE to Grails and Rails, I have seen the steady increase in productivity offered with each set of advances in technology. I have also witnessed companies fail to embrace these benefits until well after their competition had done so, nearly always to their detriment.
If you are a CTO, IT manager, architect, or anyone who is responsible for the technical direction of your company’s suite of applications, you owe it to yourself to learn as much as you can about modern, dynamic languages (Groovy, Ruby, etc.) and the web application frameworks built on them (Grails, Rails, etc.). The leading reason companies tend to avoid these technologies – slow execution speed relative to Java or fully compiled languages – is usually given more importance than is warranted, since most performance problems tend to stem from sluggish database interactions or network data transmission time. And many large companies tend to overstate their own performance demands. Sure, your internal applications get a lot of use, but are they really under more of an onslaught than the thousands of public-facing web applications built in dynamic, interpreted languages?
Consider this an open letter to the guardians of reference architectures across the Fortune 1000. Do yourselves a favor. Do not ignore Ruby on Rails. or Groovy and Grails. There’s a whole segment of applications tailor-made for these technologies, and far too many of them are still being built with Enterprise Java Beans, by teams that are far too big and not nearly productive enough.
