#begin

Andrew and David start this chapter with the following sentence: “Every craftsman starts his or her journey with a basic set of good-quality tools.” I couldn’t agree more. They give the example of a wood worker and his tools. He has saw, chisels, drills and braces, mallets and much more. Those will be his or her fundamental tools. As he or she gains more skill, more complex tools will be added to her arsenal like; chain saws, table saws and other power tooling. If the craftsman would have started with the power tools, he or she would never have mastered the basic ones. This makes perfect sense, right?

Is this any different in software development? No, of course it’s not. Using the basic tools begins a process of learning and adaption. Each one has their own personality and needs special care, handling and sharpening. And, over time these tools become like an extension of the craftsman’s own hand. They become part of their brain, way of thinking and even probably remain the preferred set of tools over the high-tech power tooling they can get now.

The authors say something really cool next, and I’ll just quote them: “Tools amplify your talent. The better your tools, and the better you know how to use them, the more productive you can be.” This is amazing and I couldn’t agree more. Mastering the basics really is very useful and boosts productivity. And I can give you a nice example too.

Like every software professional I use Source Code Control. I’m an adept user of Git and I know it pretty well, I think, at least. I’ll have to search for things sometimes but I’ll be able to fix most issues in git. Even to a point people come to me with all kinds of Git problems they got themselves into. Why!? Well because I only use Git from the command-line. I’m using all the low level commands and thus I’m pretty well educated on what they do exactly. Don’t get me wrong, every time I read through some docs about Git I learn something new so I’m far from the guru people think I am. But the fact remains that because I use the console, I have a better understanding of all the individual commands do. Last year I studied this git blog called “Git from the bottom up” which dives deeply into how git works. It’s a fascinating read and I strongly encourage you to read it if you want to know more about Git. You can read it here.

Let’s get back to the book now: As you gain experience in your vocation and with your tools, you will add new, more complex tooling, like power tools to your toolbox. And you will probably be adding them regularly, always be on the lookout for a better way of doing things. Especially when you get yourself into a situation where your current tools can’t cut it.

There’s still a lot of software developers who will learn a single language using a single IDE like Java with Intellij and shape their career around that. Nothing wrong with this, its just not the pragmatic approach!

Alright, now that we have the introduction out of our way we can get into the fist paragraph of this chapter: The Power of Plain Text!

The Power of Plain Text

What about plain text!? Well, of course we know as pragmatic programmers that our base material is not wood, or metal; it’s knowledge! And as an industry we have decided that the best way to document and persist that knowledge is plain text. We write code as text, unless you are some obscure binary wizard of course, but I highly doubt that. We don’t just have plain text of course, we also have design schematics etc. however they can be expressed as text as well like with PlantUML or good old LaTeX. By the way; if you want to check out a very interesting presentation about plain text I highly recommend a talk by Dylan Beattie. You can check it out here.

But let’s take a step back; what exactly is Plain text!? Well, I would define it as human readable text in a non structured way. There’s also structured plain text, like json or xml or even html. And, why do we use plain text? Well because we need to edit or read it. We could have written it in binary but that wouldn’t be very useful. So we raise the abstraction level and make it human readable.

Drawbacks

Are there any drawbacks to plain text? Well, yes! It often takes up more disk space. But do we even care about disk space anymore at this point? But the second part is, plain text is more computationally heavy. So your software must spend more resources and time to interpret plain text. This is the reason why Google implemented this protocol called protobuf for example. Protocol buffers is an alternative communication pattern to JSON which uses binary, let’s call it serialization, to communicate between processes. And yes, these processes can be distributed.

In the book they talk about how some developers might think that writing out a lot of data as plain text as means of telemetry is bad idea because it exposes too much of the application’s internals. Haha, how this has changed right!? I mean, now, in the golden days of cloud computing it’s all about telemetry and traceability. This is such a point where the book dates itself 😀 remember, it was released in 1999. Even back then, the authors said the following: “Some developers may worry that by putting metadata in plain text, they’re exposing it to the systems users. This fear is misplaced.” They’re real visionaries aren’t they? 😛 Pretty impressive!

The Power of Text

So we have these two drawbacks; larger files and computational intensive. What are the benefits then!? Well Andrew and Dave mention three of them: Insurance against obsolescence, leverage and easier testing. The next part of the paragraph is dedicated to these three benefits. Let’s take a look.

Insurance Against Obsolescence

The authors start this section of with the following sentence: “Human-readable forms of data, and self-describing data, will outlive all other forms of data and the applications that created they. Period”. And I couldn’t agree more. Imagine if all your Unity3D .meta files were binary. How would you do any custom processing!? As a matter of fact, in the past, they were binary! Although it was a choice, if you had a pro-license. But I remember the days when I started a new project, forgot to swap the binary format to yaml and my merge requests all went to shit. Oh boy, those days were annoying. I guess that’s where my fears for using the Unity3D inspector come from.

To get back to the book; I indeed agree that plain text data mostly outlives binary data because it can be more easily reused or even re-purposed. An example they give the the book is also a pretty nice one. It’s about legacy software that returns plain text instead of binary, or vice versa. If you have to deal with legacy software, it’s very convenient to have access to plain text over binary because you can adapt more easily, or even reverse engineer the legacy system from its in and output. If you don’t have access to the source code for example.

They also rightfully note that there is a difference between human readable and human understandable. Human readable data is mere plain text data, yet if you cannot make sense of it, it’s still worthless. Imagine you have a JSON file that contains data like; Field1 = 10, Field2 = some GUID, Field3 = true. What information do you have now? Not very much right. So naming these fields to actually mean something is really required to make them useful.

Leverage

Now David and Thomas mention something I just did a few seconds ago. Using plain text offers you leverage. By this they mean that virtually every tool in the computing universe can operate on plain text. Think about it… They are totally right. Even more cooler is the fact that our source code control systems are specifically designed to work with plain text file. You can use these tools to track changes in literally every plain text file you can imagine, like source code, configs and even documentation.

Easier Testing

When everything is plain text you are also able to exploit this with your testing practice. If all you systems receive plain text as input and output plain text then you can write intermediate tools or middleware to analyze that data and do something useful with it.

Lowest Common Denominator

According to David and Thomas, back in 1999; plain text will be the lowest common denominator as means of communication over the internet. They specifically mention XML but I estimate we communicate more in JSON than XML nowadays. Even so, (G)RPC calls do use a binary format by means of protobuffers.

My personal opinion about everything about plain text is that, yeah, I think they are right and I agree with them. A lot of what we do is plain text; source code, yaml, JSON, XML and even our high tech infrastructures are written in specific DSL’s like ARM, BICEP, TerraForm, and others. Plain text has really dominated our industry and will remain so because it’s just far too powerful to be replaced with anything else. Maybe on the security or performance end of this discussion might we want to change plain text to something else. But a binary format, does not mean it’s secured. Simple example; I can turn a string into base64 encoded bytes, and then change it into a string again. All data will remain the same. Remember that as security 101 lesson haha.

So that’s it for today. Let’s continue another time with the next section of this chapter called Shell Games. Cya!

#end

01010010 01110101 01100010 01100101 01101110