2011-11-24

Tools that make a difference

When I first started out in the software product development business, new and shiny tools frequently captivated my imagination.

Over the years, I've come to see that very few new tools truly let you do new things, or offer improvements more significant than the costs of their adoption.

First, let's go over two disappointments:

Ruby on Rails is marketed as a way to reduce time to market. It delivers, when your product is trivial microsites. Otherwise, the investment it requires, and the restrictions it imposes, more than offset its merits.

Likewise with Scala. It's sold as an improvement in language expressivity, but confuses "more" with "better". It's not better for the vast majority of business missions to be able and encouraged to perform the same primitive operations in six different, largely unlegible ways. It's perfectly OK if your mission is to produce academic papers, or sell a maximum amount of consultancy hours, but for a customer of product development, a loss both in the short and long terms. And that's even without going in the whole matter of upwards compatibility.

From the bitter comes the sweet, however, and a few tools which truly make difference have come out of the innovation around these things:

HAML is the best way to describe XML/HTML templates I've yet to come across. It introduces conceptual and communicative symmetry without taking away anything important. On the JVM side, Scaml is an implementation of the same ideas.

GitHub (and Git) changed small software project management. Its predecessors (SourceForge, other forges, java.net, Kenai et al.) were stuck in a rut with the concept of how people can fix bugs and customize existing software projects, and get those changes included in the upstream. The concept of person/team specific repository namespaces, pull requests, and the fork and merge big red buttons have let me do things that I'd otherwise not done, as well as easily include others' work.

JRebel has helped me to rapidly deal with a project in which I had to make changes to an extremely slow-starting undocumented buggy component, that hadn't originally been built to be testable. Most of the time, JRebel just works, especially with a Spring stack. When I've had problems with it with less-reliable just-released JEE6 stack components, Anton has responded to support mails in hours.

0 comments:

Post a Comment