Thursday, December 2, 2010

The perils of rolling your own

I spent a good portion of the early years of my adult life messing up my health by smoking. Even throughout my thirties I was an off and on smoker (or “social smoker” if you will) at various times.

It’s well understood that no matter what you smoke, whether regular cigarettes, “low-tar”, cigars, hookahs or even medicinal (or illicit I suppose) marijuana: inhaling smoke will screw your lungs up pretty good. For my part, I smoked hand-rolled cigarettes, which is probably one of the worst options: no filter to take out anything at all.

Smoking

In 2002 I moved from the UK to Boulder, Colorado in the US. For those that don’t know, there’s probably no place else on earth with a more militant anti-smoking stance than Boulder:
"In 1995... Boulder voters made national headlines and created a local uproar by expanding the city’s smoking ordinance to ban smoking in all indoor public place... The Boulder Dinner Theater had to get a special dispensation so an actor could light up on stage, as called for in a play."

From Insider's Guide to Boulder and Rocky Mountain National Park by By Ann Alexander Leggett, Roz Brown
As it turned out this was actually a great thing for me. It helped make quitting smoking and attempting a significant lifestyle change considerably more possible. Nonetheless, the first time I went to a gym and tried to run (for just sixty seconds!) I swear I nearly died. Humiliatingly, the gentleman on the treadmill next to me, easily older than my father, was barreling along at 6mph and hand been doing so for the last twenty minutes.

I definitely learned the hard way that rolling your own is bad.

I think this lesson translates into software development too. It’s often tempting to “roll your own” frameworks for various software development needs. At one point in time this was especially true for web applications. I’ve been to party this. Several years back we wanted an MVC web framework with AJAX support. There weren’t any at the time, or certainly none our lead engineer liked. So a couple of the guys I worked with wrote one. It was a cool project; fun and intellectually stimulating as well as educational. And we got to do things the “right” way, no more tolerating those parts of other frameworks we didn’t like. But it became the biggest albatross around our neck.

When you build your own proprietary framework there are several key problems:
  • Nobody's going to maintain it but you. This starts off as fun -- nobody else is "screwing" with your code, but quickly becomes a bind. In our situation in particular, with the AJAX/MVC web framework there was the never ending tedium of browser compatibility issues.
  • Dubious value. Is building general purpose frameworks *really* what you want to be paying your engineers to do? Is that *really* the business you’re in? Is it *really* the best use of their time?
  • It's hard! Sure, building 80% of the framework you think you want isn't too hard. But try finishing it. Try polishing it. That last 20% is tough.
  • Eventually the originators leave. You may think you've got the institutional knowledge for your framework well shared. But I'm willing to bet that if the main driver behind your home grown solution leaves it'll start to rot. A year later (if that) everyone will hate it. Not much longer and it'll be the reason why nothing can be done and everything about your product sucks (this is often melodrama but try countering it effectively...)
  • New employees have never heard of it. So they have to learn it. And, obviously you can’t hire anybody with experience in using it.
  • It lives...and lives and lives. Once you have products depending on your framework, extricating yourself from that can be difficult and costly. Just try convincing non-engineers that you spend time fixing this problem.
These are big problems and not to be underestimated. Based on my experience you should think very, very hard before you decide to commit to investing in building your own framework for anything.

The MVC/AJAX web framework we built years ago still limits us even today.

It was OK for the experienced highly-skilled programmers that built it. It was great for them to build rich one-off applications with. The trouble was, the business needed us to build dozens and dozens of cookie cutter applications…all similar but slightly different.

The trouble with that kind of work is that one doesn't tend to use experienced, highly-skilled programmers for it (or if you do, they don't stay around for long).

So then of course we had a framework that was hard for most of its users, and certainly wasn't geared to churning out cookie-cutter applications. They were frustrated and it was overly complex for the actual task at hand. Part of the consequences of that was we suffered the same defects and problems in the cookie-cutter applications over and over again. And it took longer than it needed to build them and longer than it needed to test them.

Once again, I learned the hard way that rolling your own is a really bad idea. We should have built a tool for building cookie cutter apps, not a general purpose web framework. Quickly and reliably turning out cookie cutter apps was the business we were in, not web frameworks.

P.S. if you've still got that itch to build a framework, how about contributing to an open source one instead?

5 comments:

  1. I think this is a bit misleading, Jon. Given the requirements and integration between server, thick client imaging app, and browser, I don't think there was a choice but to roll our own.

    As I recall, the debate at the time was not whether or not to roll our own framework, but rather what technology platform on which to roll it.

    Interestingly, today, I'm not sure there's a suitable framework to tackle the same problem. Maybe GWT. Problem with GWT is that you still need experienced developers to use it. Maybe what we needed was engineers who actually wanted to program in JavaScript. But again, at the time we started, the JS revolution had not yet taken off. I believe prototype.js was in very early stages and jQuery had not yet been released.

    I think the problem of cranking out cookie cutter apps hasn't been solved by anyone. The closest I can think of are CMSes and I have yet to see a CMS that wasn't a gigantic pain the ass.

    Maybe the root of the problem is that you need experienced and highly skilled programmers, period. Put a highly productive toolset like Ruby on Rails in the hands of experienced programmers and they can crank.

    ReplyDelete
  2. Also, I'm curious. I can see that not understanding the framework would hold the entire team back. But what were the bugs? Call this one professional curiosity.

    ReplyDelete
  3. @Ted -- Thanks for the feedback.

    It's true, we had build something to glue all that together. I just question whether we made the right choice. Hindsight of course is always 20:20. Still, I am not sure that we fully explored what we would have taken to (for example) coerce Struts into what we needed. And I firmly believe that as a general premise one should look very hard at whether you really need to build a proprietary framework if that isn't really what your business is.

    I don't believe you do need experienced and highly programmers to crank out cookie cutter apps. If you do you're in trouble, because that is boring work, and they won't want to stick around and do it.

    RE: solving the general problem we solved a good portion of it for generation 1 PI portal. We had a management application within which one could go (essentially) File --> New --> Portal app. Then a "wizard" let you walk through what features you wanted. There are other industry or company specific examples of this sort of application. Yes you sacrifice flexibility but ultimate I believe that is what was needed.

    Lastly, re: what recurring bugs? I'll drop you an email rather than comment here.

    ReplyDelete
  4. I'm curious why you didn't select and contribute to an open source framework to move it in the direction you wanted OR push this one out to the open source community to increase "ownership".

    Paul

    ReplyDelete
  5. Hi Paul. Thanks for your question, it's a good one. At the time this framework I'm mentioning was conceived and implemented at my organization I didn't have quite the influence I do today.

    For what it's worth, I reckon that contributing to an existing framework (likely Struts at that time) would have been the way to go.

    As it happens we did, from the outset, technically open source our framework. However without the community building and popularizing of it that wasn't as valuable a gesture as it might have been.

    ReplyDelete