DOP 41: Input Questions And UIs Are Evil

Transcript

Darin Pope:0:00 This is episode number 41 of DevOps Paradox with Darin Pope and Viktor Farcic. I am Darin

Viktor Farcic:0:06 and I am Viktor.

Darin Pope:0:08 Today we're going to talk about the evils of UIs in all its forms.

Viktor Farcic:0:15 They're not always evil.

Darin Pope:0:18 Okay, when are they not evil? Let's start there first and get that out of the way.

Viktor Farcic:0:23 When they do something, or help you with something, that is done better with UIs, than without UIs. That was a politically correct answer, wasn't it, no?

Darin Pope:0:37 It was basically a non answer is what that was. So give a concrete example.

Viktor Farcic:0:41 So if you want to create issue ticket, yeah, UI is probably better for most people than CLI, right or any other way to do it. If you want to visualize something and then UIs are definitely great. We can all debate which things should be visualized, which things shouldn't, but when you want to put some graph, some statistics, some pie charts, what so not, then yes, they're great. I'm excluding from this story non technical people, of course. For my mother, UI is good for everything.

Darin Pope:1:24 So now we've said what UIs are good for, what are they not good for?

Viktor Farcic:1:29 They're not good for anything that should be done twice, in the same way, which is most of the things we do. So let's take code as example. Code should be written with UI, because it's, every time you write something different. I mean, if you don't write something different every time then you shouldn't be coding. So yes, using some UI, like Visual Studio Code, IntelliJ. It's great for coding. Now, when you want to compile that application that you've been coding, then you're doing the same thing over and over and over again. Going to File -> Settings -> Compiler, whatever, would be the option how to compile something from UI. That's a very bad idea. Very bad thing. It's hard to reproduce, hard to document, and very, very slow.

Darin Pope:2:26 Okay, but what's the...why is that bad? You listed a couple things, but why is that bad? I mean, I can teach somebody how to click on the right menu item.

Viktor Farcic:2:38 Yes. First, it's slow, right? So at least if you're gonna teach them how to do something like that, teach them how to execute how to run a shortcut and control x, y, zed, whatever would be the shortcut. So let's start there. I mean, any decent engineer is not really using mouse much to begin with, because it's very, very slow. You know, it's been a long time ago, but I remember once I was pairing with a guy who was going to File->Save every minute to save his work, because he was paranoid, and I was, how do you do that, why? What's wrong with Control-S. This is the stupidest possible example. But use shortcuts if you need to use UIs to do repetitive tasks and don't use UIs when you can do something from CLI. You're an engineer. If you don't understand the advantage, if you as engineer don't understand the advantage of writing scripts, which are code basically writing code to help you, then there is something wrong. And it's it's a paradox, isn't it? That we as engineers, we write code for others to use. But we are incapable of writing code for our own use or running that code. Isn't that kind of contradictory?

Darin Pope:4:07 Not to probably 98% of the developers in the world. It's like, well, this is the way I was taught to do it, or this is the way everybody around me does it. Why do I want to, you know, buck the trend?

Viktor Farcic:4:20 Yeah, but why do why would you, as a developer, think that anybody is going to use code you write, when you're incapable of writing code for yourself? You cannot eat your own dog food, right?

Darin Pope:4:36 Here's the here's where I think the mentality is. Its like, "I work in big company A. Somebody else takes care of all the other stuff. I'm just doing it for myself." And then why aren't you... So I'm going to go ahead and jump over on your bandwagon. If you're just doing it for yourself, why not come up with a different way to do it. Here's my workflow and this is my this is unfortunate. I typically use, if I'm writing real language, Go, Java, whatever, I'm going to use one of the JetBrains products, usually it's just IntelliJ because I have a paid license. I pay for it, it's not free, so there you go. But to this day, when I'm working with Git, I don't use Git in the Git integrations inside of IntelliJ. Although they're nice. I drop back down to a shell and do all my Git integrations. Because that's just how I how I'm working. Same thing, when I'm compiling code, I don't compile inside, I flip back out to my terminal and run whatever I have to run. I can't do it in the UI. Number one, most of the time can never figure out how to do it because it's so convoluted. There wasn't a Control-B for build. Right? That's that would make too much sense. But of course, it's never that simple. And I couldn't figure out how to do key mappings and stuff. It's like, I want an editor just enough to do what I need to do, but then I want to get to command line as quickly as I can.

Viktor Farcic:6:00 That's the healthy attitude. That's the normal attitude. You're using UI where the UI is better then using CLI where CLI is better. And Git was designed to be a CLI based tool. Now, I will admit I do use UIs for Git. I prefer UI, for example, to see the diffs of a pull request. I prefer UI to comment on a pull request. I know that I can do that through CLI, but I use UI for that. So I'm in no way saying that UI should not be used at all. I'm just saying that they're good for visualizing stuff and diffs between pull requests and baseline, that's visualization in a way. Pushing is not.

Darin Pope:6:45 Everything we've been talking about is sort of what we would consider "classical UIs". Some sort of forms, some sort of editor, or some sort of stuff. But asking questions from a CLI is also a UI.

Viktor Farcic:7:04 In a way.

Darin Pope:7:07 Okay. Continue why "in a way?"

Viktor Farcic:7:10 I mean it is UI in a way because it guides you to do some kind of wizard. You know, you execute command x and then it asks you "What is your name? What is your last name? What is your email?" or whatever the questions are. So maybe it's not actually...calling it UI would not be...it is a user interface. It has inputs and you provide the outputs or the other way around. I'm always confused. The problem with that is that it is very hard to document. And that means that if you're not documenting, you're not working as a team. You're not member of a team, you're not thinking of others. So let's say that we have a typical command and this now equally applies to UIs and why I think that they're bad. And that command asks you five questions, and then you want to document how others can do it. And you would just say, okay, "execute this command and then answer the first question like this, and the second to like that", and so on and so forth. Isn't that hard compared to "execute this script with the five arguments, copy and paste this," and that's about it?

Darin Pope:8:29 Absolutely. Because all it takes is a different language mapping, a different anything, in the keyboard will completely blow that up. Now, I don't think it's bad that if a CLI is programmed in such a way that it asks questions, although not optimal, as long as it is not the only way to feed data to it. Like if I don't pass in any parameters to ask me questions. If I pass in parameters, whether it's the five separate parameters, or I pass in a file and it knows how to slurp in the parameters from the file, that's okay, because I have options.

Viktor Farcic:9:14 Yes

Darin Pope:9:16 If the only reason why the CLI was written was because the developer did not know how to write front end stuff at all and he just wants to ask questions from the CLI. It goes back to your rule. If I have to do something twice, I need a different way to feed data to it. If I'm ever only going to do once, who cares?

Viktor Farcic:9:38 Exactly. Who cares, as long as those questions...answers to those questions end up being stored somewhere. So even if you're going to do it once, you most likely want to document it. Unless we're talking about...if you're talking about doing once, like I'm going to install this only once in production, then it definitely needs to be documented. It needs to end up being somewhere. Because I don't trust you writing wiki pages and especially not keeping them up to date. So asking questions and then answers to those questions being stored in some properties file, yaml file, whatever, is great. There is a huge advantage those things, both questions, UIs, consoles, and all those things is that they're a great learning experience. I will be honest. I learned most of what I know, let's say about AWS or Google Cloud through their UI. Right, because it's more intuitive and you know nothing about it. But then when I started creating clusters like there is no tomorrow, then of course, you fall into CLI and first time you might use inputs to provide the answers. But after that, it's just a single command with arguments. There's nothing wrong with arguments.

Darin Pope:11:03 So how do we convince someone that in today's world, you can't even...let me ask the question this way. Is there a way I guess there is a way to interact with Kubernetes without a command line? You're going to have OpenShift wrapping things. I think Rancher probably gives you the ability to interact and do the things that you would typically do from the command line. Am I correct? I believe I'm correct. I spend so much time on the CLI, I don't even remember anymore. We've already answered it, but let's answer it in the context of what we do day to day in Kubernetes. Why would I want to use a UI in Kubernetes?Visualization probably would be one.

Viktor Farcic:11:52 Yes. If you maybe want to look at some memory utilization of your pods, for example, UI is probably great for that. I mean, it's not probably, it is great for that because it gives, you know, kind of bar charts or pie charts or some kind of visualization. That's great. Metrics type of stuff.

Darin Pope:12:15 Even a describe would be okay, right?

Viktor Farcic:12:18 Yeah. Describe if you want to go through events and see which there is a problem with one of my pods. I don't know which one it is I want to start describing them and seeing events said that, that's okay. That's good. I'm not doing it myself. But I can understand that that can be just as good or even better than doing it through a CLI. Yes. Browsing. Let's put it this way maybe and I'm now thinking aloud. I did not really think in advance. Maybe UIs are good as a read-only mechanism for something.

Darin Pope:12:56 Reporting concept.

Viktor Farcic:12:58 Yeah, reporting.

Darin Pope:13:00 Yeah, because I know anytime I've worked with somebody that has OpenShift, most of them, they're already all thinking point and click all the time. But I have to admit when we were browsing around and looking at the pods and seeing the data laid out in a reasonable way to consume versus what I would see from a describe from the command line, it's easier to understand. Well, maybe not easier to understand, but it's easier to see the different things.

Viktor Farcic:13:30 It is definitely easier to see different things and it is definitely a good learning mechanism. But those people that you've been observing, real or imaginary, that using OpenShift UI, they're most likely not thinking about the company as a whole. They're most likely not...they're selfish people. Right? They're almost certainly not reviewing changes of each other's. They're almost certainly not sharing with each other what they're doing. They just do stuff. And that's the problem. That's, that's the problematic attitude is, "oh, my job is to do stuff. What is the stuff I did and how will somebody else know what is the stuff I did" does not really matter. "How will I cooperate with with the rest of organization" does not really matter and so on and so forth. People are focused on doing stuff and that's their only focus. There is no team play in many of the teams. Because if I'm wrong with what I'm saying, then how do other teammates of that person using OpenShift UI know what happened?

Darin Pope:14:55 I believe that you may have just hit on something that most people don't think about. My job is to do stuff. That person has, in my opinion, that person has been taught the wrong role. That isn't their role. Their role is to make money, save money for the company. It's not stuff. Because as soon as they go on vacation, or permanent vacation, leave, then how are the people that are left behind going to figure out what this other person did?

Viktor Farcic:15:37 Exactly. It's all about documentation. How do you document everything you do? And we probably spoke about it how you writing essays in wiki is not real documentation, at least not technical documentation. It is not up to date, it becomes obsolete very fast, and so on and so forth. That's why we define things as code, because it is accurate documentation of something. That can be your application, documentation of your application is the code of your application or tests of your application. Same holds true for infrastructure or anything else. And that's how we share that knowledge. It is a language that we as engineers invented so that we can communicate with each other. It's a language like any other. And we even stopped writing in byte code and assembly. Not only because it's hard, but also because it is very difficult for other people to understand what we want to express.

Darin Pope:16:46 I think, going back to the wiki example, as a developer, as an engineer, as an infrastructure person, would you rather write documentation or would you rather write either real code or pseudocode...pseudocode meaning declarative definitions of things.

Viktor Farcic:17:12 Declarative definitions of things, or code. What I want to see in a wiki is when there is a page "how to set up a cluster", I'm inventing use case, I want that wiki page to say, run this script. And if you're not sure what that script does, or how to customize it, open it and you will see it in comments or in the code that is nicely written and what so not what it does. Ideal documentation for me is just a group of pointers, where to find that something that will do something. Think of documentation as a group of links.

Darin Pope:17:56 And to me, I'm gonna take it one step further, even though you just inferred it. In that wiki page, I don't want to say anything more than here's the, here's the phrase of how to set up cluster X on Google. And it's a single link off to a Git repo that has a README and the README has everything there. So the wiki is super lightweight, it's just a different way to get to the wiki. I'm sorry, the wiki is super lightweight, and it's just the only way to get to the repo. That's it.

Viktor Farcic:18:31 Exactly. And even that README should not...what I see very often is those READMEs or wikis saying, Okay, so this argument does, if you specify if you want this, then you should specify that argument. Which is silly because that's what help of that command or script or whatever it is, is supposed to give you. So there is no real reason why would you specify the meaning of stuff if the meaning of stuff is defined in stuff on the README, yes.

Darin Pope:19:05 Yeah. Now, that doesn't mean you couldn't have another real documentation book, if you will, in that repo that dumps out everything. That way, in case you haven't installed the CLI yet, it's like, okay, are the options here? Instead of doing the command for AWS, because I may not know the extra switches to get to the point to actually ask the right question. But I can browse it on the AWS documentation, and it's like, oh, yeah, I need to do the s3 one. Right. And it's sync. And there's a couple of extra switches. I think the way that AWS does their docs is helpful. And then once I've done it a couple times, like oh, yeah, now I remember how to ask the question to the CLI.

Viktor Farcic:19:47 Exactly, but that documentation that you were looking is 100% or maybe 90% is a dump from AWS CLI.

Darin Pope:19:57 Yes.

Viktor Farcic:19:58 It's not written by somebody who has no better way to waste his or her time than to write things that already exist. So there is a single source of truth for everything and that includes documentation. And then that truth can be transformed into other forms that are may be more useful for certain audience. That's great. I mean, Google search is much better than whatever I can do through CLI. So I do search in Google and that does lead me to some documentation. But that documentation, when it's good, it's a dump.

Darin Pope:20:38 Well, that's the way the Jenkins X documentation site is generated, right?

Viktor Farcic:20:44 Yes

Darin Pope:20:44 Generated off of source code.

Viktor Farcic:20:47 The documentation is not generated from the source code, but that's more documentation about Okay, so this is the architecture of Jenkins X to say something. Right? A few diagrams, some text, right? Or this is the philosophy behind XYZ. So the reason I'm not saying that there is no need for writing some separate pages in documentation, stuff like that. But that's on a much higher level, not the explanation of what certain command does.

Darin Pope:21:22 So in this trip around the UIs today, we've talked about the good, the bad, and implicitly the ugly. I don't know anyone that enjoys seeing kubectl describe output. Unfortunately, I'm getting quicker and quicker at reading it just because I've been doing it more. But man, it's taken a while to sort of understand. You start to see patterns, at least when you're doing that. That's another conversation. I won't go there.

Viktor Farcic:22:02 Now we're entering into conversation and this is now this is the part that is definitely not for everybody but some people become ninjas with doing greps and awk and stuff like that. And they can do stuff that I cannot believe through CLI, but that's already for a small percentage of people.

Darin Pope:22:25 Do you Perl? If you Perl, you can do it.

Darin Pope:22:29 This was a pretty good conversation. I wasn't sure where it was going to go and it was pretty good. I liked it. So if you're listening to this on Apple Podcast, please subscribe and leave a rating and review. All of our contact information, including Twitter and LinkedIn, can be found at https://www.devopsparadox.com/contact. And if you'd like to be notified by email when a new episode is released, you can sign up at https://www.devopsparadox.com/ The signup form is at the top of practically every page. The links to the Slack workspace, the Voxer account to leave us a voice message, and how to leave in a review or all down in the description of this episode. Why am I sing-songing this phrase? I don't know. I haven't had enough caffeine yet. If you haven't bought the Canary... what do we call those things...courses, courses, and you're interested in Canary, go do it. The best coupon that we have for Udemy will be down below in the description as well. If you're more interested, and we've already sort of revealed it in a previous episode, if you're interested in chaos engineering, there is a course coming for that. I don't think today is...what is today? Today is....don't say the real date. Today is February 5th. Are we finished with the course yet? It's February 5th.

Viktor Farcic:24:09 No, February 5th, no, but I hope it will be close. At the time of recording, I'm still on vacation and that means that I can work like there is no tomorrow. So it will be done soon.

Darin Pope:24:27 So where are you right now though? If it's February 5th, where are you right now?

Viktor Farcic:24:31 February 5th, I am in Madrid. That's the week after FOSDEM.

Darin Pope:24:40 Week after FOSDEM. Okay. So hopefully you saw Viktor at FOSDEM. Sort of weird to talk about it in the past when it in the future. Okay, full transparency, I don't even know what today is. I've lost track. Today is January 21st when we're recording this. Obviously we have to do things between both of our travel schedules of when we get get things done. But be on the lookout for that chaos course. We're just not sure...it's coming along well, but it's a different animal than Canary. Is that a fair assessment? It's, it's very different.

Viktor Farcic:25:20 It is, and it is, for a very, very small percentage of people. A huge percentage of people will want it, but a tiny one can use it. It's like a riddle.

Darin Pope:25:37 It is. And what's interesting about it is, in my opinion, everybody talks about integration tests and load tests and all this other stuff. There should be chaos tests. And I think a lot of people think of chaos from the Netflix concepts of Chaos Monkey, Chaos Gorilla, Chaos Kong. And although that's true, it's not necessarily the easiest thing to pull off. I think you'll like the way that this chaos course is and it could be put in as a step in your process. Because it will tell you things that are a little more manageable and a little more how we shall we say, driven from the command line? Right, just like what we talked about today.

Viktor Farcic:26:28 Exactly.

Darin Pope:26:29 I saw lots of stuff that is going to be interesting. So be on the lookout for that chaos course. Not exactly sure when it's going to go because, again, of travel schedules. That pesky day job. Right? It gets in the way. But it also provides the way for us to do this. Have a great week, Viktor. I'll talk to you whenever we talk again. Thanks again for listening to episode number 41 of DevOps Paradox.

DOP 41: Input Questions and UIs Are Evil

Show Notes

Hosts

Darin Pope

Viktor Farcic

Links

Rate, Review, & Subscribe on Apple Podcasts

Signup to receive an email when new content is released

Transcript