Pragmatic 27: Military Software

Welcome to Pragmatic. Pragmatic is a weekly discussion show contemplating the practical application of technology. Exploring the real-world trade-offs, we look at how great ideas are transformed into products and services that can change our lives. Nothing is as simple as it seems. This episode is sponsored by LIFX. Visit lifex spelled L-I-F-X dot co slash pragmatic for more information and to take advantage of a special discount off their amazing LED smart bulbs exclusively for pragmatic listeners. I'm your host, John Chidjy, and I'm joined today by my guest host, Casey Liss. How you doing, Casey? - Well, how are you? - Very good, thank you very much. I wanted to get you on the show to talk about something that we've both had experience with. I suspect you may have had a little bit more experience with it, but that's about military software development. So it's something that I, when I worked for Boeing about in 2001 through to 2003, I worked on a project for the Australian Defence Forces called the HF Modernisation Project. And that was my first and only exposure to developing software for a military contract, which required all sorts of hoops to jump through and so on and so forth. But you've also had some experience in that. Can you tell me a little bit about your experience? Yeah. So it was actually about the same amount of time and it was a few years ago, but I worked for a wholly owned subsidiary of Northrop Grumman. This particular company did a lot with naval navigation and things of that nature. And so the stuff I worked on, obviously I need to be a little hand wavy about it, but it was navigation systems for both the Navy, the American Navy and some civilian folks as well. So for example, this company does the navigation system or did at the time, the navigation system for Royal Caribbean. And so, if you've ever been on a Royal Caribbean cruise and you got to your destination roughly on time and intact, then I'm going to claim responsibility for that, even though I think I wrote like two lines of code for that product. That still counts. Two lines, it's still two lines. Right. Cool. All right. Excellent. Well, one of the things that I think it's a good place to start is you don't just walk into a job and sit down and start programming for military software because you have to go through a vetting process or a screening process. And certainly, I did. And when I first signed up, it was because the company had military contracts and I was slated to work specifically on one, it was one of those things that if you didn't get your clearance, you're essentially told, "Well, thanks for coming. See you later." It was a minimum requirement. had to get it. So, yeah, you had to behave, I suppose. But if there's anything dodgy, I mean, if there's anything dodgy in your past, it could jeopardise your job. So, it was quite serious. So, when I submitted the application, it took them probably about six, four to six weeks, I think, to do the assessment. And, you know, I had to sit down and have an interview and fill in a bunch of forms, going back to, well, I don't know, some point just after I was conceived, if anyone Like, I mean, it was insane. It was pages and pages long. And they want to go back and get contact details of anyone you've associated with, particularly if you've been overseas is something I learned. And because I'd spent two years, two and a half years roughly in two separate stints in North America, I was flagged as a more interested- I don't want to say high risk, but I'll say more interesting or worthy of more closer examination or something, which is why one took longer to process apparently so I'm told. So did you guys do something similar? Yeah so at the time I needed to get a some modicum of security clearance and as far as I know it's not active anymore but certainly I had to go through a very similar thing and so I had to fill out a form which even then I believe was done online but nevertheless it was a form I had to fill out that just like you said went through my employment history to the beginning of time including like in high school when I just had, you know, silly summer jobs, my living history as in like a residence history forever, maybe, well, I think it was like 10 or 15 years or something like that, but I was fairly freshly out of what we call college, I believe you guys call university. And so I had, I had moved, you know, a couple of times because of that. And then my dad worked for IBM up until two days ago and when he retired. And so we had moved, um, pretty much every two years for most of my childhood. And so when you're, I don't know, I was like 23 at the time or something like that, 24. And when you're that old and you need to go back 10 years, I had to go through like 10 different addresses or something like that. Some of which, you know, you had to dig up from records that you weren't even sure that even your parents had anymore. And then of course, after that, you know, they, they tend to spend some time going and interviewing some of the people that you've listed as kind of witnesses that you are, that you are who you say you are. and you are someone who lived in that place at that time. And I actually never heard back from any of the people on my list, whether or not they got interviewed, but. Certainly I know the idea behind it was, and you kind of hinted at this was what, what is in Casey's past and what leverage could somebody else have upon him? So for the sake of, for the sake of discussion, if I had debt up to my eyeballs, I had to report that. And then that's risky because if I'm, if I'm really someone who carries a lot of debt and I get to the point that I'm freaking out about it, some foreign government could come in and say, here's a suitcase full of money and it'll get all your debt problems away. You just got to tell us the secret about what you're working on. And that's, that's risky for the government and that's not good. And so that's what the whole process was about. And I, I pretty much had to stay away from most of the, from most of the code base until I had my clearance. And there were certainly absolutely meetings that I could not participate in until my clearance came in. Absolutely. Yeah. And exactly the same in my case as well. I found myself excluded for that first month and a half, just, you know, reading over the same induction manual, basically, welcome to the company. And I'm like, oh, like, what am I going to do? Oh, I guess I'll read the induction manual again. It's only the fourth time. Anyway, so now I definitely know where the coffee is. But anyhow, the point is that I sometimes would hear- Because at the time we were still on an old analogue phone exchange where I was staying, was an old apartment building in Brisbane and it had an old analogue phone line. And if you've ever had an old analogue phone line, you can- You'll know the noises in the background. There's always a little bit of a faint hiss in the background and strange clicks, and sometimes you hear echoes and stuff, and like a digital line. Anyway, I could have swore that during that assessment period that I could have swore that I heard strange noises on my phone line. I just- This is what I'm telling myself, right, Casey? It's like they're listening to what I'm saying. I even joked at it with some people that I was talking about on the end. And I was like, you know, if they are, I really don't want to be too much of a smart ass about this, because what if I, you know, if I jokingly say, hey, I've planted a bomb and blah, it's like, no, that would be just dumb. I mean, I was old enough to not do something that stupid, but goodness me. Anyway. I hear you. In fact, just recently I was at, I was going to try to use the right terminology here. I was queuing at an airport security gate and they actually had a sign up, like a poster up that said in so many words, "Do not make jokes about bombs. We will not find it funny and we will take it very seriously." And I thought to myself, wow, okay, good to know. People need to be told these things, you see. Yeah, apparently. Damn me. Yeah, because there'll be some smartass at some point that'll say that, and then they'll be like in an interrogation room for the next five weeks. Anyhow, god dear. Okay, so once you get through that vetting process and they say, "Look, you're approved up to this level of classified information," then you can get on and do your job, which is great. But the thing is that I learned that there are so many little things about working in that environment that are different or very, very strict. So, I just wanted to go through a list of things that I thought were interesting and maybe you can add to to some of these, we'll see how we go. The first one that struck me is I'd worked in at Nortel previously and a few other companies had swipe card access systems, you know, nothing, yeah, everywhere's got these things, no big deal. But you know, you swipe a thing on the door, it releases a solenoid, the door sometimes auto magically opens, other times you got to push it. That's, oh, well, fine. Hey, that's okay, it's a few calories, right? Push the damn door open, no big deal. Point is that you swipe it, you hold the door open 'cause you're a nice guy, right? You're going to hold that door open for the next five people to come in. They're going to come right in and you're going to smile. They're going to say good morning. They're not showing their badges. They're not swiping in themselves. They're just walking right through that open door you opened for them. It's very nice of you. And when you want to walk out, there's an infrared detector. Sometimes there's a release button. You just push the button or it detects there's a body there. It automatically unlocks the door for you. Sometimes again, it magically opens. Other times you open it and out you walk. Yeah, well, when you're working in this military stuff that I was involved with, that doesn't cut it. You have to individually swipe in and swipe to get out again. So, you can't just swipe in and hold the door open without getting into a lot of trouble. And I did get into a lot of trouble because I picked up those bad habits from previous companies I'd worked for. Did you ever get in trouble for something like that? They call it tailgating. Yep, yep. They did call it tailgating where we were. And I never got in trouble for it. And I think in part that was because the company was only about a thousand people. the, the, the subsidiary that I worked for was only about a thousand people. And, you know, you at least recognized almost everyone else's faces, even if you've never spoken to them and don't know their names. And so everyone was very good about if you were to hold a door open for someone, everyone was very good about still bad, you know, hitting the little reader with their badge, just to make sure that you're counted or, or what have you, you know, so the audit trail is there that you just entered or exited the building. And I'm trying to remember if exiting required you to badge out. I think it did. Yeah, it's been a few years now, but certainly to your point, getting in absolutely did. And people would definitely give you a look or remind you kind of sternly politely if, if you forgot to badge in as you were as you as you know, somebody else is holding the door for you, you'd get a reminder, oh, I think you forgot to hit your badge. Yeah. And you know, they take it seriously. Oh, they took it very seriously. So it's interesting you brought up that thing that you knew the people that worked there or you knew their faces and one of the things when we went through our security induction which was designed to bring people up to a standard that they would expect for your secure behavior and it covered all sorts of things like this tailgating issue as well as locking your PC when you get up from your desk and just the usual housekeeping sorts of stuff. But on this particular issue they played out some scenarios and the scenario they played out was, well, just because you know that that person you've seen them around doesn't mean that they weren't let go. You don't know that they weren't let go yesterday and they no longer have access to the building. What if they're being led in to do malicious damage because they're emotionally upset from being let go? You know, what if these people were removed from the building because they breached the, you know, secrets, official secrets act or something and, and divulge classified information? I mean, you don't know that. So, unless they have their badge, unless they swipe in, and unless their face on the badge matches their face, you should contact someone with security immediately. And that's what we were told, and that's what we did. And I made the mistake once, I'd like to say. It was just once. And yeah, I pulled up in front of security for tailgating in behind someone. And they didn't seem to care, but someone else who was behind me did care and dobbed me in. And I'm like, "Well, that was nice, but I never made that mistake again." took it seriously. Yeah, and the funny thing is now Casey is that I go into a non-military environment, have done actually pretty much since 2003, and I'll swipe in and then I'll swipe out and I'll swipe, well actually you don't have to swipe out but I'd do anyway, and I swipe in even though someone else could be opening the door for me and I've had people say to me, you know, I'm holding the door, you don't have to swipe in and I'm like, sorry, bad habit or rather was it a good habit? I don't really know. I was just about to say - I didn't say that. - It's a habit, okay? So anyway, okay. So that's one of those little things that struck me. So anyway, the next one about security badges also though is their removal from view whenever you're outside the premises. And I made that mistake as I walking down the sidewalk on a lunch break, going to get, I don't know, whatever I was getting for lunch at that point. And just my luck, one of the security guys, from the company, happened to be walking just behind me, pulled me over to one side, rather roughly, I might add, and pointed out that my badge was showing. And it's like the rules were very strict. You know, you leave the building, you take the badge off, put it in your pocket and get it out of sight because that makes you a target for access to that building. Yeah. So, I mean, what are you doing? OK. I don't think- I don't remember having to do that. I don't debate that it's the right thing to do, but I don't remember them being particularly punchy about it. Although to be honest, more often than not, I just ate at my desk anyway. So, it wasn't really that exciting. In later years, after that, I had kids and was on a tighter budget and ended up eating at my desk since then. So, it's less of an issue these days, I'll admit, but it's a habit I got into and it's one of those things. Maybe I just got stuck with a really anally retentive security dude. That's also quite possible. But hey, anyway, he took it seriously, even if no one else did, but well, I did after that. Anyway. All right, cool. Another one about stairwells, and I think I talked about this briefly on a previous episode, I think it was episode number eight. I worked in a high-rise- well, actually, I worked in a bunch of different buildings when I was involved in the project, but there's a high-rise building. And in the high-rise building, there's this- there was a sort of unwritten rule whereby if you had to go more than two floors, it would be okay to use the lift. But if you didn't, if you're only going one floor or two floors, it was expected you use the stairwells. And, you know, I guess I had reasons for that. It's like, well, maybe it's an exercise thing or maybe it's a, we've only got four lifts and we need to be, I don't know, if energy efficient, I don't know, whatever. But that was just sort of like the unwritten rule. So, you know, you would get in the stairwells, you know, swipe in the stairwell, go to the next level, swipe out again. No big deal, right? Unfortunately, at five o'clock in the afternoon every day, at least at that point, God knows what it is now, the anti-intruder alarms would be set at five o'clock. You could swipe into the stairwells because that's a fire safety requirement, but you couldn't swipe out again. In other words, once you're in, you are stuck in them. Nice. Yeah, and I didn't know this. I've only been there a couple of months and anyhow bottom line is I'm like oh I just got to drop this down to level 10 or whatever it was and I go into the stairwell not thinking it's two or three minutes after five I'd normally gone by five hadn't come across this problem before and I went in there and yep there go the anti-intrusion alarms and they're these hundred and god knows what decibel in that ear piercing pitch that's designed to make you feel nausea and and disoriented I didn't feel disoriented exactly but geez I felt that nausea and I was like crippled up on the floor I was in there for a good few minutes before they let me out sure enough I opened the door to my favorite security guy with two other security guys behind him and I'm sort of like staggering out of this stairwell and I'm like I'm guessing the alarm got turned on at 5. Thanks for the memo guys. Yeah cheers so anyhow then they drew my attention to some leaflet that I'd hadn't been given and said, yeah, it says it clearly here. And I'm like, yeah, great. Thanks, guys. Anyway, suffice to say, didn't make that mistake again. Anyway, OK, so one of the other things was that if you were to breach too many of the safety, sorry, security rules after a while, then they threatened with revoking your clearance and you would then essentially therefore be sacked because without your clearance, you couldn't do your job. The Official Secrets Act applies for your entire life, so anything that you, well, whatever the equivalent is in the US, but it's based on the same system as the British system, whereby once you come across any information that is considered to be classified or need to know, you must maintain that secret for the entirety of your life. And therefore, if you leak any information at any point in that future, you can still be prosecuted, go to jail, that kind of thing. So, you know, obviously the rest of this episode, we're just going to be speaking in certain vagaries, but I think it's okay to talk about the different bits and pieces of the restrictions of working in that environment without being specific about exactly what we're working on. So, that's the goal anyway. So, if this is the last episode of, dear listener, if this is the last you hear of my voice, then perhaps you'll know what happened. But Casey should be safe because he's such a nice guy that no one would take him away or something. Yeah, hopefully. We'll see. Okay, right. Let me see. So, that was access requirements and so when it came to buildings. The other stuff was pretty straightforward. They had absolutely ridiculous password requirements and this is back in 2001. So, these days I know it's got to be X number of symbols. You got to have a mixture of uppercase and lowercase and numbers. You can't have repeated numbers or letters. It just get, you know, the rules for passwords these days are insane. are insane but even back then they were really strict and they had a forced rotation it was something like every four or six weeks I forget but it was very very regular and it was so annoying because you're forever forgetting your damn password and of course you couldn't write it down because you know how some people write it down on a bit of yellow sticky note or something well yeah if they catch you doing that well that's a big cross and that's a fail so don't ever even try that but yeah getting up and walking away from your computer and not locking the screen I got pulled up on that a few times thankfully though that was by my manager not by the security guy that was probably more serious but yeah control or delete walk away because yes we're developing in Windows right yeah okay no Max of course you are of course but I mean yeah you're you're a you know you're a dotnet guy so it's all good right yeah there you go see yeah Windows is your friend up to a point okay it's a it's okay all right um okay so beyond that beyond that I think it's we should probably talk a little bit about the levels of secret because everyone, I guess a lot of people know this, maybe they do, maybe they don't, but 'cause there's different levels of classified, right? - So, yeah, well, it's in the US, I'm gonna probably butcher the details, but my recollection of it was that there was classified, which is a pretty darn simple check for clearance. Like they don't really go that deep into your history. There was secret, which involved a more thorough check into your history. And then there's Top Secret, which involves putting on a polygraph and actually interviewing you and things of that nature. And then anything north of Top Secret, I'm sure there's several levels, but I don't know them offhand. Yeah, that's it. So, basically, there's been a bunch of different variations of this. And the funny thing is that I, something I learned when I was just brushing up on the details for this show is that back when I did it, Australia had a subtly different system. There's more or less a pseudo international standard which is derived from the British definitions originally. And it's the top four that are the most well known. So this classified, as you say, is referred to as either protected or restricted. And protected or restricted information would cause, by their definition, undesirable effects. Now, it goes into undesirable effects but, you know, there's a link in the show notes if you really want to read up into what that means. But if this is all, if the information is made public, so, you know, classified slash protected slash restricted, same kind of thing would result, would cause undesirable effects if it was made public. Confidential information would cause damage or be prejudicial to national security if it was made public. Secret would cause serious damage, so that's getting serious now, to national security if it was made public. And top secret would cause exceptionally grave damage to national security. So, that may or may not help. But yeah, and as you say, in order to get clearance at different levels, you need to go through ever increasing levels of scrutiny, including polygraphs and all that sort of other rubbish. And I say rubbish because, you know, you know, every time I hear polygraph, I just keep thinking of ways of beating polygraph tests, but never mind that. Not that I- And I'm neither confirming or denying what my clearance level was or what I went through specifically in that sort of regard to get it. But the bottom line is that all of those levels of secret mean nothing unless you have a need to know. And this is the thing that I didn't appreciate before I worked on the military project is the whole concept of need to know just because you've got clearance up to top secret ultra super high awesome level doesn't mean you just can walk in there and read every single top secret document that you want to feel like reading you have to have some kind of need to know you specifically need to know in order to carry out your job and I guess the funny thing for me was the decision about whether or not you actually have a specific need to know it's a little bit it can be a bit flimsy because it depends on the person. So someone who is a superior or who is higher up in the chain in the project you're working on, gets to make that decision, that choice. And it's sort of a bit strange to me 'cause I thought, well, what if he thinks what I might need to know is actually not what I need to know and there's actually something else that I might need to know that he doesn't think I need to know, you know? Yeah, it's very, it was very, very subjective. And I mean, generally, well, that's being a little unfair that this, it was pretty clear most of the time what I did or did not need to know. And but there were certainly occasions where it was subjective. But there were also some odd rules about it kind of going back to the earlier part of the conversation about odd oddities with the security. Yep. One of the things that I that I learned quickly was that unless you were actually boarding one of them, you were, none of us were ever supposed to know all three of the following facts about submarines. What submarine we're talking about, where it will be and when it will be there. So if, if say, for example, that there was a ship, a submarine called, well, no, they're boats, aren't they? There was some big divide. And I forget, I think submarines submarines or boats, the things above water or ships. Anyway, if one of the submarines, let's say the USS Dallas, because I love Hunt for October. So let's say the USS Dallas is going to be somewhere on the 4th of July. Then I can't know where that somewhere will be. Or alternatively, I know that there will be a sub in Newport News, Virginia on the 4th of July, but I can't know which sub that will be. And so, you would only ever be allowed to know two or three pieces of information. And I never actually got lucky enough to get a sub ride when I was working there. But if hypothetically, like some of my coworkers did, and they basically knew, "Okay, I'm going to Newport News on the 4th, and there will be a sub there. I have no idea which one." And then as they were getting on the boat, they would find out, "Oh, this is the USS Dallas." - Right. Okay, cool. Yeah, I didn't come across that specifically. I didn't have anything to do with the submarines to be honest. Mine was HF Mods. It's a good way of splitting it up because then one person doesn't have all the information required to actually know the specifics about what, where, when. When I was involved, I did a a little bit of software and I did a little bit of system work. So, systems integration. And the thing with systems is that you have to know a little bit about the fringes of the other systems that are connecting together, but the need to know was not always as clear because I didn't know what I didn't know and I had to rely on people that did know to tell me that I had a need to know in order to get access to what I needed to know. Right. If that... and I don't actually... I'm not... the funny thing is I'm not actually trying to be funny when I say that, that is actually accurate as to what the problem was. But anyway. All right. So I just want to pause this for a second and talk about our sponsor for this episode. So LIFX, spelled L-I-F-X, is a smart light bulb that gives you previously unheard of control of your lighting. Each bulb is Wi-Fi enabled and can give you light in whatever color of the rainbow you so desire. It's an energy efficient LED light bulb that you can control with your smartphone. With over 1000 lumens at your disposal it's incredibly bright but only consumes 18 watts of power at the maximum. Controlling the brightness, colour and a range of cool effects is really easy through the smartphone app and the LIFX smart bulb is made to last. It's ready for 27 years and that's averaging 4 hours a day. That's the equivalent of 40,000 hours. So you're probably going to move house before you need to change the light bulb again. The LIFX bulbs support both standard Edison screw and bayonet connectors and will work at all standard voltages around the world between 100 and 240 volts AC. It has a developer friendly SDK currently available for iOS, Android and Ruby which means that if you can think of a great way to control these bulbs you can go out and build it on whatever platform you like right now. I've been testing some of the demo bulbs and my kids went crazy, I put on the disco light effects and some strobing and they went absolutely crazy. I had a dance party in the main lounge room. It was just absolutely fantastic. Lifex bulbs are shipping today for only $99 US dollars with free shipping worldwide. Head on over to lifex.co/pragmatic to learn more and enter the coupon code pragmatic for 15% off the total price of your order. Thank you to LIFX for sponsoring Pragmatic. So I just want to talk about the IT infrastructure a little bit and I'm gonna be a little bit generic because I think it's probably better that I am. So first of all I want to talk about Tempest. Did you come across Tempest? No that doesn't ring any bells. Okay well Tempest is something that I came across. It's actually believe it or not an NSA code name so not even an Australia thing it was actually a North American thing United States thing I should say and what it does what it is is it refers to the spying on information that is being emanated so emanations from equipment and that could be emanations that are either electromagnetic ie radio or or magnetic or electric fields it could be visual or it could be sound or it could be vibration. Anything that emanates from equipment that you're using that has secure information on it. So the thing that you learn a little bit about Tempest is that not just any building can be used. So the thing is that there are restrictions as to how close you can be to windows, how close other buildings can be to your building. And some buildings require, you know, fitting with, you know, additional shielding and all sorts of other little requirements. Now I don't have the list of requirements and I'm not going to go through them, but that's just an idea of something that needs to be considered. You can't just set up shop wherever you feel like it and start working on a defense project. The whole building needs to be approved. So that whole Tempest thing is a very big deal with IT infrastructure. Now, beyond that, even that's not enough in some cases because well, let's face it visually, you've also got the ability of people to look in through the windows. And there's ways of cutting through reflective glass and so on. And there's methods and all sorts of things. So what you want to do is make sure that you also have rooms for the really highest level of security stuff. And these are rooms that are double, triple, heavy shielding, no windows, you know, completely isolated rooms where you can work on the highest level of information. And that sort of stuff is was something that I was never, I only heard about because I was never involved with. but some of the information I was told is essentially so sensitive that it's not even left in the PC. So in order to actually work on the information on a PC, what you would do is you would check out a hard drive and you would insert it into a special dock and that dock would allow the PC to function. You would work on what you had to work on and when you were finished, you would then check it back in and lock it back into a secure safe. And this is all like ultra, ultra, you needed to know definitely, and you had to have the highest level of clearance to get in there. And they were very careful what went in and out of that room. So you can't just go in there with your swipe card and do what you want. It's locked down very heavily. So the networks are split into two networks. And one of them I like to think of as the secure LAN, but they refer to it as the red LAN or the red network. And the other one was the corporate LAN, which is the so-called the black network. And that was just for general business and any non-classified information. So you're setting up a meeting and it was sort of like, oh yeah, meeting for wink, wink, nudge, nudge, we are all code names, these are my code name, but you know what I mean? Yeah, it's a meeting for blah in this room. Yeah, that's corporate land stuff. Whereas a secure land was of course, for anything that was classified up to a certain level. And if you wanted to get data in and out of that secure land there was a massive rigmarole you had to go through because they would lock down everything. They locked down the USB ports, they would lock down the Mac address. So the switches that were connected on the Redland, you know, they were locked to the Mac address. So that port on that ethernet switch specifically in that rack and that room on that floor could only ever connect to this ethernet card, you know, port number one of that ethernet card on that computer. And if it ever got connected in or disconnected something else, then an alarm would go off, which I discovered one day. You see, because- Where you go? Well, yeah, because, okay, it was perfectly innocent, of course. And that was- It was a simple mistake. I was moving desks and I moved my computers because that's just what you do, I suppose. And I was actually keeping the same- The move- I was keeping the same hardware, the same cables, same everything. But my cables, for whatever reason, were the same colour. They were supposed to be different colors, right? One for the black LAN, one for the red LAN, but no, no, no, mine were both blue. So, you know, unless you trace the cable, you lost track of which end was which. So all the Mac address ports had all been set up. It was all good to go. It had been unplugged the night before. I was, you know, moving it in, plugging in the next morning. All was hunky-dory, except I plugged them in the wrong way around. So my corporate LAN PC was plugged into the red LAN and vice versa. And I think it took about 30 seconds, maybe 45 before the security guy walked up to my desk, tapped me on my shoulder and asked me what I was doing. - Was it your same friend that you met outside on the way back from lunch? - As it happens, yes it was. - Funny how that is. - He really didn't like me. I just, he didn't like me. I think that's what it was. That's a shame. Anyhow, nevermind. So it was all perfectly innocent, but yes, there were alarms set up. Yes, they did find out, they were notified and they found me. So yeah, they take that seriously. So just as an aside, people that don't know what MAC address locking is real quick, just in case you don't, MAC stands for a Meteor Access Control and it's six groups of two hexadecimal digits and that's unique to every physical ethernet address. I think, you know, Wi-Fi as well. And, you know, Apple doing some cool thing with rotating MAC addresses randomly to stop prevent tracking in iOS 8 and that's all, you know, very cool, thumbs up, awesome. But so far as this goes, that would not work in this sort of an environment, obviously. that relies on the fact that MAC address is fixed. But anyway, so did you have any experiences like that or anything similar? - Not really, not with regard to networks. I know that certainly if not in the office, but on board vessels, that there were two different networks. There was a, there was the kind of dirty network, if you will, that you can run almost anything on. And then there was the kind of clean, if you will, classified information, things that are required for the ship to run properly, those sorts of networks. But generally speaking, during my day-to-day activities, I didn't really run into that very much. The one thing I will say, though, is that I was one of the first engineers, or developers, I should say, because we had other kinds of engineers. I was one of the first developers to get a laptop, which was a very weird thing. And this was in, what, 2006-ish, 2007, something like that. And it was very weird to have a laptop. Most of us had desktops. In fact, most of us had CRTs at the time, and this was late enough that CRTs were kind of going by the wayside. But we mostly had actually IBM mini towers, and that was our work computer. And one thing I do-- well, I mean, I miss a lot about that company. But one thing I miss very much is that because it was all government contracting, we couldn't work overtime without permission from the government. And so unlike the kind of consulting I do now where, you know, if you work overtime power to you there, you had to put your pencils down at 40 hours and get the crap out of there because we didn't want to get in trouble for overcharging the government. And so that was actually very refreshing because I never worked more than 40 hours a week except a couple of rare occasions. Yeah, that's an interesting situation. I haven't come across that before, not in this particular case. I guess it was the way perhaps the contract was set up. But in my case, no. You want to work extra hours, oh yeah, they're going to make you or let you or coerce you into doing it. Some people there would really burn the candle at both ends and they didn't mind. You only charge the same amount of time, of course, but you're going to be working those extra hours. Oh dear. Anyway, that's not exploitation at all. Anyhow, so ... It's terrible, but anyway. So, the next thing I just want to talk about is the red tape. And I don't know how much of this you came across, but one of the things and I've been out, I've been working now for all, pretty well getting on 20 years, and it was the single most amount of red tape of any job I've ever had to work in. And- Yep. Yeah, you know, it's like if you wanted to, you know, release your build of what you're working on. There was all of these forms you had to fill in and they had to be signed off and so on. When you are actually doing all of this work, you had to get all your interfaces set up, right? So these interface specifications that had to be, they were just so detailed. And the reason I suppose in that case was that each of the individual teams didn't know all the details about all the other sub teams were doing. So if your interface specs between your different sub teams weren't actually detailed enough, then I guess you could get caught out and you might have something where, this message doesn't actually respond with the right information or whatever. So they spent all this time and that required all this extra rigor and all this red tape and it was frustrating as heck. Did you go through something similar? - Oh yeah. You have to understand that when I went to this company, this is my second job out of college, out of university. And the prior one was working on slot machines for the Oklahoma Native American casino market. Wow. And the group I worked with- So, just to interrupt you for a second, you got to listen to the last episode I just did about slot machines then. I saw that that was one of the things you talked about, and it immediately piqued my interest. Sorry to interrupt, sorry, keep going. No, no, not at all. So, I went from that, which was a bunch of old game developers, not old as in age, but like, you know, prior prior experience was doing real video game development. Um, at some point their company got bought up by EA and then the EA shut them down like they do to everyone. And so it was a bunch of these generally speaking, uh, guys that were in their mid to late thirties who really generally speaking, didn't have wives or girlfriends or anything like that, and they worked constantly and it was, it was an adventure, but they were extremely knowledgeable, extremely, extremely knowledgeable and very casual about things because the shop was all of 20 people or something like that. So then I go from that to, to this big government contractor where I couldn't check in a piece of code unless I had an issue request to associate with it. So if I see a typo that's on the user interface, I can't just go in there and fix it real quick. I've got to raise a bug. It has to go through the change review board or whatever we called it. They have to approve it. It has to be scheduled, prioritized and approved. And then at that point I can go in and make that change. And I left the company I'm speaking of mostly because we were moving to where we live now. But I think I don't, I don't think I would have lasted too much longer anyway, because of all the red tape. We did code reviews for every line of code that ever got checked in, which at first I hated in, in the end, I actually ended up liking it. But it was also, it was kind of like handcuffs because anytime I wanted to get anything done, even fixing a typo, it still had to go through code review. And you had to set up a coworker and a superior. You had to get the diffs squared away. They had to be posted on a shared drive so they can look at them in advance. Then these people had to look at them in advance and figure out what they wanted to complain about, if anything. And my code when I was writing non-trivial things got demonstrably better because of these code reviews. So again, I don't really besmirch the idea, but nevertheless, there were times when all I wanted to do was change a darn typo. And it was still hours upon hours of work between the reporting of the bug, the change review board, the opening of the bug, fixing of the bug, checking in of the bug, code review of the bug, and all of this is to change, I don't know, favorite to not have a you in it or something like that. You know, I mean, it was the most ridiculous thing in the world. But it was for a reason. That's what you think. Yeah, man, you just put that on the table. So, hey. But yeah, hey, exactly right. And it was the same for me. And I'm fortunate, I say fortunate, I guess I was involved in a very small part of a set of drivers essentially for a small piece of equipment involved in a particular subsystem that Charo may name us. The point is that I was just, I was not dealing with this on a daily basis, but I worked in a team of engineers, developers that were working on with this stuff on a daily basis and you never heard the end of it. And although I only went through it a handful of times, what you just described is very, very similar to what I went through also on the systems engineering side, because I was writing a whole bunch bunch of documents about different interfaces and requirements and such and it was the same kind of issue. I needed to get signatures from seven department heads in order to get the changes incorporated into the document by the document control team and this is sort of when I had that the epiphany is that working with the military is like working with a government department essentially and it comes along with all of that red tape that comes with it. It's It's not just about classified information, secret, secure information. It's not just about that. It's just process driven to the nth degree. And just when you thought it was not possible to add more process and more red tape, they added it. It's just unbelievable to me. Yeah, absolutely. And I think that there are several reasons that that happens. I think the biggest and most obvious reason is it's fixing everything by process. time anything ever goes wrong, well, now there's a procedure to prevent that. And it was more deliberate and less organic. And as I've gotten a little bit older, I happen to believe that having just a more organic error handling approach where you learn from your mistakes, but you don't necessarily add process because of it, I think that makes a little more sense, but anyway, so there's a lot about process and a lot about fixing or preventing future bugs and issues. But I think a lot of it is also that the government is a big entity, or at least here it is, and it employs a lot of people. And the easiest way to employ a lot of people is to have a lot of checking and balancing going on all over the place from the top, all the way to the bottom. And I think some of it, not to say that it was necessarily deliberately written for that purpose, unlike where I believe that a lot of the process is deliberately written to prevent some issue from happening a second time. But I think the kind of, maybe I don't know if subversive is the word I'm looking for, but it's the best one I can come up with. But the subversive purpose of it, of all this process was just to keep that big an organization that big. Because to bring the process back and lean it down means somebody's losing their job because they just don't need to have all these checks and balances anymore. I mean, I'm with you on that, mate. I mean, seriously, I do wonder how much process is there for process sake. I don't, and this is going to sound a little bit odd, I guess, maybe coming from me specifically, but I guess I see process as being something that you should try and keep at high level so that people are on the same path. But if it has to be so specific and so detailed and have so many other requirements, then process becomes for its own sake. And it doesn't actually add any appreciable value. It actually starts to subtract value. striking that balance is always going to be difficult. But honestly, I honestly think there's another angle as well to it, is that you create process in a lot of cases to spread accountability. - Oh, that's a very good point. - Yeah. So, yes, like someone will say, "I'm concerned about this because I'm not an expert in this particular thing. So, I'm going to put it out for a review and I'm going to spread this accountability across multiple different people. Okay, so let's go and do that. Now I'm going to say, okay, you know what? I'm doing this a lot of the time. So what I'm going to do is, I'm now going to create a process. This document in this topic must be reviewed by a minimum of these number of people. Great. Now I'm covered. And it's like, okay, I've done it. And there's an earlier episode on design reviews and name only. And it's the same kind of idea as well. So if you want to go back to listen to that episode again, if you want that particular episode, that I went through this, and just to touch on it really quickly again, is that just because you give someone something to review doesn't mean they're actually gonna effectively review it, because people have other things that they need to do, like, well, I don't know, getting their own documents reviewed, actually being productive, that's another thing they might wanna do. And you don't always have time to go and do a thorough review of other people's stuff. So it comes down to, I now am waiting on signatures, and that's another thing they love, is damn signatures and everything. It's got to be wet ink too. Did not this digital signature stuff. No, no, no. (laughing) God. Yeah, anyway, that's another whole episode. Yeah, I should do one on that. Wet ink versus digital signatures. Goodness me. Anyway. So yeah, it just, it reaches that point where if you spread accountability wide enough, then no one individual can be to blame. So, you know, I missed this on this document. We went through and accidentally something sank or, you know, exploded or whatever. And then they do a big review and they say, "Oh, well, it went out to review." know multiple people would have blamed we're gonna sack all of them well I don't know maybe not maybe we should fine all of them no I don't think so that is so cynical of me well no but I think there's some some modicum of truth to it if not a lot of truth to it because you know again part of the reason the government entity is so big is just like you said to spread that accountability so no one head is going to roll if something goes pretty badly or at least mildly badly now maybe there'll be one singular human that takes the blame if the submarine runs aground. But in normal circumstances where something inconvenient happens, well, just the whole department as a team is given a stern tongue lashing and that's about it. - Yeah, that's it. Yes, well, honestly, yeah, I don't know what the answer is because when I actually left Boeing, one of the big reasons was was the red tape. And, you know, because it just, it just drove me out the wall because I was getting feedback on the grammar in my sentences. And this is the thing that used to really irritate the heck out of me. And I'm trying so hard not to swear right now because it was really, really annoying. I'm writing a sentence, okay. And there was this one particular guy, department head, who was, who saw himself as a grammar Nazi, but in the end, he was not fully qualified to be a Grammar Nazi. So depending on the phase of the moon, the color of the moon or the direction of the wind, he would say, "Oh no, this is the right way it should be worded." And you're like, "Okay, I'll word it this way just for you." And you would go and you'd do that update. But of course that would mean you have to go and get all the departments heads to review that change and get their signatures again. "Okay, no worries. There goes another week of my life." Because you had to have a five working day minimum waiting period to give them opportunity to review it. Great. So, you go back again the following week, you know what? He changed it back to how I originally had it. And I just went down to his desk, I put the two in front of him, both with his signature against the markup and I said, "Pick one now!" And I'm like 22 or something. I was... Yeah. So, you know, that may have sounded aggressive, but believe me, it was a lot more aggressive when I was younger. And I don't think he was my friend after that. I certainly wasn't on his Christmas list. But the point was that that was a sort of frustration that drove me to leave because it's it's just it was these people Were not adding value. They were just picking that my the way I structure a sentence does not change the intent of The sentence of the detail of the design that I'm doing. So why are we reviewing this? Why are you reviewing this? What value are you adding? Come on So anyway And that's when the process is just for the sake of process and I just had to go and I and actually It was really good for me actually, because when I left, I then went to work for a company called MPI Engineering, and that's when I got back into control systems, and it's more or less been the sandbox that I've been playing in ever since. It's more on the software side, more in controls, and out in the cutting face, making machinery work, and that's, you know, very little red tape. So, yeah, much better than that. It's funny because I, being a consultant, I occasionally will work with, say for example, a really big financial firm, and I see a lot of the same issues there, a lot of the same red tape, and additionally, a lot of the middle management glut. And I did a project at, about a year or two ago, somewhere local, and every meeting we had, had what I would consider middle managers in it. And usually like four or five of them. And I think that in most cases, most of these middle managers deep down inside knew they were expendable and that they were one of 15 people just like themselves. And I think that a lot of times what they would do is they would pipe up and make a stink about the silliest things. And I genuinely believe the reason they did this was because they wanted to show everyone else around them, they're worth something. And so they would just pipe up at, let's say about a grammar issue and have a fit about this grammar issue. And because they think in their heads, well, everyone saw me make that smart, you know, make that smart catch on that grammar problem. They can't get rid of me. They'll have to get rid of Joe or Susie instead. And this isn't a place that was like living on cuts. So it's not like there was a pending, um, layoff or anything like that. It's just that I think that they deep down inside knew that they were kind of redundant. And so, they did everything they could to seem not redundant. And oh my goodness, it was very, very challenging. Even as a consultant where I knew I was getting out as soon as the project was done, it was still very challenging. Yeah, I did. I've done a few years as a consultant and during that time, that was something it was nice to be on the outside of. But the funny thing is when I was working for that consultant for two years there I was actually back in the cutting face doing programming again. That's one of the things where you never admit that you actually know how to do something because then they'll make you do that something that you know. So it's like oh yeah experience with with SciTech SCADA oh great you can fix up this enormous drama we have. Yeah it's like I came here to do work in in this area and now I'm back to okay yeah because you know the bottom line you know you want that paycheck at the end of the day so you you shrug your shoulders like here we go again roll the eyes and you just get typing but anyway yeah but it is it is terrible that whole minimal management bloat and that's another topic all unto itself but the the thing is i do wonder though people listening to this that haven't actually had the um i'll say pleasure quite a pleasure of working in on military development is some people look on it with a sense of um i don't know it's like it has a sort of an allure to it. It's like, "Oh cool, I'm working on a stealth airplane or something, or I'm working on some submarine or something for a submarine, something for a plane that's really, really cool or ammunition or whatever floats your boat." And it's like, "Oh, this is so cool." Once you realize that, and you get on the inside of it and you've gone through all the rigmarole to get clearance and everything, and you realize, A, you can't actually tell anyone about it. B, there's so much red tape you have to go through and so much BS you have to deal with on a day-to-day basis, it really can be quite frustrating. You get to the end of it, I'm sure a lot of people get disillusioned, but the funny thing is they still seem to have a lot of people that stay in that environment. So I came to the conclusion that it's an environment that works for certain people. I was not one of those people. It sounds like you weren't probably either. But if you're ever interested in doing that sort of thing, hopefully, if nothing else, episode has given you an opportunity to kind of get a handle on what you could expect and whether it's your cup of tea or not, or cup of coffee or cup of Leucazade or whatever the heck you drink, you know, Mountain Dew, possibly, I don't know, maybe not. Yeah, but there's certainly some good things that came of my experience for sure. And one example is everything that was done and that happened was deliberate. many cases, I think it was taken way too far, like we just discussed, but it was deliberate. And when a lot of developers oftentimes are kind of shoot from the hip and just, ah, screw it. Well, I'll write some code. I'm sure it'll figure itself out. And that's not at all going to cut it when you're working on things for an aircraft carrier or submarine or a stealth bomber or what have you. And so they were very deliberate, which was something, which is a skill that I think I've carried with me, or certainly a state of mind I've carried with me ever since. And the other thing that this company was, for better or worse, they were extremely good at reproducible results. And so if you look at on my podcast, ATP, in episode 55, when we talked about software methodologies, finally, we talked a lot about how Agile and Scrum is a really good way of learning from the past and trying to handle something that is kind of inherently out of control. Well, once you get to this sort of an environment, a big government environment, the company I worked for was CMMI level three, I believe, which I forget. I don't even remember what CMMI stands for, but what it basically says is how mature is your process? And at a level three, I believe It said something along the lines of when you estimate something's going to take a thousand hours, 80% of the time, it's going to take within 5% of a thousand hours. And again, I'm kind of getting hand wavy with the details because I don't recall the specifics, but that's the idea. And so it was very deliberate and it was very reproducible. And that's something that I think all software developers should aspire to be is both deliberate and be able to reproducibly estimate and also execute on projects. I think that a lot of the red tape, just like you were saying, John, I think it was overkill. I think it was ridiculous, but there's certainly a happy side. There's a yin to that yang, if you will. Well, I'm glad you actually brought that up because I guess I did kind of paint that as being perhaps less than an optimal experience and perhaps you should have different expectations. But the bottom line is you're right, absolutely there were positives. And one of the things that I did take away from it is the thoroughness with the documentation. And that is something that I've tried to carry with me since. Again, I don't always succeed. I'm human. That's fine. And I get affected by bosses screaming at me at times saying, "Get the damn thing out the door." Yeah, it happens. But, you know, it's something that I am far more thorough than I was as a direct result of that working on that project and working in that environment. environment. You also mentioned the whole code review thing and that's something else as well is that we also did code review and in some cases it was line by line and I know that my drivers had the once over and it was frustrating but it was also enlightening at the same time because you get different people's perspectives. I mean just because this is the way you're going to do a nested if statement or whatever else, you're going to have a switch statement or whatever the heck you're doing so I was programming in C and it was you know whatever whatever whatever you know someone else's approach to it and I'll say well here are the reasons why I would suggest the following and you would learn something from that and you would go away and you it would make you a better programmer because the thing is if you don't do line by line reviews of code that stuff just doesn't come up people will just tend to be very you know hand wavy and say "Oh yeah, I just didn't like the way you wrote this." And they tend to be very vague. Whereas if you're on a line-by-line code review, they have to be specific. Look, what specifically is wrong about the way that I've structured this or the way I've defined this or the way that I've laid this out? What specifically is the issue? And I found that to be valuable as well. And honestly, I think that more places should do detailed code reviews. But if you're gonna do them, you gotta have the right mix of people. And again, that's something that I discussed in a previous episode, but in any case, yeah, it wasn't all bad. You're quite right. And there are good lessons to be learned from that. And predicting time is always difficult. And that's something that I'm eternally working on. And I hope one day to master, but I fear perhaps it is an impossible thing to master, but certainly there's still room for improvement. So I'm going to go with that. And I mean, if I could get my estimates within, what was it? 80%, let's say, then, geez, I'd be happy with that. I really would, 'cause seriously. - Me too. - Yeah, geez, it's so hard. But 'cause you have people change and deliverables change and different project pressures change. And you just- - I don't know, if you're anything like me, I always think I'm much better at what I do than I am. And so I'll be like, "Oh yeah, that'll take me 40 hours." And then inevitably it takes anywhere between 60 and 80. And so it was not too long after I started developing, doing this for a living, that I just started multiplying whatever my internal estimate was by either a factor of one and a half to two, to give, and that would be my reported estimate. And so that 40 hour estimate, I think to myself, yeah, I can do that in about a week. Well, then I'll tell my boss or coworker or whoever, yeah, that's gonna take me about a week and a half to two weeks. And more often than not, I actually end up right that way by almost doubling what I think it should take. - Yeah, the old rule of thumb I was told was double it and add a bit. And it's generally good advice. But I'll tell you what, never, ever, ever tell anyone that that's what you do. Because I made a mistake once of mentioning it to one of my engineering colleagues, not, I will note, not the project planner, not the project manager. And, you know, Mr. Loose Lips Sinks Ships goes and says, oh, hey, did you know that John does this? There's time estimates. And I'm like, burying my face in my hands. And I'm like, you jerk, how can you do this to me? So, of course, now he starts deconstructing all of my schedule estimates. And I said, you see what you've done to me? And he shrugged like it was no big deal. And then for the rest of the time I was there anyway. Yeah, it's tough. It's over. Especially, especially if you tell someone that's not a developer. I got made the mistake of saying to a project manager, you'll be thinking it through out loud. Well, I think that'll take about 40 hours. - Yeah, it'll probably be about two weeks. And they'll be like, "What? "No, no, no, no, no. "You just said about 40 hours." "Well, yeah, but I'm always wrong whenever I say that. "So I always basically double it." "All right, so 40 hours." "No, you don't understand. "It should be double that." "Okay, fine, fine, fine, fine. "I'll give you 45, maybe 50." "No, it should be double." "Okay, 60, but that's as high as I'm gonna go." - Oh, the negotiation. The negotiation, oh, it's so infuriating. 'Cause it's like, I need five days to do this thing. 'Cause of course I'm careful. We'll keep it as an inner monologue, right? Okay. So, I need five days and it's like Project Magic says, really need it done in two. And I'm like, okay, so let's just play back what's just happened here, shall we? Okay. You asked me how long it's going to take. I told you honestly how long I thought it would take. You're now coming back to me telling me I can only have two days to do it. Well, here's the thing. Next time, don't bother asking me. Okay, because you're just going to put down two days and I'm going to be screwed either way. Thanks. I see how this works. Oh, it's the worst. And I'm totally derailing us now. And so you'll just fix it in post. But just the other day, I was having a marathon meeting at work. And we were doing sprint planning where we estimate how long each user story is going to take. And then one of the things we also come up with is what do we think, or what will what one of the things we were told to come up with is what we think our velocity will be for that sprint. So that's to say that if each work item, each user story is, you know, so many points, how many points of effort do we think will complete? And so the developers in the room were looking at the project manager saying, well, how many did we do in the last couple of sprints? Well, the fact of the matter was we weren't going as quick as we wanted, and it was starting to look a little bad for the project managers to have this conversation. So they were like, well, no, no, no, we're going to do better than that. And I'm thinking to myself, the whole point in agile, The point of Agile, in my personal opinion, is to look at past performance as an indicator for future performance. Yes. And so, we know that, and I'm going to make the numbers up, we know we've done 10 points for the last two sprints. And you're telling me you think we're going to do 30 just by pure magic this time? Okay. Yeah, that's it. Oh, it's the worst. I know. And project managers that have never been in the thick of actual software development are the worst of the worst. So, you know, that is, goodness me. I hear you, mate. I'm sorry, this got negative. Let's end on a positive note. I'm not sure what that positive note is yet, but let's end on a positive note. Positive note. Okay, well, just to do a quick recap then, there are good things about working in a military-based software development environment. It will teach you a lot more about thoroughness and consistency. And there are downsides, but because we're focusing on the positive, if you want to have listen to the downsides, you'll have to go back about 10 minutes where we talked about the down. Does that work? Yeah, something like that. Well, it actually so here's an example of something that was good. One of the things that I got to do as part of my job was I had to babysit a deployment and that involved for the particular stuff I was working on going on a destroyer for an overnight cruise. And so I went I went down to one of the ports on the eastern seaboard got on this I I think it was a destroyer. I'm not, despite having worked at this company for a couple of years, I'm still not good. - Did it destroy anything? - No, not while I was there. - Well, then it's not a destroyer. It doesn't destroy anything when you're there. Anyway, sorry. - Yeah, no, I'm with you. But no, either way, I got to go on this ship and spend overnight on the ship. And it was doing like some high performance turns and like high speed runs and stuff. And it was extremely cool for 24 hours. Much more than that, I think I would have been miserable. But for those 24 hours, it was freaking awesome. And so that was something that, I mean, what job do you get where, other than being in the military, where you as a civilian can go onto a United States or Australian Navy ship and go for a spin, just for funsies, 'cause that's kind of what it amounted to. - Yeah, it's a very good point. And on the project that I was working on, it was spread over multiple locations, spread around Australia. and I had the opportunity to go to two different locations, undisclosed locations, and see different parts of Australia that I previously hadn't seen. And one of those areas I haven't even been back to since. Absolutely stunningly beautiful remote part of the world. And if not for my involvement in that project, I never would have been exposed to that. And it was quite an experience. And I thoroughly enjoyed that as well. So certainly the opportunity to see things that normal civilians don't see is kind of cool. I'll also agree with that. And that's actually probably the best point to end on, I think. (laughs) - See, we got there. - We got there, fantastic. Okay, well, if you wanna talk more about this, you can reach me on Twitter @johnchidjie and check out my writing at techdistortion.com. If you'd like to send any feedback, please use the feedback form on the website. And that's where you also find the show notes for the episode under podcasts pragmatic. And if people wanted to get in touch with you, Casey, how would they do that? Sure. Well, the easiest way is probably on Twitter. My handle is @CaseyLiss, C-A-S-E-Y-L-I-S-S. I also occasionally write for my website, which is [email protected]. And then you can catch me on my podcast with friends, the Accidental Tech Podcast, which is at ATP.fm. Fantastic. Cool. I'd also personally like to thank LIFX for sponsoring this episode of Pragmatic. If you're looking for a great LED bulb that's energy efficient, remotely colorful and just plain fun to use. Remember specifically visit this URL lifex.co/pragmatic and use the coupon code pragmatic for 15% off the total price of your order. So thanks again for listening everyone and thank you Casey for coming on the show. Thanks for having me on. I had a good time. Cool, me too. (upbeat music) (upbeat music) (upbeat music) (upbeat music) (upbeat music) (upbeat music) (upbeat music) (upbeat music) (upbeat music) (upbeat music) (upbeat music) (upbeat music) (upbeat music) (upbeat music) (upbeat music) [Music] [BLANK_AUDIO]