In this week's episode we strive to define some confusing and controversial terms:

• DevOps
• Agile
• MVP
• API
• Done
• Hacker/Hacking
• Engineer vs Developer
• Tiny

Resources
Video: 10+ Deploys Per Day 2:08
The Manifesto for Agile Software Development
Book: The Lean Startup by Eric Reis
Humans are Turing Complete
Tiny DevOps Episode 19: Mastering Evolutionary Design with J.B. Rainsberger 44:15

Co-host
Amando Abreu
LinkedIn

---

Transcript

Voice over: Ladies and gentlemen, the Tiny DevOps guy.

[music]

Host: Hello, everybody. Welcome to another episode, another exciting episode of Tiny DevOps. The new year is here, and we decided to do an episode. I invited back my friend Amando to talk about definitions. We're going to try to start 2022 off with some clear definitions on some confusing topics. Welcome back, Amando. Thanks for joining me. I'm excited to do this episode because our industry is so full of crazy and confusing buzzwords. We're going to try to get to the bottom of some of these. We haven't actually discussed our own definitions before, so it's possible that we will find that there's more confusion than we realize and we don't even agree on something here. Let's see what happens.

Amando: Yes, that's the idea, to see what happens here. Great to be here again. Let's see how it goes.

Host: Great. I reached out to my LinkedIn network a few weeks ago, and I told them we were preparing to do this episode and I asked for some suggestions. I said, "What terms in software development and in IT do you think are most often misunderstood?" We got some great suggestions. We're going to start through that list here. The first one, since this is a DevOps show I think we should just tackle that one right away, the term DevOps. Do you want to start this one off, since you're my guest? Tell me what you think DevOps actually means.

Amando: You host Tiny DevOps, so I think you should start.

Host: You think I should start?

Amando: Define your own podcast title.

[chuckles]

Host: For me, the definition of DevOps really goes back to 2009, when John Allspaw and Paul Hammond gave their seminal presentation, it's available on YouTube, called 10+ Deploys Per Day. They laid out a concept, which we now call Continuous Deployment or Continuous Delivery. At the time, it was pretty new and revolutionary. Almost immediately after they gave their presentation, the first DevOps Days conference was organized and held a few months later on the same topics. To me, that talk is really important. Understanding that talk is important to understand what DevOps means.

The basic point they make in the talk is that the traditional mindset between Dev and Ops is that developer's goal is to push as many changes as fast as possible into production because customers want that. Operation's goal is white-haired old guys who just say no all the time, their goal is to prevent any changes from ever happening to production because they want things to be stable. The point of this presentation was that this is the wrong way to look at things. Actually, the goal of both Dev and Ops is to enable the business to serve customers. To me, DevOps is aligning the goals of Dev and Ops to serve customers. That can be done in many different ways.

The tools you use are interesting and useful, but they don't make DevOps. This is where it gets to that really fuzzy area where people say things like DevOps is a mindset [chuckles]. It kind of is. It's also not very useful as a statement by itself. You have to explain the rest of the context. I usually simplify when I'm talking about this to say DevOps is cooperation. That's an obvious oversimplification, but I think it gets us in the right direction.

If you can take a sentence that says DevOps and replace it with cooperation and it makes sense, you're probably on the right track. If it doesn't make sense, like you're talking about a DevOps team and you've replaced that and that was cooperations team, that doesn't make sense. That's why I like to make that oversimplification. That's my answer to what DevOps is. Please disagree with me if you want to.

Amando: That's a very interesting one. If I got a €1 for every time I applied for a job for a DevOps team, I'd have €5, which isn't much-

[laughs]

Amando: -but still more than you'd expect. I'm not totally sure if the irony is lost on these people. If you look DevOps, the term DevOps, the whole thing just comes from the need to have a term to describe that thing that, I guess, you call cooperation, which is totally right. At Trivago, I was part of the first team that actually used DevOps. I guess it created some good things for the business also, because suddenly you get a one person doing the job of two.

So that's always good, less expenditure. You get more ownership. I'm more likely to watch over my code so I don't break production. If production does break, guess who's fixing it. It does a little bit of that. It creates more ownership is not the actual word but it is one of the words I want to use, but it's not the other word I want to use.

Host: [chuckles] So many words to choose from.

Amando: Exactly, yes. With so many languages in my head, English is not even my instinct anymore. I definitely agree with more of that and cooperation, yes. I've seen some of your LinkedIn posts where suddenly, "Oh, yes, security. Oh, sorry, well, you must have been talking about DevSecOps." It's also about having terms, that people want terms to describe things. You come up with these terms and none of them really make sense. It's just people want to name things.

Host: Yes, I don't have a problem per se with DevSecOps, if it provides value to your context. If somebody suddenly is now thinking about security more because they're using the term, okay, great, use the term. If you put everything that possibly could fit under that umbrella together, you're going to end with a word that's longer than Mary Poppins' favorite word. It's going to be ridiculous. I just use the term DevOps to encompass BizDevSec, QA, AI, whatever Ops. It's the same philosophy, the same principle, of aligning goals to achieve the business outcomes.

Amando: Yes, I like you were saying of replacing the word with collaboration or cooperation and if it makes sense then you're probably going the right way. That's a pretty interesting way of looking at it. It's incredibly simplistic, but I was trying to think of one where it wasn't accurate.

Host: [chuckles] All right, that's the challenge for listeners. If you can find a place where replacing DevOps with collaboration or cooperation breaks things, send me a note and I'd love to hear about it. I admit that it is oversimplified. DevOps is more than just that. I think it points people in the right direction if they make that change.

Amando: Especially, problem statements like we need more DevOps. We need more collaboration.

Host: There we go, yes. [chuckles] All right, have we beat that horse? Shall we move on to the next one?

Amando: Yes, I totally agree with you on this one. We have a similar philosophy in this part anyway. Yes, maybe I'll change my mind later on. We'll see.

Host: Okay, we'll do that for the intro to 2023 episode. We'll change our definitions again. [chuckles] Let's move on to another big hairy one. Agile; this one might even be more misunderstood than DevOps and DevOps is pretty darn misunderstood. It's your turn to go first. Tell me what you think agile means.

Amando: I don't have the actual textbook definition what anyone calls it, but to me agile is something that is fast, whether it's fast to break or fast to fix, hopefully both. Anything that is not fast or as fast as it could be is less agile than optimal if you can use it as an adjective.

Host: I just looked it up. The dictionary calls or it says that agile is the ability to move quickly and easily, so, yes, I think you're on the target there. I actually learned just yesterday that when they were on their ski resort writing the Agile Manifesto, the word that they were using on that weekend wasn't agile. Of course, internally, they were deciding what to call it and everything, but their working title or their working concept was the word light, not agile. They were working for light software development, but I guess they thought that didn't have the catchy ring to it. Maybe they thought it would be even more misunderstood because light can mean so many things, from a color to physical light to less fat in your mayonnaise or whatever. [chuckles]

Amando: [inaudible 00:08:42]

Host: I like that context. It has the same connotation about the ability to move quickly and easily. You're not weighed down by procedures and extra whatever stuff you don't need.

Amando: Absolutely, you have the space to adapt to the situation instead of-- Also, one thing that always got me about the Agile Manifesto and people yelling it within corporations, it's people and interactions over processes and tools, if I'm not mistaken, then the first thing is here's this tool, every single time.

Host: Yes, agile, it's become a religion, maybe in good ways but definitely in bad ways, too. I see people trying to beat each other up over the head with the Agile Bible, if you will and trying to shove it down people's throats. You have to be agile. You're not doing it my way. [crosstalk]

Amando: Perhaps sometimes it is agile to not be agile.

Host: That's the paradox, isn't it?

Amando: Yes.

Host: I don't want to get too philosophical or too religious here, but I think there's a strong parallel between the idea of trying to force agility on somebody, and the idea of trying to force somebody to believe in your religion. You can't do either one. That doesn't make sense. It violates its own principles in doing so.

Amando: Exactly. Not all zealots are religious purely and simply by the religion we know, so, yes, there's a lot of agile zealots walking around.

Host: Definitely, yes. [chuckles] I'd like to go back to the Agile Manifesto. I don't think it's a perfect document, but I think it's a good document. There are some parts of it that are somewhat dated, but if we take it in the context of when it was written and what the computers had the capabilities to do at the time, I'm thinking specifically of the idea that it says in the principles it talks about we should release on the order of weeks or months with a preference for weeks. I think if they were to write that now, they would say with a preference towards minutes. In 2000 running an entire test suite and releasing the instant you hit merge wasn't feasible.

It is now. I don't think that was meant to be a lower bound. There aren't many, but that's one example where I think that the manifesto is somewhat dated but the principles are still sound as long as we can look past the written word to what it's trying to communicate to us. I think it's very valuable. When you do that, you get this sense of moving quickly and easily that so many zealots tend to forget about.

Amando: Yes. This one is also relatively simple. This would be actually more interesting with someone that doesn't really know these terms, someone from the business side that maybe has a PMP course and hasn't really looked into things that much.

Host: That's a good point.

Amando: Could be interesting, because also another thing with definitions of terms and stuff is that even if we disagree, it doesn't matter because we're not working together.

Host: [laughs] Fair enough. Yes, it's much more important that your PO agrees with- well, at least your at least understands what you mean.

Amando: Exactly.

Host: I understand what you mean.

Amando: Some internal document of definitions makes more sense than everyone having to agree on everything worldwide because it doesn't matter if I agree with someone on LinkedIn whether X means Y. It doesn't matter. As long as the people that I work with daily and collaborate with daily both say the same things with the same words, that's good enough.

Host: Absolutely true.

Amando: Perhaps we can move on to the next one. MVP.

Host: Yes. MVP.

Amando: Yes. I know you have some strong views on this one.

Host: I do. I see this word used incorrectly all the time.

Amando: Yes, it's a really MVP thing to use it wrong all the time.

Host: I guess so. An argument can be made that are you using it wrong if the people you talk to understand what you're talking about, and that's fine.

Amando: [inaudible 00:13:07] to quantify. Whichever basketball player brings in the most money is the MVP. That's it.

Host: There you go. Yes, but value is in the eye of the beholder. [laughs]

Amando: Yes, but there's a monetary value attached to it.

Host: But what is that money worth? [unintelligible 00:13:23] too far. To be clear we're talking about an MVP product, the idea that you're building an MVP. For this one, I think it's important to recognize where the term comes from. MVP, I guess I should have said this already, stands for minimum viable product. It's not a most valuable player or whatever. Those are fun too. It's minimum viable product. It's important to understand where the term comes from if you want to understand what it means, or at least what it used to mean, what it meant originally. A lot of people take MVP to mean simply a beta version or an alpha version of a product.

That we're going to build a first version of a product, it'll take six months and we're going to get it in front of some customers, and we're going to iterate from there. There's nothing wrong with that approach per se, but that's not an MVP as it was originally defined. The term was made popular by Eric Reese's book The Lean Startup. He gives examples. The best known example, I think, is Zappos the online shoe retailer that's been, I think, bought by Amazon since then. The founder of Zappos, when he was starting, when he had the idea to sell shoes online, it was a very non-obvious idea.

I don't remember when this was; mid, late 90s, I suppose. The idea of buying things online was already new and the idea of buying something so personal as a pair of shoes that might not fit and it might not feel quite right, even if it's the right number, that was a very unsure bet at the time. Rather than spending six months to build a beta and trying to get 1,000 customers and investing in a bunch of shoe inventory, he went to his local shoe store, took some photographs with a digital camera, of shoes, put them on a website and then once he sold a pair of shoes, then he would go buy the shoes that he had just sold and then ship to the customer at a loss.

When you think about this, that at a loss, I think, is a really important thing to remember here, the MVP. The goal of an MVP is not to have 1,000,000 customers. It's not even to impress 50 customers. The point is to learn as quickly as you can about your business idea, to see if it's viable. That's what he did. When you think about the fact that he was doing this at a loss, it might make alarm bells go off in people's heads. Why would you do that? You can't make money that way. Consider the alternative, which was probably to spend hundreds of thousands of dollars building a website versus losing $10 a pop on selling some shoes at a loss.

Amando: It's also an incentive for people to do something that was not really normal to do at the time, which is buying shoes online. If people see a $10, $20 difference from the store price, they might give it a shot, I suppose. You might end up with more data than otherwise.

Host: Yes. That's what an MVP is. It's the minimum product you can do to validate your business idea.

Amando: Yes, and from a business perspective, not necessarily a tech one, we're an MVP now internally. One of the investors wanted to have a look over my architecture design and everything. I was like, "I think an architecture design is precocious for an MVP. It's going to be a [unintelligible 00:16:50] application [unintelligible 00:16:51]," and he loved it.

Host: In some conversations I've had people bring up a related concept which is a proof of concept, which you could think of as an MVP for technical stuff, except there you actually want prove that your technical idea works not that the business idea works. They serve similar purposes but one is business-focused and one is tech-focused, more or less.

Amando: This is an interesting thing for definition, whatever an MVP is. It's more of a business first thing than Eric Reese's Lean Startup. That's where it came from. It didn't come from a technical book. I see a lot of developers just going way too far with MVPs. If it takes you a month to build, it's maybe not an MVP.

Host: An MVP could be a landing page for a product that doesn't exist yet. Say I'm going to build a course on how to launch Kubernetes on your Raspberry Pi or something, maybe I don't know if anybody wants to do that. I don't want to spend all the hours it would take to write the script and whatever. I'll just put up a landing page here. For $100 you can buy this course, and if anybody clicks on it it says, "Sorry, this isn't ready yet but I'll email you when it is," or whatever. You don't even have to take money. Just see who clicks on the button.

Amando: Yes. At one point I wanted to see if having written a book would make any difference in how employable I was. I just put up a fake book cover on my website and link to download it. It didn't change anything, but of course the end number was very small, so it could have been a difference. That kind of stuff. You have to be super lazy for it. If you're thinking too far too much [unintelligible 00:18:36] MVP. Also, you've sent some emails on your newsletter, The Humans [unintelligible 00:18:41] Complete thing, some are, but yes, a lot of manual work for an MVP is okay. I'm glad that the team I'm working with, they're aware of this.

They know that in the beginning, maybe some stuff will be on a Google sheet and you you're going to have to do it manually. They're perfectly aware that's the case. That's good, but a lot of people from the start-- I've done the same mistake as well. Manual work is okay for an MVP. Doesn't have to be perfect. Doesn't have to be super complex, isn't a proof of concept because if you're trying to prove that something works technically, that's not the MVP. The MVP is whether someone will pay you for this.

Host: Exactly.

Amando: This can be done by Mechanical Turk people.

Host: I recently heard a podcast where somebody was making the case that their product could not have had an MVP because their product was automation-based. I was listening to the podcast thinking, "You don't understand an MVP or automation." I think their product was rebuilding Kubernetes clusters or something. It was something fairly technically involved that can be automated, but my thought was your MVP should validate whether customers want to pay for this, not whether you can do the thing.

Amando: A landing page and a checkout button [crosstalk]

Host: You can even say for our MVP we will deploy your Kubernetes for you, but it takes eight hours and we're going to do it manually with keyboards and you have six people in India doing it for you. That could be an MVP too, and over time we're going to automate it so it's faster. This person just hadn't thought of it from that angle, and that's fine and maybe they didn't need that. I don't know. Saying you can't do an MVP probably means you don't understand what an MVP means.

Amando: Could be, but, for example, in the startup place where I am there's a lot of people that they've been going a year now without a product. They're pre-product, but they have money in the bank. They have things going on and their MVP was, essentially, a pitch deck to an extent because getting money from customers is one thing, getting money from investors is another. It's two different things going on there.

Host: Yes, and, of course, different business models and I don't know that an MVP is appropriate for all business models or all cases. An MVP is most useful, I think, when you have a completely untested market idea like selling shoes online for the first time. If I was going to start selling shoes online right now, I probably wouldn't do an MVP, or at least not at that level. It would be more of a POC. Then it's a question of do I have a niche that's small enough to make money or do I have enough billions to invest to start competing with Zappos or something like that? A very different question I need to answer then, will people buy shoes online?

Amando: Yes, exactly, because now you know that they will so it's not MVP stage. You can get shoe store themes from Shopify for free if you want [unintelligible 00:21:39] MVP is something that has to- you have to be lazy to get one done.

Host: Pretty much.

Amando: A lot of stuff is scrapped. A lot of stuff might be manual. A lot of stuff might not even be there. I remember at one point I was working for this online store and they wanted to test something. I don't remember what it was. My suggestion for the MVP was just having the button on the page and seeing if people actually clicked it to see if they would actually use it. If you create a new feature, and it's just hidden behind some link somewhere, you don't even know if people are going to click that link, so you're not even sure if you can provide the value if the customers are going to find it organically so you should test that before you develop anything.

Host: Next on the list we have API. Now, this is an interesting one, because it almost has a technical definition but I guess MVP is also an acronym that's fairly specific. What do you think an API is?

Amando: I think the actual term is Application Programming Interface. It's communication, perhaps, is a very simple name for it. API is communication, perhaps. One program using abstractions of another and it doesn't necessarily have to be programming. You can consider a kitchen making requests to a chef. There's an API there involved. It's just simplifying communication, simplifying input and output expectations, perhaps.

Like you were saying, it doesn't necessarily have to be a REST service. An interesting one is a development team. If you have a properly set up system, or you're going to have Jira, you create a task in Jira developers take care of it. That is kind of an API going on there. There's a certain format of inputs that goes in and a certain format of output that goes out depending on the inputs but that's not necessarily an API, is it? An API is just the transfer of-- It's an interesting one. I'm curious [unintelligible 00:23:55].

Host: You got the acronym right. I think of an API as a defined way that computers speak to each other or computer programs speak to each other. I just pulled up the Wikipedia page on the topic and it contrasts an API to a user interface, which I think is a good analogy. User interface is how computers interact with people or vice versa whereas an API is how computers or computer programs interact with each other.

Amando: Not necessarily. For example, the Arduino bootloader has an API. That's the same. How would you call it in that sense? Even microchips themselves have APIs for the code running in them to communicate with themselves.

Host: That's a case of hardware talking to software, right?

Amando: Yes. Also, different layers of abstraction, although this is compile stuff so let's not mention that one. Let's not leave people asking more questions.

Host: Anyway, I think the important point to make here because I think the confusion most people make, those who do make confusion, because they think that an API means a web service. It means that I'm writing a service that talks to another service over the web. Usually Rasp, but it could be Soper or some other XML-based web service. I think the important thing is that API does not mean web service. A web service is an example of an API, but it's by no means the only one.

In fact, before the web existed APIs existed. Often APIs are just the way you call a function. If you have a shared library, it has an API. In fact, that's how I learned about APIs. When I first learned of APIs, I thought of it as the set of functions in this shared library and how they're used. The web concept actually came later. The youngsters don't realize that but that came later.

Amando: I was going to suggest that because libraries, et cetera, they all have APIs and how to work with them. I guess a lot of principles apply to design a good API. They apply to probably all APIs which is very similar to object-oriented programming in general.

Host: I think you're right. I think a lot of the same concepts that come from things like good function names in object-oriented programming. Depending on how your API is designed, you want good endpoint names, or good function names or the parameters you pass they should be clearly named and so on.

Amando: I forget what the actual technical term for it is, but it just needs to know as little as possible about each other.

Host: Isolation concerns probably or something along those lines?

Amando: Something like that. That will apply. I've heard people say that microservices is just object-oriented programming but through network.

Host: In a sense. Calling microservices just anything is a little bit dangerous but on principle, I think you're right.

Amando: It's very similar. It's just now you have latency to think about.

Host: Fault tolerance and a thousand other things. Thus it's not just anything but the point stands.

Amando: I hope my employers don't listen to this but my philosophy with microservices is we'll implement it when I can hire somebody else to take care of it.

Host: Microservices are great for certain problems, but a lot of people don't have those problems. Let's talk about done. Can we define done?

Amando: That's a great one. I can put on my C-level hat for this one and I have a good analogy I think you'll like.

Host: I'm ready. Hit me.

Amando: Done. Again, this is a thing that depends from team to team, company to company but to me done means when something is in production, working and customers can interact with it. To me, that's what done means. Whenever somebody says done, I'd not question but I look at who they are to see what they mean because if you ask a mechanic, "Hey, is my engine done yet?" They might say yes and the engine might be done, but it might not be back in the car yet. It might still be on the shop floor.

If an engineer told me something is done, maybe it's the thing that is done is still not back in the car. If a business person tells me done, the way I see it is is it generating revenue for me yet? It is good to have some sort of alignment here and I do get the arguments that I sent my software off to QA, it's done. As far as I'm concerned, it's done but it's not because it could come back, for example. Even when it's in production, it might not be done if it hasn't been going and working for a week.

It might still come back and have some things let's say critical bugs that affect its functionality because if you count minor bugs as something not been done then things are never done done. Then you start saying done twice and if you have to say done twice, you know your definition of done is wrong.

[laughter]

One time someone asked me if something was done and I said it was pretty done.

Host: Pretty done, okay. I mostly agree with you, I think, although I definitely think context matters. Specifically, in the context of, say, a kanban board or JIRA or something like that. It is important to know when you can move that ticket from in progress to done. That probably isn't the same as it's generating revenue and there are no bugs and customers are happy with it because you probably don't know that until after it's been in front of customers for days or weeks or sometimes longer.

Amando: This one, I think it's also especially management, depending on who they ask because there's different people involved in different parts of something. Depending on who you ask, their part might be done. QA might have already tested it, you might say it's done but it might not have been deployed to production yet. Then it's not done done in the sense that the person that is asking expects. This is definitely something that internally everyone needs to agree on, and perhaps even create names for other things, like your stages on your kanban board and Jira, or whatever other system you're using. [inaudible 00:30:35] anyway.

Host: Yes, I agree. I think that every team should define done to whatever degree is necessary on their team. Some teams maybe it's intuitive, and they don't need a formal definition. That's fine if that works.

Amando: I think that's very difficult.

Host: I think it probably is, but I think on certain small teams, maybe it's okay, if you have two people and you just work it out or whatever. But if you ever find yourself in a situation where you're saying, "It's done except for," I think that's the time when you need to formalize what done means because if you have to verbally provide your exceptions to your done state, then it's not actually done. It would be really useful just for communication purposes to agree on what done actually means.

Amando: Yes. This goes both ways. This is not just something or definition you can agree in, let's say, isolation from each other because it's also about the person that is asking. They also need to know what they're asking because if they're just asking, "Is it done?" and they don't have a definition, then they don't know what they're asking.

Host: It's true. My wife and I have this problem almost every day when it comes to dinnertime. She'll say, "Diner is--" She says, "Ready," which definitely ready is a whole other topic. What she means is done, which is also confusing if you're trying to apply to scrum teams.

Amando: Actually, maybe I prefer ready. Is the engine done? Yes. Is the car ready? No.

Host: See, this is where these definitions are really useful because in most scrum teams definition of ready happens before you start the work.

Amando: Okay, like dinner could be done, but could still be the oven hasn't been opened yet. The [inaudible 00:32:24] is still closed. Dinner is just done.

Host: That's what my wife means. Dinner's done to her means now it's time to come set the table and pull the food out of the oven. To me, dinner's done means I can sit down now and I can start serving my plate. We have just this conflict almost every day. [chuckles]

Amando: Yes. You also need some internal documents.

Host: Yes, we need a wiki. If only we had Jira for our household runnings we could just put it in [inaudible 00:32:48]

Amando: It sounds actually like computers doing that, they probably need therapy and a few months off. [unintelligible 00:32:57] where agile hurt you.

Host: Have we done done, or do we need to do more? Is it done except for something else?

Amando: We're done done. We can do the hacker or hacking if that's [crosstalk]

Host: A hacker or hacking, you hear this come up. In fact, recently, I saw on a social media conversation where somebody made some bold claim that hackers are evil. I don't remember exactly what it was. What do you think? Are hackers evil? If so, or if not, explain your answer.

Amando: I wouldn't say so. I even have a title of an article which is complete bollocks, and I know it is, but, GDPR rules, do they make hacking legal in a sense? Because if companies are required to give you your information on your request, you can do that with hacking. Things are not as easy to hack anymore. I guess if you're a developer, you should know how to break your own stuff. If you can break your own stuff, you can figure out how other things are done and know how to break other stuff. It's perhaps quite software-related because it's reverse engineering stuff.

My words don't come out properly today, but when I was first learning SQL, for example, I knew what I shouldn't do for it to not be vulnerable. This doesn't really happen anymore, but when I started learning that, I started learning when other systems I was using were vulnerable and, of course, I played around with it a lot. I got a lot of interesting information. At one point, I was able to display whatever page I wanted on a competitor's website. The search button, they had a search field, you could put in any URL as long as before it it had some quotes or whatever, and it will display whatever was in that URL.

That's useful for phishing and stuff like that. Like, "Hey, your account is hard," et cetera. That doesn't really matter. Also, credit card information, even when all the credit card payment suppliers did not save data locally, which is why they tell you. Hackers are not evil. That doesn't make any sense. That's just a strange LinkedIn post just to attract attention.

Host: Do you have a definition for what you consider hacker or hacking to be?

Amando: Getting access to something you shouldn't have access to.

Host: I have a broader definition of hacking than that actually. What you described, I would describe as cracking, which is gaining unauthorized access to something. It could be someone's account, it could be breaking DRM on music, on your iPod, or rooting your phone. Any of that sort of stuff is cracking.

Amando: [unintelligible 00:35:57] some software to bypass the if condition for the license.

Host: Now, that is a form of hacking, but I think hacking is broader than that. This is a very informal definition. I haven't looked it up, but this is just my concept of it. Playing with something to learn how it works, or to see what you can do with it.

Amando: Yes, I agree. That's another definition, which this is how a lot of people actually use it, especially in mainstream media and stuff, is using something for something it wasn't intended to be used for. Like, this guy hacked gambling sites, or not gambling sites, but this woman hacked Tinder.

Host: Life hacks. Use duct tape to wash your dishes or whatever magic you might come up with.

Amando: Yes, but that kid from TikTok already ruined those with his.

Host: I think of myself as a hacker. In fact, I think of my daily work, writing code, is largely hacking. I'm not trying to break into any systems. I'm just, "Okay, I need to solve this problem. How am I going to do it? I don't know. I'm going to try a bunch of different things and see what works and what can I do with this."

Amando: Reverse engineering kind of thing.

Host: Yes, definitely reverse engineering, I would say, is hacking. Even if it's not software. If you're reverse engineering a piece of hardware or a lawnmower, you might even call that hacking if you want to.

Amando: Yes, fair. In a lot of maker spaces, a lot of people consider themselves hackers.

Host: It sounds like even amongst ourselves, there's still some ambiguity here, and I think that's okay.

Amando: Even within ourselves.

Host: I didn't quite say that right, did I? I didn't mean within myself, but between the two of us, there's still some ambiguity, perhaps within ourselves as well. I don't know.

Amando: Like I said, it only matters if the people that you work with agree on the same definition, because otherwise it doesn't really matter. This is an interesting topic because even if you go for society, people have to know what the words mean. If people start changing the meaning of words, then you can't get anything done, because if you hear a certain word, you expect it to be a certain thing, but it turns out five years ago, Merriam Webster changed that to something slightly different, just enough to cause confusion. It can a dysfunctional team, it can create a dysfunctional society.

Host: I think you touched on a really good point, though, which I think they call white hat versus black hat hacking. Black hat, if I'm not mistaken, is the idea of breaking into something for nefarious purposes. White hat is generally the idea of breaking into something to demonstrate how it can be broken into so that you can fix those security holes, although there might be other reasons.

Amando: That's the reason Amazon pays out sometimes $20,000 for people to bring vulnerabilities to them. I think $20,000 is still very little for some stuff because if you could theoretically profit millions from it, $20,000 isn't going to cut it. I think for stuff like that, they would cut you a slightly different deal. Even white hat hacking, like at one point, I gained access to credit cards in some online store, and I sent an email saying, "Hey, guys, you have this vulnerability and so on and so and you should probably fix it."

Of course, the reaction wasn't-- I expect it to be strange, because it's like working for an alarm company, and then writing a letter saying, "Hey, I'm selling alarms. You weren't home so I left this letter on your kitchen table." It's like that, like, "Hey, you have this vulnerability, and here's all the credit cards for your customers and all the transactions since 2004." It's a bit like, "Are you scamming me?" Then nothing changes. There's definitely that. Then there's also the gray hat, which if it's more profitable to be black hats, you go black hat. If it's more profitable to be white hat, you white hat.

Host: Then there's red hat, but that's just a company owned by IBM and it sells Linux distribution.

Amando: They're an amazing money making machine.

Host: All right, tell me what you think of the difference between an engineer and a developer.

Amando: I could think in different ways, this case. If I'm a developer I might think some things, if I'm an engineer I might think other things. But without trying to act superior or anything, an engineer will actually engineer. It's also a verb. A developer might be someone that has a smaller scope in what they actually do. An engineer might engineer the system, which is a lot of just thinking going on.

An engineer might the swagger documentation for some API, the developer will do it, but you could also say that that's more of an architect, so it depends. Engineers definitely have a broader scope in what they do. Developers code more, think less, because the thinking was already done for them. If you're a developer, and you have to think a lot, perhaps you're an engineer.

Host: I don't have a strong feeling on these terms. You could also throw programmer in there if you wanted to, or even coder. There's maybe different degrees of these things, but these terms are often used synonymously. My thoughts on this, it's a very different angle than what you just said, and I don't disagree with what you said.

Amando: It's also not strong in any means. It was just one of the ways I could think about it.

Host: I could definitely see it working that way. My personal thought on it is that engineer is usually a bad metaphor for what we do in software. There are times when it maybe is appropriate, and this comes out of the software craftsmanship ideology, which I don't a 100% buy into either, but they make the point that engineering implies a big project, maybe a flight to the moon, for example.

There was software engineering going on there in the sense of this waterfall approach, your big design front, you decide all your requirements and your constraints and so on and engineer the system, and then just have the little peon coders build the stuff that you engineered. In the truest most complete sense, that's probably definitely software engineering. Maybe those projects do still exist, maybe they even should exist. I don't know. I don't think that's what most of us are doing except in maybe very small scale.

Amando: Yes, so you're saying the more agile something is, the less engineering is going on.

Host: Kind of. Sort of. Engineering is still happening, but it happens in a different way.

Amando: Yes. Yes. Let's say a bridge, a lot of stuff is a given like gravity, the amount of weight that is going to drive through it. A lot of things are a given, but with software, nothing really is a given, so less engineering has to go on, and it's more of a hacking.

Host: Yes. [laughs] There are definitely people who make the claim that Agile software development fails because it doesn't believe in engineering, specifically XP because it doesn't believe in this sort of engineering approach. I'm not actually sure that I agree with that. I'm looking up something quickly.

Amando: I can see the logic behind it.

Host: The thing is that Agile software practices and XP, in particular, do engineering, they just do it in a different way. I did a recent episode with JB Rainsberger where he talked about evolutionary design, which I don't think we used the term engineering in that conversation, but I think it's the same sort of thing. It's the idea that you could build a design or engineer a design, piece by piece as you need it, rather than doing it all at once. So in that sense, it still is engineering, it's a different kind of engineering. If you want to use analogies-- and I think this is why the software craftsmanship group say engineering is a bad analogy, because it doesn't really feel like it fits here.

It feels more like a gardening activity or painting a masterpiece. It's more of a step-by-step iterative, feel-your-way-through-the-system rather than a big engineering effort up-front. Does that mean that I think that software engineer is a bad title? Not necessarily. I think it's mainly synonymous with software developer or programmer. All analogies are limited. That's why they're called analogies and not the thing. Those are some of my thoughts. I don't have a strong conclusion about that.

Amando: Yes, it's a hard one. You could say that less premeditated planning is less engineering in a sense, but I'm just opening up the Wikipedia page, and the term engineering is derived from the Latin, ingenium, meaning cleverness and ingeniare, which means to contrive or devise.

Host: We definitely do those things even in Agile Iterative Development, right?

Amando: Yes, exactly. But also the word engineer not everyone can have that title everywhere. For example, in Portugal you cannot be an engineer if you don't have a master's or might be a bachelor's. But Portugal is strange because people with just a bachelor's are also sometimes called doctor.

Host: I think the same is true in Canada that you have to have a master's or something to be considered an engineer.

Amando: It's a protected title, and that's maybe why the word developer and coder and stuff like that popped up because there's a lot of-- I don't know if a lot is the right word, but there's a substantial number of people in this field that don't have degrees.

Host: Well, I certainly think that the term or the title, the job title engineer has become devalued, at least in America, the United States, where I lived most of my life. You would have engineer tacked on to anything. Customer support specialist engineer, or sales engineer. You're just a salesperson. You just tack on engineer to make you look more impressive, without changing the job description at all.

Amando: Yes, I've heard of WordPress engineer.

Host: We all know WordPress wasn't engineered, right?

Amando: Although I don't dislike WordPress. I don't dislike Automatic. They're cool. Everyone who starts, regardless of their title, starts off with two weeks of customer support.

Host: Okay, I guess I won't be working there.

Amando: They want to weed you out.

Host: Yes, well, they did. I wouldn't have worked there anyway. I don't want to work in PHP, so they weeded me out on several different fronts.

Amando: Yes, PHP is a--

Host: No disrespect for those who like PHP. I just don't like it. It's okay that you don't like the things I like too, so.

Amando: Yes. There's ways to make it less sucky. But, of course, if you're coming from go, there's no reason whatsoever why you'd do PHP unless you're getting paid €120 an hour for it, then yes.

Host: I guess that might help. Cool.

Amando: Yes, well, all right then.

Host: So shall we call this an episode? I think we've tackled some hairy definitions. We've come to a few conclusions.

Amando: [unintelligible 00:47:51] the DevOps definition, but we didn't define what is a big DevOps, and what is a tiny DevOps. That might be an interesting one.

Host: The way I look at it is that most of the DevOps literature out there, and I don't just mean written words, I also mean YouTube presentations or conference talks and all this stuff, most of it's about the big companies [unintelligible 00:48:14] that comes from Google and Netflix. In fact, the 10+ deploys a day, I think that was from Netflix. Netflix, Google, Amazon, Spotify, these companies are the ones that are making all the big splashes, and that's great. I love it. I like listening to their success stories. I like to hear how they were able to handle 15 billion requests per second, or expand to 10,000 Kubernetes nodes or whatever, all these technical challenges. It's fun.

The same way I like to listen to the stories of how they landed on the moon, and that stuff. But most of us are never going to do those things. Most of us won't land on the moon or deploy 10,000 node Kubernetes clusters. Even if we do, that probably won't be our only job. Most of us work in small companies, small to medium size companies, or we will at some point in our careers, and those companies face a certain type of challenges that the big companies usually don't.

They usually have lower budgets. They have fewer people on staff. They have fewer seniors on staff, and so they need to solve these problems, the same sorts of DevOps problems, the cooperation and collaboration problems, but they don't have these deep pockets and huge data centers and all the fancy things that the big players have. So that's what tiny DevOps is. It's focusing on the smaller companies that have to solve the same sorts of problems.

Amando: Yes, so basically the smaller problem-- not smaller problems, but tiny refers more to the company than the DevOps itself.

Host: Yes, so I target my consultancy, and this channel, also, I try to keep the topics relevant, to people that are trying to do DevOps on a team of 1 to 20, 25 people.

Amando: Yes, fair.

Host: I think there will still be a lot of relevance to people on larger teams, but if you have a problem that's specific to a 50-person or a 1,000-person team it's not for this channel.

Amando: Yes, fair.

Host: All right, thanks for coming on. It was fun talking about definitions. It's fun to see you again. Let's do it again. I'd love to have you back on the show for some more definitions or another catch-up at a later time.

Amando: Yes, for sure. My English wasn't great today because I was just thinking in Norwegian all the time.

Host: Well, I'm sure your English is better than my Norwegian would have been.

Amando: I don't know. Do you speak any Dutch-

Host: Not really.

Amando: -being in the Netherlands [unintelligible 00:50:39]

Host: Not really. Very little.

Amando: Okay.

Host: I can read the menus.

Amando: If you know Dutch, Norwegian is quite easy.

Host: I did notice that when I was in Norway, that the signs looked like somebody misspelled Dutch.

Amando: Yes, basically, just like Dutch looks like misspelled English, so it's just a few misspellings away from [unintelligible 00:50:56]

Host: Exactly, yes. [laughs] All right, thanks so much. We'll see you all next time. I hope you tune in again later.

[music]

[00:51:26] [END OF AUDIO]