Wednesday, 6 June 2012

Capital Goods

Humans are the only species capable of developing capital goods - things that help you do other things. A spade was better at digging than a bare hand, and a JCB digger is better than a spade. And even though it's expensive it's cheaper than employing the several men who would be needed to do the same work.

This all sounds fine. But there is a "but" ... and it's the people who design and develop the capital goods.

If you are the designer what do you do when the JCBs start rolling off the production line? Do you say your job is done and apply to be a JCB driver? Not likely! You take another sheet of paper and set about designing another digger.

And the same happens in the software world. Back in the day (not long ago - 2003) there was no Rails and few people knew about the Ruby programming language which is also young (1995) and very clever. 

Then along came an incredibly clever young man called David Heinemeier Hansson (Google DHH) who realized that you could automate so many of the chores involved in developing a web application. It was a bit like the step from the spade to the JCB. And Rails attracted a following and evolved to version 2.something at which stage it was a pretty complete product - a working JCB if you like. 

However the developers didn't leave it there, they went on to make Rails 3 (and they are still evolving the product). My guess is that as many man hours (are there women on the development team?) went into the step from Rails 2.3 to 3.0 as went into the development up to version 2.3. But from the users' point of view Rails 3 is not much more than a new bucket attached to the JCB. 

The law of diminishing returns has kicked in with a vengeance - as it always does.

And it seems to me not only that a lot of effort is going to produce relatively small improvements but also that much effort is being absorbed with complex solutions (which show how clever you are) where simple ones would be as good or better for the end user.

A good example is the JQuery-Rails gem. All it really does is supply a few Javascript files and copy them into your Rails application. Wouldn't it have used less of mankind's resources to package them in a Zip file with a short Readme to explain where to put them? And the simple approach would allow the web developer using Rails to see what was being done and fix it if necessary.

Joel Spolsky wrote a blog piece about this sort of complication 10 years ago - The law of leaky abstractions

By the way I am just using Rails as an example. The same process occurs in all professions.

No comments:

Post a Comment