Every Sinatra application dies a hero or lives long enough to become a bizarro Rails app.

How does your organization build software: From the outside in, or from the inside out?

It’s a question that I’ve been thinking more and more about recently. At imgix, we’re in the process of swapping out the underlying technology on some older applications. Our team has outgrown certain libraries and is swapping in frameworks. The monolithic Tornado app powering our marketing and docs site recently got the axe in favor of a simpler Rails stack.

The new imgix docs site is the first piece of the new Rails work, and it comes with some really neat functionality. The velocity at which the team is able to contribute to it is remarkable.

At previous jobs, we would always start out small projects with something like Sinatra. At imgix, the choice had been Tornado. These small libraries allow you to get something stood up quickly and serving out traffic. The logic of the application can be contained in a single file so you put it in a single file.

But as teams grow and shuffle, things get bolted on. Hand me that CORS support! No CORS support? We’ll write it ourselves! Without the guidance of a framework, we start put stuff in any old directory. Development energy is unguided, shooting off in whatever direction seems most expedient. The organizational whims of yesterday are different from the well-formed organization structure of today. I disagree with my organizational choices sometimes just weeks later. My past self has always been out to get me. Soon, you have a few projects using the same underlying technology but all looking totally different. You walk home wondering, How did we get here? No one wanted this to happen.

If you’re lucky, it hasn’t mattered. The outside world could care less what library you use to deliver a handful of HTTP responses. The outside world doesn’t care that your entire team spent a week deciding on just the right framework. If you’re lucky, you’ve got a functioning business with some less-than-ideal code.

Maybe it’s age or maybe it’s knowing better, but I don’t use things like Sinatra any more. When working on a team, the library-based inside-out approach is a fast-track to a town only full of bikesheds. The outside-in, boring framework approach at least lets you know that the bikesheds in your town will be predictably located.

This line of thinking is very strange to me: technically Sinatra and things like it are simpler by design. They do less. They don’t come with as much baggage. Why then, do Sinatra projects seem to end up being the opposite of simple? As a result, I now just start with the bread-and-butter framework for the language, even if it is a bit heavier at the outset. How this train of thought has not wound up with “use Java for everything” I’m not sure. There is, like everything in software, a balance.

How does your organization build software: From the outside in, or from the inside out?