Choose one: High productivity or code you can maintain

No matter how you slice it, there's always a trade-off between speedy development and ultrareliable applications

Email a friend

To

From

Thank you

Your message has been sent.

Sorry

There was an error emailing this page.

Thinkstock

Current Job Listings

I’ve been doing a little development lately in addition to my regular job tasks. Nearly all of this has been leading-edge stuff. One thing that's struck me: Good gosh, testing a one-line code fix requires several minutes.

Development goes in phases between maintainable and productive, usually hitting one of those extremes in the process.

Many of us have engaged in rapid application development (RAD), where making a change and getting it to production all happens from an IDE (or not) and takes seconds. On the other hand, we've all seen catastrophic production outages, when some developer pushes an item to production that shouldn’t be there.

In other situations we've done highly maintainable development where nothing is a one-line code change and deploying what would be a one-line code change to production is an act of sheer will with a lot of moving pieces. The software world loves to do this and manufactures complexity very well, thank you very much.

Take a historical example of RAD. In the Java world, JBuilder used to be able to incrementally deploy to Weblogic. In the PHP world you could edit a file on the web server or locally, then scp it into the right directory. Either way you could easily test that file locally. In the Microsoft world, back in the VB days, you could easily make a change, then hit Run and test it again. Microsoft still leads at this in the cloud era with autoswap, but let’s face it, it ain’t like it used to be (and Azure is no one’s favorite cloud provider).

Take the biggest historical example of arguably maintainable software development. Java EE abstracted you from the hardware and, in exchange, required you to create about 20 embedded Zip files (OK, a minor exaggeration) and 15 different XML descriptors (not really an exaggeration in a substantial app) to test a one-line code change in your Model 2 controller. On one hand: Look ma, no more someone-did-something-by-mistake in production! And no more buffer under/overruns. On the other hand: Good gosh, it was a productivity suck.

Fast-forward to today, and even the language productivity for a full stack application is an interesting productivity suck. Adding a minor detail in a Java servlet or C# app is nothing compared to a fully functional programming monster. No more will you pull a header out of an injected environment thing, oh no, we have to figure out how to do this in a completely stateless manner that stays “functional” throughout.

Yet when Docker is an essential part of your build process, you have a lighter-weight version of the Java EE packaging dilemma. To make a change, I have to build the change, bring down the container, rebuild the container, and bring up the container. There is no incremental anything, really.

Where JavaEE wrought Spring and JRebel, so will our modern environment. The pendulum will swing back to productivity, and developers may realize their “beautiful” functional code is a piece of trash if they can’t, say, add one HTTP header into a downstream service. Someone will make an integrated environment that fully connects to Docker containers and injects changes. Eventually someone will create a whole RAD thing that can’t be fully rationalized into tools like Jenkins and deploys directly in production, and we’ll start the horror show all over again.

For now, enjoy waiting minutes to test a very minor change even locally while production stays stable. We live in interesting—but maintainable—times.