Force Multipliers & Boilerplate Modules

Ravi Mohan (@ravi_mohan)
8/26/12 10:46 PM
Advanced languages (among other things ) are force multipliers. But if you are writing the n-th CRUD app you are multiplying by zero

This very much fits into some of my opinions that have been firming up over the past couple months. A year of quite-deep immersion into real-world functional programming (Gemini Observatory made a strategic commitment to Scala last Summer for “high-level” software) has, as always, left me somewhat dissatisfied. As Ravi says, on the one hand I’m quite happy to assert that when facing an interesting algorithmic problem there is a “force multiplier” effect of having a good type system, easy-to-use higher-ordered functions, libraries, etc.

But, even at an observatory, “interesting algorithmic problem”s are not the core of the software developer’s workweek. Instead, what we spend most of our time developing are aspects that relate to the database, UI, infrastructure, devops, and administration. Here, the “force multiplier” of a powerful language is, as Ravi says, multiplied by zero: this semi-boilerplate work is so well-understood that “tools that help you reason” give you no advantage and the burden they impose (importantly: edit-compile-confirm times of minutes) is significant.

Meanwhile, it’s painful to pay software engineering rates (especially “software engineers who can solve interesting algorithmic problems” rates) for semi-boilerplate work. I’ve been wondering if the answer is a shift towards API/Library production (using statically-typed “advanced” languages) as the primary software engineering deliverable and UX (using dynamically-typed “high productivity” languages) as a task for a separate … but it isn’t. The idea of stratifying development, fiefdoms, etc., surely that’s a bad idea…

div>