Rock Climbing and HTML (or any Development)

I'm an old timer in Rock climbing.  Not the Faux climbing in the gym but on real rock with whatever surface erosion has provided for it.  I remember a boulder problem on Mt. Woodson that was called Television Screen (aka, Super Edge).  It was a big rectangular block that was tilted just off vertical with an irregular surface and this wonder edge that also had variations in it.  There was just enough of both to provide light hand and food holds to lie back off of while edging with your feet on the face.  It was rated 5.10 and just on the edge of what I could do with my new (then) EB climbing shoes.

I was so proud of finally being able to climb it with my new EB shoes.  Then a friend of mine just scurried up in the running shoes!  I could not believe it, regular shoes and much less effort!

The difference between the two of us was the context, me -vs- him.  I could do it but I needed better shoes and it was still hard.  He just needed to try.

The same is true of software development.  The rock is the project, the shoes the tools and the context is whom is climbing.  

This lesson reappeared in the tech press last week with a team at Sencha decided to re-duplicate the slow parts of the Fastbook app in HTML to show that it's not HTML's fault that the original FastBook app was slow.

In this case Sencha's Fastbook app is the project, the tool HTML and the context is the Sencha programmers.  The Fastbook project indeed shows a much faster HTML application using Sencha's tools and just HTML.  However they miss the point and the point is context.  What works in one context may not work in another.

The context is 1) the staff doing the work, the 2) other internal goals of the project and 3) a bucket of other restrictions, limits, requirements and forces that shape the outcome in any project.  Yes, given almost any tool, almost any project can be created and be successful given the perfect context (that is what Sencha had).  

But most context is imperfect and just like in Fastbook, the context did not allow the creation of an HTML application that was expected.  Re-writing the same application in native code would work given the same context and indeed did provide the expected application.

This lesson is replayed again and again for 1) design methodology, 2) project management, 3) language and tools and almost any other holy grail of development that is hyped in the industry.  Context beats all.

It's like that definition of insanity : "Doing the same thing over and over again and expecting a different result", but with a twist : "Doing the same project with different people, different processes and a different company and expecting the same result, is insanity".