Slow Down and Think

Sorting through junk in my files a while ago, I came across a true blast from the past: A punched card. I was fortunate enough to start my career in software just after these were commonplace, I only had the chance to use them a few times, and even then they were more a curiosity of the past than a serious tool.

Seeing an old card did make me consider how software development has changed over the years, though. The amount of computing power we have at our disposal, of course, is one most obvious change, but there have been a great many others. Our languages, tools, virtually everything we use is vastly more capable than what we were stuck with in bygone years.

Doing Better

Not all “modern” software development is superior, though. While there is of course a vastly larger amount of software around now than there was even a few years ago, it doesn’t really seem like the overall quality of software is going up noticeable. There’s a lot of pretty bad crap out there, even though it’s new.

Surely we should be producing vastly better products with our vastly better tools, right?

Sometimes we do, but not all the time, and I would hazard a guess that it’s not even most of the time.

Impedance

Back in the old days, you had to reason out your programs more fully before you started, it was painful to change your mind, you had to punch all those cards again, after all. Even after dinosaur card-readers no longer roamed the earth, a substantial program still took a long time to compile, and link, and all that stuff before you went from code to working application.

Now with more more immediate feedback, we tend to bang out programs faster than we can think about them sometimes, I believe.

Don’t get me wrong: I think a fast feedback loop is a virtual necessity for good software development, and it’s not just speed that has made the “think” step take a back seat. Web applications in particular are good candidates for continuous delivery, where we actually deploy whole new versions of an application every day at least, not just once or twice per year.

Faster isn’t (By Itself) Better

This fast cycle time is extremely valuable: It allows smaller and therefore safer changes, faster feedback from customers, quicker time-to-market, and much more.

It doesn’t cure all ills, though, not by a long shot.

We build software nobody wants, and we do it more than we used to, because it’s faster to do it (and therefore less expensive).

We build software without a proper design or architecture, because it’s fast enough to build, try, then throw away when it doesn’t work. Just because we alienate all our users is no reason not to crank out tons of throwaway crap, right?

We build apps that are more shallow in many ways than they used to be.

Some of it I do blame on tools, or at least on the over-reliance on tools that some developers have. I suspect it’s true that many developers nowadays couldn’t build a webapp without a framework if their lives depended on it. Many couldn’t talk to a database or build a simple command-line UI, and this is a bit frightening, to be honest.

Even among the developers who could do all these things and more, they spend a lot of their development career on autopilot, building things that have no lasting value, even when they are making every effort not to do so. They are pressured by their companies to build more, when they should be being pressured to build better, not just faster.

After all, the market leaders generally don’t just build more things than the competition in the same amount of time, they do something qualitatively better than their competition.

Way back in 1911, Thomas J. Watson, who went on to found the company that would eventually be known as IBM, said “The trouble with everyone of us is that we don’t think enough. We don’t get paid for working with our feet — we get paid for working with our heads.”

Then he wrote down the single-word slogan: “Think”, which went on to become quite famous within IBM, and even outside to a degree. The word appeared on signs throughout the company, and represented a reminder to carefully consider before acting, even as the ability to act faster became available.

Just because you can doesn’t mean you should. Slow down and think!

Principles and Practices

Tired of the Software Development Grind? Know it can be done better? Check out my book: Principles and Practices of Software Craftsmanship or sign up for my Craftsmanship Dispatches newsletter.

Published: September 03 2013