Code generation and object-relational mappers are nothing new. When we built our own company framework in 2006, there were already plenty of comparable ones out there that we could’ve used. Certainly, it would have saved us countless hours of work in the beginning. Building any framework from scratch is a daunting task, especially when we know there are others that have been worked on for years.

So, in this plug-in happy culture, it begs the question, why would you ever roll your own framework, platform, or plug-in if there’s something out there potentially just as good?

For me, there are three big reasons.

An Intimate Understanding of the Problem Space

When we’re writing our own tool, we have no other choice but to completely immerse ourselves in the problems that the tool is desperately trying to solve. We must become experts in that domain. There’s no going, “Well, I downloaded this library, copied this snippet of sample code, changed some of these parameters, and...I dunno, it just seemed to work.” There are few things more unsettling than a programmer not knowing why something works but that it just works.

For example, many ORMs “lazy load” data by default, grabbing an object’s relational data from the database only when it’s been accessed in the object, instead of loading the relational data from the database up front. This is particularly efficient because the framework makes a database request only when we ask for it. There’s less data stored in memory at any given moment.

For the novice ORM user, this might just be a nice-to-know type of thing. She might just keep programming against it without really concerning herself with the concept. In her test environment, the database has a sparse few test records, and the code she’s writing against the ORM to pull back data is doing a dandy job. It just works.

But once she publishes her code to the live environment and real data starts to flow in, that seemingly benign little snippet of code she wrote using the ORM suddenly starts to bring the server to its knees. For example, an innocent piece of code like this...

...is actually making a database call for every person in that company to access his or her office location. That could mean thousands of executed queries in just a few lines of code.

When we’re the ones building the tool, we have to know where all the potential gotchas live. When we’re just the ones using other people’s frameworks, we can let those gotchas slip past our radar until it’s a little late.

Finding a Core Problem and Doing It Better

No matter what’s available in the vast landscape of prebuilt tools, you can find a small sliver of something that can be done in a better way to fit how you program—to better conform to the types of apps you build.

In my case, the reasoning was simple. There wasn’t a framework that would custom generate ActionScript objects that would directly tie into a database model. If I were to use something off the shelf, I’d likely have to use two distinct pieces of software: one to build up my .NET layer and a second to create ActionScript classes. If I ever made updates to my data model (which was often), I’d have to then rebuild these two disparate pieces of my application separately.

X2O is, in many ways, just like every other code generator, rapidly building objects that map to a database schema. But it is specific to the core needs of our business. No other tool generates code in the exact way X2O does. As our business grew over the first couple of years, we would tailor our software to our development workflow rather than let a piece of software we had no control over dictate how we worked. Building a code generator specific for database-driven Flash applications was the one fight we wanted to pick with what was out there. It was the problem we wanted to solve better.

The development team at Stack Overflow also went this route by writing their own micro-ORM. When they first released their programming forum site, they chose LINQ-2-SQL to handle all of their database queries. But as traffic and their data storage grew to a large enough proportion, there were noticeable performance leaks.

The way in which LINQ-2-SQL interprets a LINQ query, generates a mapped SQL query, and then executes that query was too inefficient given the amount of traffic they were supporting and how they were using the ORM. Queries were simply taking too long to execute on a traditional ORM.

Instead of swapping it for another off-the-shelf ORM, a couple of their lead engineers, Sam Saffron and Marc Gravell, wrote their own lightweight version called Dapper.^[18] Dapper’s execution is much faster because it does away with much of the overhead LINQ-2-SQL carries with transforming queries into relational objects. It accepts only raw SQL as input, circumventing some of the bottlenecks inherent to converting one domain language like LINQ into another like SQL.

However, what you gain in performance, you lose in robustness. Unlike most traditional ORMs, Dapper doesn’t automatically map queries through to an object’s relationships.

In the Stack Overflow code, Dapper was originally integrated in spots where there are performance bottlenecks, where losing some of the elegance of programming against a traditional ORM is worth the gain in execution speed. Now, almost all of their new work is done using Dapper. By rolling their own, Saffron and Gravell uncovered where the bottlenecks were and solved their specific problem better.

Programmer Hubris

Building our own toolset to do the work we do is the ultimate toast to our labors. What else could feel more satisfying to a developer than working on code that makes the future code we have to write that much easier? Building our own stuff is motivating.

When we’re building our own toolsets, we learn a lot about what we value in our work. Oftentimes, these tools are the ones that define a career. Also, it’s not just because they might help out other developers. They also uncover what we’re hell-bent on improving. They cause the arguments we have a strong opinion about to bubble to the surface.

The tools we build are also ours. They’re wrought with our own opinions about how something should be done. No one can tell us how we will build the tools that help us do our work. So, when we’re writing our own little tools, we dictate what’s important. For some, it’s a nice escape from code we’re writing for other people. This is where our pride as developers can shine through.

And pride is where we’ll conclude our journey.