Ambiguity/one way/Dutch
Anyone who has ever worked with clients knows how demoralizing and frustrating a vague requirement is. “Do this, do that, we need this” – that’s all you hear, without any understanding from the other side or respect for how the process works. They have a certain goal in mind, and they don’t care how you get there. That’s fine for machines (and we’ll learn how to do some of that), but for work done by people (and especially for coding work), that is not the way. You need to know exactly what is required so that you can do it precisely.
A lot of the time, even the clients don’t know what they want; they have a vague idea that they want to act upon, but nothing beyond that. This ambiguity needs to be sorted out at the beginning of the project and it certainly should never spread to the code. Once something has been defined, then there is a way to do it that is the fastest, most secure, or most convenient (depending on requirements). This is the way that you need to find.
But, again, how do you find this way? It is not obvious to anyone who is not Dutch (a reference to the Dutch programmer Guido Van Rossum, the original author of Python). So, if you’re Dutch, you’re fine. If you’re not, read this story (it’s a much better fit for these principles than regular code):
Three friends were stranded on a boat with no food or water. These friends only had in their possession a lamp that seemed to be empty. One of the friends decided to rub the lamp, which caused a genie to appear. The genie granted each of the friends one wish since they had all summoned him together.
The first friend made his wish: “I wish to be sent to my wife and children.” The wish was granted, and the friend disappeared, having been sent back to his family. The second friend wished to be sent back to his house in his hometown. This wish was similarly granted. The third friend, a loner, had nowhere he could think to go nor no one he could think to go to, so when his turn came, he said: “I wish I had my friends with me.”
Now, this is an old story, but the way most people interpret it is that the friends were forcibly put back onto the boat by the third friend’s wish: a classic tale of be careful what you wish for. However, an engineer can read the story and come up with some other possible scenarios. Maybe the third wish brought back more than those two people (if he had more than two friends); maybe it brought back no one (if the other two weren’t considered friends, that would be a sad turn to the story), or it could even lead to an argument over what a friend is.
But most programming languages are like the genie. It does exactly what you tell it to do. If you’re vague, the room you give it for interpretation can cost you, so be careful and only wish for the exact thing you want. And people (such as our previous clients) are like, well, the people. They sometimes know what they want, they sometimes do not. But, to succeed, they need to know precisely what they want in both the context of the goal (getting home) and the context of the rules that govern them (they could’ve let the third friend go first if they doubted his intentions). This is quite a conundrum, isn’t it?
The key here – and this is something DevOps and Agile methodologies preach as well – is continuous improvement. Trying to continually find that one way. And if the scenario changes, tweaking the way to that scenario. This strategy is essential in coding, DevOps, machine learning, and practically every technology field. Iterative methodology helps turn even the vaguest goal into a bold mission statement and can provide unified direction.
The Dutch are a very direct people; only they could have invented a language as head-first as Python. Speaking of direct, you should probably read the next section now … or never, if you don’t have the time right now (see what I did there?).