Razors and Development

A few years ago I switched to an old fashion safety razor and haven’t looked
back. The latest entry into the razor market has reaffirmed my decision as the
right one.

The new Pro Glide from Gillette only costs less than $10 to purchase. Good
deal, right? Nope. The replacement blades cost $3-$4 each! Assuming you get
a few weeks out of each blade, you’re looking at paying between $6 and $10
every month to use this razor blade.

It’s a great deal—for Gillette.

I use Merkur razor. I paid a lot, comparatively speaking, up front but I
can buy better quality razors for less than $0.75 each. They last a lot longer
and I end up with a much better shave.

I view the trade-off here as the same one you have to look at when deciding
what framework you choose to develop your code in. There are a lot of
frameworks that provide a lot of help getting off of the ground. It almost
seems too easy.

Write your on custom blog in 5 minutes? Sure! Want to have a RESTful API?
Add a couple of classes, some new routes, mark as complete.

Look at the framework and read some of the comments from its detractors. Those
complaining generally have one of two problems:

They’re going to complain about anything, they’re just ranting. Ignore
these people.

They’ve hit a legitimate pain point in the framework where they deviated too
far from the intended use. Pay attention to what these people are talking
about.

If you’re application is significantly complex, no off-the-shelf framework is
going to do everything you need it to. Some frameworks may even get in the
way. Make sure you realize the trade-offs before you commit.

What makes a good framework?

… a temporary structure used to support people and material in the
construction or repair of buildings and other large structures.

Put another way for software development:

… helps you ramp up quickly, then gets out of the way.

Historically, frameworks manage the first part of this well. That’s where
they shine. It’s the last part that they’ve had a problem with.

Django manages both of these well. My one complaint with it is that it
manages the latter part better than the first. There’s a lot of boilerplate
needed to get started, but I can live with that. When my applications outgrow
Django, removing Django from the equation is easy with one exception.

Models.

Models are like your razor’s blades. Without blades, your razor doesn’t shave;
without models your application doesn’t have any data to work with. The fix
I’ve found works best for me is to keep my models then and put all of my logic
for operating on them in other areas of the code base.

This separation helps me keep my business logic portable. I might be using the
cheap route to get started, but the heavy lifting goes with me if I decide
something else is a better fit.