Picking Up From a Coffee Shop in Austin
0:00Well, hello, everybody. It's the 14th of July, 2009. And this is the Agile Executive Podcast number four, I think. But I could be wrong. Who knows? So last episode, as avid listeners, and I'm sure there's at least two or three of them may recall, Israel and I were like outside of a little coffee shop here in Austin. And we got to one of the topics we got to talking about was essentially the mixture of sort of agile software development or agile in general, sort of moving more into the IT world and a little bit of vice versa. And now, so this is obviously this is Michael Coté talking and Israel Gad is also on here. But I thought it would be nice to bring along one of the people that we mentioned in that podcast and someone that both of us have talked to on this topic who is, well, why don't we just let him introduce himself? Why don't you introduce yourself? This is Andrew Schaefer with Reductive Labs. We're the people behind Puppet, but I'm also deeply interested in agile software techniques, agile infrastructure, agile ops, and how businesses can deliver more value. And so a couple of days ago, Israel gave like a little teaser of what we're going to talk about today. But for the listeners, do you want to kind of give us a little summary of kind of the sort of loose idea we were thinking about in that teaser post, Israel?
What Stands Between Agile and IT
1:18I will be glad to. We were thinking in terms of what stands between agile and IT. Namely, traditionally, we apply agile in software development. And the results have been so promising that various authorities, for example, Dean Leffingwell, started talking about applying it to other knowledge work. One of the adjacencies of agile is, of course, the business of deployment. Namely, you can do agile very, very quickly and then lose all the time with the software being on the shelf if your deployment is not speedy. If you are able to develop quickly and to deploy quickly, the advantages are compounded. And they are compounded on quite a few dimensions. We are talking about time to value being much shorter. We are talking about making various decisions in terms of actual customer feedback rather than hypothesized customer feedback. And we are talking about the combination of
Deployment as the Economics Problem
2:38developed software and deployed software in efficient manner as being a low-cost input in the overall economics. So this is a subject that has been intriguing me for some time now. And I'm very, very happy to dig into it. Yeah. And, you know, I think when we were talking about it back at the cafe there, you know, we were kind of digging into kind of like what that looks like as far as some examples we could think of. And I remember I was cooking up some kooky example of what having essentially to narrow down to one thing, being able to deploy things much more quickly on a daily if not sort of multi or within a daily basis to be very extreme about it. And, you know, I think the interesting thing, you know, that kind of Andrew can bring to this discussion is, you know, his work at Reductive Labs and just thinking about the topic in general. There's a lot of these sorts of things of like what exactly this, to use the phrase for it here, what this sort of more agile like operations or IT sort of looks like and kind of examples of people using it to their benefit. And with that sort of layup there, I mean, where do you see agile and IT kind of coming together in your world, Andrew?
Bigger Than Deployment, and Why Ops Resists Change
3:54So let me start by commenting on what Israel just said. And I think in my mind, this idea of agile infrastructure and agile operations is much larger than just deployment. And hopefully we'll explore that through the, you know, either this podcast or in the future. But in general, your traditional operations has built up a resistance to change. Change causes outages and operations wears pagers and they don't really like waking up and putting out fires. So they tend to adopt heavyweight processes to essentially slow the change and protect themselves from their own organization. But the fact is that change happens. Change has to happen. Change is what enables the business. You might as well embrace it. You might as well enable it. But you want to mitigate your risks as much as you can. And in general, if you think about agile, I break agile into sort of two piles. I break it into a pile of sort of engineering and process techniques and then a pile of engineering techniques. And in the engineering pile, the basis of every agile technique in my mind is being able to build your application from source.
Could You Rebuild That Server From Scratch?
5:18So you can't talk about anything else, test driven development, version control, all that stuff. Well, version control, I guess, is sort of a baseline. But you need to be able to build from source before you can rebuild their servers from scratch. But not very many people can rebuild their servers from scratch. If you go through most organizations and look at every server, which, you know, ostensibly these are serving business critical applications, if you just threw that server out the window or blew up that part of the building, everything, then how fast can you get those services back online? And I think that's sort of the fundamental question is, if you can't rebuild your servers, your services from scratch in an automated way, then you can't really talk about being agile in ops, in my opinion. And I think just to make sure that, you know, to focus on this, there's, there's a little bit of like a leap that you made there between development and operations. And that's sort of the kind of the way you put it in a recent post was to look at your infrastructure as, as your application, essentially, or as part of or an application. And then, you know, when you start to think of the servers and the middleware and all that junk, essentially, as part of your application, rather than the thing you run your application on, then it starts to become more natural to think about how do we build that part of the application from source, if you will. And so the source may not be like the source code for the operating system and all of drivers and all this business. But the point being that,
Building the Infrastructure Like the Application
6:56you, you have control over as, you have control over as, as sort of, I don't know, as hopefully as quickly and hopefully as easily as you can sort of build your application, you can also build the infrastructure that is part of that application, if you will. Exactly. And to be clear, you know, participating in this and watching this, I feel like this is essentially being driven by web operations. And one thing that becomes, if your application is a web application, if that's the business, if the business centers on a web application, what you've essentially done is you've, you've traded all the headaches that you had, you know, trying to make sure that this application would run on every version of Windows and Linux and Mac or whatever. And giving yourself some operations issues that you have to keep up. So at the end of the day, if you don't have the infrastructure, you don't have an application. It doesn't matter how good your idea is, how good your source code is. If you don't have an application. So you have to kind of abandon some of these ideas. And this is something that in some agile thoughts, it just, it kind of gets to me, but you have this idea of a non-functional requirement. Is anyone familiar with this term?
The JVM Upgrade Nobody Could Justify
8:13Sure. It's sort of like the bane of sort of product management and agile for all sides, because there's always people who want, I remember like one infamous thing, which there was some team I was on and we wanted to upgrade the JVM, the Java runtime. And it was, it was kind of difficult to figure out how to position that correctly and sort of like, you know, the motivation for getting an agile, like requirement in, because it was essentially a non-functional sort of thing that didn't have like direct or obvious or intuitive sort of user impact, if you will. But, uh, so yes, at least I'm pretty familiar with that. So in general, my opinion of that perspective is that on one level you're looking at, okay, we have business value, we deliver to the customer, we can charge them X amount of dollars. On the other hand, you have a whole bunch of stuff that you just kind of don't do that ends up costing your team tons of time and money. And I think on some level rejecting this notion of a non-functional requirement, because in my opinion, a lot of these go right to ops, they go right to things that make developers and operations lives a lot easier. And, and some of them, and the majority of them, if you don't fulfill those requirements, then your application is non-functional.
Why They Call Them Non-Functional Requirements
9:31So that's why I think they call them non-functional requirements. I would actually like to take your good point and make one additional step with it, if I may. And tell me if I'm putting words in your mouth, please. To me, uh, one can run in one of two modes. The one mode is when you have 10 or 20 or 50 or 100 versions of your software for your top customers. So you make a special one for top customer number one, and it's another special for top customer number two, and so on and so forth. So what happens, sooner or later, you have produced, let's say, 100 versions of your application and of your infrastructure. And you are stuck maintaining all those, and usually when you branch of a branch, you start getting into big trouble, or trying to get back into the trunk of the code. In contrast, in web applications, the way you relate to them, we might have produced 100 versions of the software and the infrastructure. However, at any point in time, only one version rebates.
One Trunk Versus a Build Per Top Customer
10:51So rather than having all those specialized versions, each for every top customer, instead we have everything merge immediately into the trunk and serve as, so to speak, the single source of truth in terms of what we are running. So the benefits in terms of maintenance, in terms of currency, in terms of responsiveness, to me are immense. Sure. Just to be clear, there's a conference called Velocity Conference, which in my opinion is sort of at the forefront of what is the emergent practices, the emergent ops practices that are sort of on the verge of where XP was for programming 10 years ago, in the late 90s. And all those talks, or a majority of those talks are online. You can get them on Blip TV. Just search for Velocity Conference. So I'm sure Codec could put the link up. But one of the things that John Alspaugh said in his talk about dev and ops cooperation at Flickr was always ship trunk, which is essentially echoing what you just said. Well, I wasn't actually aware of that.
Reaching the Same Conclusion From Different Data
12:08I have seen the slides that John has presented, but I have not had the opportunity to listen to his live recording. To me, it's, you know, a wonderful confirmation. Obviously, the data that he is using is completely independent of the data and experiences that I use. And yet, completely independently, we reached identical conclusion, what you call always ship trunk. Well, they had a – their focus of that talk was the operations and dev cooperation. And they're advocating that you always ship trunk and that you have a shared version control between your dev and your ops team. And that allows you to communicate and everyone always knows where to look. If you have a bunch of branches and you're managing multiple branches, anyone who's been deeply into the development process knows that that can be a bit of a headache sorting things out and knowing, you know, okay, well, I made this change in this branch to get into this other branch and it's just a bit of, you know, code accounting that becomes overhead and unnecessary in a web app. And what they do at Flickr and what sort of other people advocate is that you – instead of branching, you protect –
Feature Flags as Knobs During a Bad Deploy
13:26you basically put branches in the code that allow you to turn features off and on. And that further allows you to protect yourself when you have a deployment that's causing problems with the infrastructure, you know, because of bad SQL or whatever. You can turn off features. So it gives you knobs to control the impact of your deploys until you can get those sorted. Well, you know, along those lines and also the sort of, like, IT developer culture conflicts that we were kind of alluding to earlier. And I'm curious, like, you know, definitely, like you're saying, like this year at Velocity, you kind of saw a lot of how web companies are bumping up against and doing this sort of thing. And there's always, like, the granddaddy example of Flickr with their five releases a day or whatnot. And, you know, a lot of the cases I see of people doing this are, to your point, are sort of consumer-based public web companies. And I'm curious when these ideas – and I've kind of been curious about this since I've heard about this sort of stuff. Like, how these ideas spread to sort of the rest of the IT world, you know, whether it's just, like, boring enterprise stuff or business stuff or whatever.
Does the Humdrum IT Department Do Any of This?
14:41Or, I don't know, maybe they don't or something. And I'm curious if – like, what examples you guys have encountered as far as, like, just, like, the humdrum IT department is doing this kind of stuff? So, just like I mentioned a minute ago that I feel like the, you know, the ideas and the people are participating in things like the Velocity Conf. And there's some discussions and groups that are also moving things forward. But, in general, just like, you know, XP, people said they're doing XP or they're hiring XP 10 years ago. The kind of osmotic distribution of those types of practices has been underwhelming, in my opinion. And on some level, people talk about it, but they don't really do it. So, I'm sure that there are tons of practices that are fairly simple and easy to implement that would provide a ton of benefit in a lot of organizations. But, in general, I'm not terribly optimistic that they will adopt them unless they – unless someone could tie it to money or to some sort of business driver upstream, then sort of the grassroots adoption of these types of practices is often a losing battle.
Change Is Endemic, So What Is Ops For?
15:57That's sort of where the executives – that's why I'm hoping Israel can help spread the word. Well, I'm actually wondering, Andrew, and tell me whether the following way of reasoning makes sense to you. Why does change happen? Change happens because the environment within which a company is operating changes. And this is particularly true, has been particularly true over the past seven, eight months or so. So, change – change is endemic. Part of this change reflects itself, manifests itself in the IT environment. And the point to me is the function of IT or the objective of IT is not to minimize change in order to get the highest availability. The objective of IT is the objective of IT is to serve the needs of the business. Absolutely. If the business changes, then IT needs to change in accord. There is no point, of course, in changing for changing sake. But to be in IT and to say we would be deliberately very slow on change because we don't want to take the risk, to me, does not weigh the pros and cons in an equitable manner.
One Percent More Risk Against the Business Benefit
17:27Yes, the risk of going down might be increased by 1%. At the same time, the business benefits might easily outweigh it. An example that I would give you along those lines, years ago, the CTO of a company named Algorithmics discussed with me applying agile with some of his banking clients. And I was shocked by the large growth of programmers that the banking were using for all kinds of hedging schemes, etc. And I told this guy, look, I don't really understand why this very, very wasteful way of developing software. And he said, Israel, you don't understand, they recoup years of investment in software in one good trade, in Wall Street or London or Tokyo or whatever it was. So the benefits to the business are such that they easily outweigh the benefits that a more efficient development would have given. So this is a kind of fine line that I think IT needs to embrace, namely, you can't change too frequently or too haphazardly because you might paralyze the business.
Ops Exists to Enable the Business, Not Keep Boxes Up
18:50At the same time, you can't be pushing back about change all the time because you would paralyze the business in a different manner by not letting it respond to change. Yeah, I agree with everything you're saying. If you go back to John Alspaugh, who's a rock star, he had a slide that said exactly what you said, that ops job is not to keep the machines up and stable. Ops job is to enable the business. And so you want to be able to take advantage of everything that is an opportunity requires change in almost every case. So if you can't change or you're afraid to change or it's expensive to change or you change and it brings down all your applications, then that's not very agile. And I think it was in his talk, and you can go watch a bit. He said that – and they used the word agile in their talk. He said if you bring your machines down, you know, if you have downtime or outages 10 times a day, that's not being agile. That's just retarded. I certainly agree with that. And I would actually like to highlight your good points in the following manner.
Deja Vu: Rigid Deployment Plans as Rigid Project Plans
20:10Years ago, you know, we had similar things with development, namely before we got into iterative methods, then this business of adhering to a rigid plan was, you know, paramount for a variety of reasons in the way we did software. In many ways, when I hear sometimes from IT centers about their adherence to a very, very rich install and deployment process, I have the sense that it is déjà vu. Maybe the same disciplines that we used to apply to software development seem to apply sometimes within the IT center. And I see no reason that things that have proven themselves so well in software development would not be applicable with the right modification, of course, to IT. I agree. One of my favorite quotes is that no plan survives the initial contact with the enemy. And I kind of feel like no requirements document survives the initial contact with the developers from personal experience.
Business IT Alignment, or Wasting Cash
21:25Yeah, I think what Israel is saying gets to kind of like the next thing I was interested in talking about. And like, so, I mean, we have this idea of sort of like agile developer practices sort of meets the IT world, if you will. And then, of course, as we actually covered pretty well, to use the old enterprise phrase, you know, IT is concerned with this business IT alignment, which is basically like helping the business make money rather than, you know, retarding it, as it were. Right. Or just wasting cash, which would be the lesser evil than just kind of like grinding the business side of the house to a stop. And so, you know, I mean, we started out at the beginning like talking about one of the practices, you know, sort of like a principle level and then a practice level kind of. Absolutely. In the sense of sort of like somehow modeling your IT and your servers and everything such that you can treat it like source code, if you will, your infrastructure. And I'm curious, like in addition to that sort of principle and practice, as you guys are kind of looking at this idea, like what other sort of principles and practices you see emerging from kind of like this agile IT are? So the first step that – this was a reoccurring theme at velocity that was brought up by more than one person in both talks and hallway discussions.
Automate the Infrastructure First
22:47But you basically – you need to automate your infrastructure. That's the basic starting point, right? That's the – if you can't build those servers from bare metal to running services, then you're going to have – you're going to spend all this time doing that. And I think another thing that's happened is it used to be that the capacity planning was a long process and then, you know, obviously take some analysis. But then if you want to add capacity, you add – you make a purchase order and then some machines got put on a truck somewhere and they eventually come to your building or your data center. And then you have to rack and cable those. And then, you know, if you are really in the dark ages, you have to go put CDs or something. If you have, you know, one level of automation, you can pixie boot and bring machines up. And then if you have to configure those with kind of traditional methods, that might be a lot of work. There's a guy in the puppet community by the name of Paul Lathrop. He's a senior systems engineer at dig.com. And he came on the list one day and he was very excited. This is a couple months ago that he just rebuilt 60 machines from bare metal to running services and it had taken him two hours.
Sixty Machines With Puppet Against Two Days by Hand
24:06And he was mostly a spectator using Puppet and some – it was five. So they were – it was Debian machines brought up from the network and then Puppet built out the services. And he said that a year ago, that same job, rebuilding those 60 machines, would have taken two full days of work and working the whole time. So that's an order of magnitude at least improvement in time efficiency. Right, right. I mean it reminds me of – there's all those little – there's a handful of like neglected corners of like ITIL and service management. There's the one that's like – I forget what it's called, but it's basically just like acquisition of stuff. Sure. And, you know, there's also capacity planning, which I always thought was sort of like much embarrassed by virtualization consolidation. It's sort of like whatever capacity planning we were doing had left that much spare capacity on the table that could be consolidated. But without getting down that rabbit hole, it seems like there is a certain amount of – beyond just once you actually have everything, you know, sort of racked in cable, like the actual getting stuff before that, getting to that state where you can actually just turn the machine on and start doing things with it. Absolutely. Absolutely. Coté, I think you are out of something which I would pose as a question.
Is ITIL the Waterfall of the Data Center?
25:22And the question is as follows. In our social development circuits, we oftentimes contrast waterfall methods with agile or iterative methods. The question that comes to my mind when you are mentioning ITIL is whether it would be appropriate to draw the analogy that ITIL for the data center is in many ways like waterfall to social development. Does this analogy make sense to you or do you think I'm smoking something strong? So I'd like to make a quick comment there because I think in the – you know, and obviously if you follow how I talk and what I write about, you know, I embrace agile as sort of an idealized concept but I'm not always impressed with how agile manifests itself. And in some cases, the agilists tend to kind of demonize this mythical waterfall creature. And in reality, most places don't necessarily have waterfall. They have some ad hoc homegrown special snowflake process that doesn't look like any other process any other place. And I think when you start to contrast that with ITIL, there's a recent report that came out about ITIL and CMDBs and less than 5% of these enterprises who supposedly buy into this stuff are implementing a CMDB.
Easy to Demonize, But Nobody Fully Implements It
26:54So on one level, I totally agree with you as sort of this slow-moving, you know, impedance that is easy to demonize. You know, obviously you guys – Kode, you probably – you just did a podcast with the IT skeptics. That's right. So I'm sure he had plenty to say on this topic. On the other hand, not very many people are really implementing ITIL just like they're not implementing waterfall. Yeah. You know, I mean – and I'll have to put a link to that thing now, that IT management podcast, because this is one of the – this is in a roundabout way. It's similar to something that we were talking about with the guy, Rob England, who also goes by the moniker, the IT skeptic. And, you know, I mean, his – as his name would imply, he tends to be quite a rock thrower against like ITIL and CMDBs and things like that. But in reality, a lot of the – he's a lot more into what I sort of call – I always like to stick pragmatic in front of something. And he's always trying to get people to do pragmatic CMDBs and pragmatic ITIL and things like that, which essentially means, you know, it's one thing to sort of like map 100% of your IT infrastructure in a CMDB. It's like a huge task, which is very expensive and may indeed slow you down as far as like delivering that service management.
Map Only as Much Into a CMDB as You Need
28:13But, you know, there's other more adaptive things you can do where you only map as much as you need into a CMDB or you only do so much of the process that you need. But the important thing, which he emphasizes over and over again, not to put too many words in his mouth, is to sort of like figure out those goals that you're trying to do and figure out between tools and people and process that you have, like if you can sort of meet those goals, essentially just doing change management, which is – The simplest thing that could possibly work. Exactly. And so that's – see, there's a very agile principle right there applied. And I think, you know, his point, like to use one of his examples that we talked about in that recording yesterday is essentially, you know, when you're trying to get the maximal amount, the waterfall ITIL, I guess, you could think, you know, what we need – the problem that we have is all of this process and knowledge is trapped in someone's head or some people's heads. And we need to get it out of their heads and into the CMDB such that it's always stored somewhere. And, you know, one of his sort of anecdotal points is, well, maybe you don't really need to get all of it out of someone's head. I mean, you have a process. It may not be sort of like a Fortune 50 optimized process that defense contractors can use that doesn't rely on people. But for some organizations, relying on people to kind of know parts of what's happening in the process might be sufficient for you and it might work out.
One Change Process for Every Kind of Cloud
29:32And then instead of getting all worked up and bothered about modeling everything and storing everything and locking everything into whatever ITIL enablement tools that you have, you might rely on people and you might rely on tools. But the important thing above all of that is that no matter if it's sort of like, to use one of Andrew's terms, sort of like a meat cloud or a whatever type of other cloud, like you have the same process that both of them are plugging into. And I think that's – as with – I mean, this is the same sort of – you could kind of go through and do a search and replace of everything I just said with like RUP versus Agile. And it would be a similar sort of discussion where it's really easy with ITIL and all the tools that are embodied in it to sort of like – as I always like to think, you know, we used to have those big rational and RUP process charts. And, you know, in reality, you were supposed to sort of pick and choose and customize the stuff from RUP that you wanted to use. But everyone would be obsessed with having everyone doing everything on that giant chart. Whereas I think ITIL is a similar sort of thing where you're more interested in not necessarily buffeting it and picking and choosing, but you pick out the amount of effort you want to put in to kind of reach the same goals and enable the same process, whether it's sort of like spending all your time updating CMDBs or just, you know, updating your Post-it notes.
How Much Choice Is Too Much Choice
30:49And that ends up delivering the same nice process for change management. Allow me to bring up a question here, which is what amount of choosing between the options is appropriate, and what amount is overwhelming? Certainly my experience with system management has been time and time again that we as an industry generally offer too many options to our customers. And oftentimes the customers start with eliminating 95% or some such percentage of what we offer. Now, the definition of what is appropriate in terms of flexibility that I provide to my customers and what is not appropriate obviously has tremendous economical value. In addition, I think it has a great effect on the way things change, and I, for one, believe that tools, and certainly the right tools, can really change behavior. Is that something that you, Andrew, when you call upon puppet shops as witnessing?
Tools Enable Process, Habits Defeat It
32:12Yes, yes and no. So I think that this is a very interesting topic, and it could probably be a separate hour by itself. But in general, you have tools that enable different processes, but you also have a lot of habits and inertia. And in general, you have the technical problems and the technical tools, but there is a lot of social engineering that's required in order to adopt and leverage those tools most effectively. And quite often, this happens more than I'd like to admit, but I'll be in a conversation, and we're trying to help people use puppet. And there's something where, to me, it seems really obvious and really simple, and you say, well, all you have to do as an ops team is be able to communicate with the dev team because they're used to throwing these tar bowls over the wall. And what I want you to be able to do is talk to them about how they are going to configure this application and maybe potentially write the puppet code together that would configure that application, considering how the developers know how to use it and the ops guys are going to manage it.
"There's No Way We Can Talk to Our Dev Teams"
33:27And more often than I'd like, people will say, well, we can't do that. There's no way we can talk to our dev teams. And it's sad, but it's true. Well, I hear you loud and clear, and I would like to make a suggestion along the lines that you have stated at the beginning of your answer. You indicated that this is a fascinating topic, which is sufficiently substantive to require a full hour just for discussing of change, change management, and how it works or does not work within development, within deployment, and in various cultural contexts. Why don't we pick this topic to be the subject we discuss in our next podcast? It works for me. I think that that's a very interesting topic. And in some ways, it's the root of all – if you talk about Agile, and going back to what I said earlier about how people haven't adopted some of these practices,
Habits That Have to Die Hard
34:42I think that that's sort of the root of all these things, right? So you look at what Agile and engineering practices enable, and being able to take and TDD and use the tools that have evolved and are still evolving in the most effective way, it requires a lot of habits to kind of die hard. And that's a big problem from, you know, the top of the organization to the bottom. Yeah, it's the classic technology retirement problem, which, you know, sort of encapsulates the slowest, easiest way to solve that issue. But it's definitely not the desirable one. Well, I mean, if you're talking about TDD, then that's certainly true. But when you get to organizations where they have a different manager or a different vice president that's managing development versus engineering or ops, then it's even more complicated because it's not only the time that has to pass to kind of phase out these old things, but you actually have a separate tribe and a wall of confusion between you. And that might go all the way up to the top of the organization. And until you can figure out ways to sort of dissolve that and open up the lines of communication, then the tools themselves are never going to be utilized at their full potential.
Telling the Organization What IT Can Now Do
36:00Yeah, you have the issue of even if you can do your own internal culture change, you have to tell the rest of your organization how different new services you can provide because they're so used to the way things used to be and that being how they interact with IT. Like to the point of the financial thing, I mean, if IT is such a small cost, efficient or not, you know, for doing financials and banking, then suddenly giving them these new abilities that are more efficient and can introduce change faster, there's a lot of adapting that the business has to do as well to hook into that. Sure, I've discussed this with Israel in the past. You have, you know, you take and you transform the speed and the quality that a dev team can produce the software, and that has implications that ripple through marketing and sales. And unless you have, you know, the skills to kind of manage that cultural shift, then that can cause real problems. Yeah, well, you know, I think that's a good place to wrap up part one of the discussion here, then. And we've hit on some of the, like, little practices that people, you know, we've gone from the base level practices of things you could actually do and then kind of what that sort of enables and modes and everything. So unless you guys had anything else you wanted to weigh in on, we might as well close this part out.
Social Engineering Next Time
37:18So I guess we're talking about social engineering next time? That's right. Ways to get passwords. Nature versus nurture. I will drink to that and will lovingly dig into it. Always a pleasure. Until next time.
Machine transcription, lightly formatted. Chapter headings were written from the transcript; speakers are not identified, so nothing here is attributed.