We're Not Launching (and Landing) Rockets

This is an "off color" post, which will be more unconventional than previous posts.

I've been approached with technical problems in the past that have had straightforward, two minute resolutions as well as several months of discussion, whiteboarding, and head-scratching until the light bulb finally lit up.

No matter if the problem results in a simple tweak to an existing system that merely results in a quick deployment or the creation of a new distributed system, I always respond the same way:

This isn't hard. It's not like we're launching rockets, just solving problems.

I usually get a chuckle or a sideways puzzled look (ok, 98% of the time it's the latter), but it's something I wholeheartedly believe.

If you haven't already, take a moment to read about Space X's most recent launch, sending cargo and experiments to the international space station launched via a reusable rocket. That's pretty cool, in my humble opinion. Not only that, but that must've been a unique and difficult problem to solve.

What about building systems?

The systems we're often asked to build or enhance on a day-to-day basis aren't terribly complex if you break them down into smaller problems to solve piece by piece. Depending on your system, you may have a number of different variables to keep in mind:

• Internal dependencies in the code
• External dependencies on third party software or services
• Maturity of the code base and its interaction with your build/deploy process
• Reliability of network performance in relation to user and/or system needs
• Contingency plans for a single or (gasp) multiple hardware failure
• Sketchy internet ruffians hoping to intercept some of your network traffic
• Oops, someone unplugged the server while vacuuming (true story!)

The list goes on. And you know what? That's probably only 1% of what you need to worry about when building a system.

Well, if that's the case, that seems pretty hard.

I still don't think so.

Why? Learning a programming language isn't hard.

I'm a strong advocate of everyone learning at least something about writing software. Doesn't matter the language, platform, etc. Jumping in and learning your first language may seem daunting, but there are resources out there to help you learn.

Then you'll find that there's no magic sorcerer hat that engineer's have to wear in order to do the work that they do. It just takes time.

Time and failing. A lot of failing. And more importantly, learning from failing so that you fail a little less each time.

Mastering a language, on the other hand, isn't easy. Sorry.

Think of it like learning the piano. It'll take you ten minutes to play Mary had a little lamb, but just a bit longer to play Scarbo at a proficient level.

And then you have the patterns, tooling, infrastructure, and people. People who love solving problems who might've been down a similar road as you, that can offer advice on which patterns might be effective and to discuss the pros and cons of particular choices in infrastructure.

There are lots of ways to solve a problem.

And if the project doesn't build because you left out a semi-colon in your haste to get to the common area before all the good food is gone? You fix it and try again at the cost of a few pennies. A few pennies?

Assume you make $500 dollars an hour. That's $8.33 a minute, which is roughly 0.13 a second.

We're talking apples and oranges here, but stay with me on this one. If Space X's rocket fails to launch, it could cost them roughly $260 million dollars. Not to mention, potential collateral damage.

A poorly designed system that runs for years executing to wrong business rules could cost a company hundreds of thousands to millions of dollars: time spent in meetings, fixing software "glitches", and case loads of Excedrin.

Poorly designed systems can be fixed. It isn't a black hole that you have to live with. It's just a problem to be solved.

Healthcare.gov got fixed (no politics here, just talking about technical and business problems) and, in the process, a new department and some streamlined processes were born.

If you have good communication, trust, and a process that allows people to thrive without having to think about the mundane (should I check this box or that box), but to focus on the tasks at hand, you'll be amazed at how easy things become.