Agile Zone is brought to you in partnership with:

Jon Archer is a software professional with over 15 years experience who is lucky enough to work out of his mountain retreat high above Denver in the Colorado Rockies. He has worked as a software engineer with various technologies during the course of his career as well as a couple of diversions managing teams. These days he is the scrum master for a challengingly distributed team with members in Massachusetts, Colorado and Hyderabad India. He is a passionate believer in agile principles and is a key advocate thereof for his current employer Perceptive Informatics. He blogs at and tweets as @9200feet Jon is a DZone MVB and is not an employee of DZone and has posted 19 posts at DZone. View Full User Profile

The perils of rolling your own

  • submit to reddit
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.


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?
Published at DZone with permission of Jon Archer, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Saad Khawaja replied on Tue, 2010/12/07 - 2:12pm

This also applies to other kinds of software that are re-invented in the enterprise like build tools,web servers,etc just because the enterprise did not allow tool x,y or z or some developer wanted to enhance their resume. 

In the enterprise when you re-invent the wheel it usually comes out a square.  Then you ask why is it not working and you get an anwser that you are not pushing harder!

Liviu Ionescu replied on Wed, 2010/12/08 - 9:42am

Why did Microsoft invent EF and did not adopt NHibernate or contribute to it?

Web frameworks are really big beasts, but there are cases when building your own mini framework can solve your problems....



Cloves Almeida replied on Wed, 2010/12/08 - 5:58pm in response to: Liviu Ionescu

There are "big beast" web frameworks like Struts, Tapestry, JSF. And very simple ones like Play, Django. As the author said, nowadays when you really need to build your own framework, for the effort it better cure cancer...

Lóránt Pintér replied on Thu, 2010/12/09 - 10:34am

Nice post, Jon, though I couldn't figure out the connection with smoking: rolling your own cigarette is only slightly worse than the factory-made stuff, and that is pretty bad already, while not rolling your own framework is in general the best thing you can do.

Anyway, there is another cost you have to pay when you decide to roll your own implementation for some fundamental part of the system where other, widely used solutions would otherwise be available.

Popular systems usually have connectors to other popular tools. You can use them out-of-the-box in Hudson, test them with Selinium etc. Your own tool will need "just another touch" to make it compatible with anything. That is, if you are lucky, you'll end up maintaining not just your own framework, but your hand-rolled connectors to whatever other tools you want to use. Plugins to various systems will sprout up like in springtime.

If you are less fortunate, it could turn out that your self-rolled system is fundamentally incompatible with the outside world, and you'll end up either not using industry-standard best practices like CI and TDD, or you'll start to roll your own CI and testing frameworks. Beware of this cancer.

Emma Watson replied on Fri, 2012/03/30 - 3:11am

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.

java program

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.