localhost exposed

Next »

Elegance and Pragmatism

Preface

After spending several years as both in dev and ops I’ve begun to notice some trends that I can only describe as groups of people behaving virtuously – it’s just that the virtue in question depends on the group.

It might sound like a weird thought, but that’s exactly because it is. I am writing this based on purely intuition and gut feeling on the subject. I am no guru, no soothsayer, no diviner of truths.

I am just a hacker. A guy who writes for his future self. So I can gain some sort of feeling of growth through retrospection.

Virtues

Elegance

“Simplicity is the ultimate sophistication.”
― Leonardo da Vinci

The core principle and virtue by which dev lives and breathes is elegance. Be it elegance in design, naming conventions or a fun past-time such as code golf.

Elegance is the goal of making really complicated and complex matters disappear under the veil of simplicity. Elegance is the recursively self reorganizing piece of genetic code that is written in 3 lines of esoteric Perl but is perfectly legible in English.

Beautiful code is one goal of elegance. It is its own reward. An ends in it of itself. Write purely functional code without any side-effects and reap the mental gratification such that only Zen Monks from Nepal know of.

Elegance is making the thing that works the simplest thing it can be.

Pragmatism

On the flipside of DevOps is Ops. Operations. The guys who make sure everything works smoothly and continue to do so for the foreseeable future. Reactionary or proactive - it doesn’t matter. These guys are always active in either case.

The core tenet of the Book Of Ops is pragmatism - that is being as practical as possible.

Practical in the sense of field medics vs. neurosurgeons. Patching your mate with whatever is available that suits and then fixing the root cause with better time.

Pragmatism is doing the simplest thing that works.

It is knowing that things could always be improved, it’s not getting tangled in analysis paralysis which is quite common in dev or software architecture design.

Pragmatic Ops forces hack'n'slash with Occam’s razor while Dev is combing over the fine print of Law of Demeter or which whitespace you used.

Having been on both sides of the fence I can relate to both.

As said, the mental satisfaction you get from having all indentation across your 1000’s LOCs consistent and automatic or 100% test coverage of business logic is immeasurable and borderline euphoric. That same feeling can easily be seen as petty and nonsensical when viewed from without. But without that passion for detail and precision and concision the whole thing would probably spiral out of hands and end up as another statistic of a software project gone astray.

Just ship it

At the same time the prevalent trend in software development is “Just Ship It” whose main focus is to fight perfectionism inherent in most devs. It also hammers in the point that going live is a more pragmatic way of finding bugs than artificial tests in lab conditions.

You can always make software good, but not fool-proof and there’s big reserves of fools out there in the world ready to break your app.

From a dev viewpoint ops’ usual lack of care for the finer parts of the craft of programming seems barbaric. It seems that ops is satisfied with using duct tape as a band-aid instead of using the correct tool - actual band-aids - for the job.

And that’s pretty much the case from the ops’ point of view with the slight addition of context: we’re all out of band-aids and this guy’s gonna bleed out before sunset unless we use duct tape.

Chainsaws, scalpels and bloody rags

I think I might be over-extending my analogy, but I would continue to say that ops is ER and dev is surgery.

The job of ops is to perform constant triage of incidents from a insignificant as a log telling us that the ntp daemon had to adjust the clock for the third time in 5 minutes to having a user tell us that they cannot access a service to having a datacenter disappear from the network. Ops needs to prioritize case-by-case and escalate issues to either getting patched up quickly with duct tape or sent away for further investigation.

Devs are more akin to surgeons with their extremely delicate adjustments. Devs use scalpels to make a precise cut here, to insert this pace-maker there and then tiny stitches to fix the problem. Whereas the ops tool of choice would be to use an axe to crack the ribcage open and connecting a 12-volt car batter to get a jolt going.

DevOps

What might seem like obvious and/or absurd issues via my analogy, there are real-world counterparts to these tool choices and actions taken. That is why the whole concept of DevOps is now on the rise. It is a term that aims for an equilibrium between the two factions.

DevOps is about compromise and complementing each other. Compromise in that neither side can be driven purely by their whims and wants that aims only for their own virtue.

DevOps is like playing DnD: Your lawful good paladin cannot expect nor demand that your chaotic good rogue plays by the same rulebook, pray to the same deity or even respects the same aspects as virtues. But if your paladin wants to survive it needs to loosen the grip on what is kosher and what can be forgiven due to pressures of the situation.

Next »