The Circle of Software (Ep. 27)

Episode 14 · 2016-07-24 · 49:28 · SRT · archive.org · all Tanzu Talk

So, we got a couple of crazy conventions going on. I'm looking forward to the one that's rolling out this week. But I was thinking, or rather you were, you were thinking, like, it'd be nice to, like, think of some nice things that are going on in these apparently apocalyptic times that we have as being portrayed. And, you know, there's a couple of, like, news items, I think, that we'll go over that are related to it. But I think there's a, and I was actually visiting with someone last week, just a regular, I don't know, Fortune 500 type company. And I see this over and over again that there's, I think maybe there's, like, a five or ten year lag on, like, exciting new technology sort of, like, getting sucked up by normal companies that affect us all that we all use. And they're all, like, looking to rewrite their software and make better software. So, that's, like, a very small thing to be cheery about. But I'm looking forward to all the software we deal with from companies and governments being much improved and sort of modernized, if you will. At least having, like, a mobile interface that's sane. Like, I was just, I'm going on a flight later today. And, you know, one of the things I take for granted now, I fly in American Airlines, is, like, you can just basically, like, check in on your phone and, like, get a little mobile thing that integrates with the wallet on your iPhone. And it all, like, it all works. It's kind of crazy. And it even, like, I've noticed they've added something that tells you, like, the time you should leave to go to the airport. So, there's, like, clearly someone's paying attention to, like, what would make Coté's lives better? Like, that's, which is nice. It's, things are panning out. On a whiteboard somewhere. Yeah, I mean, we can, you know, feel like the end times are near. But at the same time, it's easy to take a step back. And, like you said, even just travel, ignore the TSA part, you know, from a technology perspective. That's right. That, you know, when I actually have to get a printed ticket, you know, I just, it's shocking that now I can just have a little barcode. And I can change my seats. And those little luxuries are nicer.

Even just, you know, I was thinking about this morning. I mean, you and I are sitting here talking on a podcast separated by 1,500 lonely miles, at least. And that, you know, a drop of a hat, you and I can talk to anybody around the world with virtually no lag and almost no cost. Like, that is insane if you go back even 15, 20 years. So, a lot of crazy, awesome stuff in tech that's empowering. And the world itself is actually a pretty awesome place, despite occasional blips of madness. Yeah, there's a largesse of productivity available if you can snatch it up and figure out what to do with it, which is it. Like, I was in Toronto last week. And it's easy to forget that, like, you've got to go over the border. And in the Toronto airport, it's really weird. Like, they have, well, I shouldn't say, it's not weird, bad. It's just out of the ordinary. They have American Border Patrol in the Toronto airport. So, they have this whole other section of the airport that if you're flying to America, I was going to say back, but maybe it's to America. Then, like, you go through Border Patrol. And then when you get, you know, like, where I was going to Dallas, like, there's no, you don't have to go through that big glass hallway to the Border Patrol people. And, you know, as, you know, I have a border entry thing. So, you just go up to this kiosk and it, like, scans your passport and then your fingers and takes a picture of you, which is always annoying because I always forget to look up because I always want the best picture possible. And then you just pass by the, you know, the fully, like, crew cut, tattooed out guy who looks like he just rolled out of the army and he just waves you on and takes your little ticket. And then also, another thing I noticed, the Canadian Border Patrol, the most stylish Border Patrol you will ever see. They all have, like, those Macklemore haircuts, you know, where you, like, shave the sides and you've got, like, the styled thing on top. They are some stylin' Border Patrol folks. That is a pretty bold claim, Coté, to make. And I suspect that we're going to have some feedback and I would appreciate on the Twitters to, if you think that is the most stylish. I've always been impressed with Europeans who make me feel worse about myself, who all seem to actually be good at their jobs and look the part.

Now, that might be, you know, like, a nice, well-put beret. That can always, that's a good look with a big assault rifle, like, hanging out underneath you. But I think, let me contextualize, of all the Border Patrol people I've seen, the Canadian ones looked like the hippest and most welcoming. They were just, like, they were doing a good job, like, welcoming people to Canada. Another fun fact about Canada is there's only, like, 32 million people in Canada, which is kind of crazy. Like, there's more people in California and I think Texas, where I live, has, like, about 26 million people and you've got, like, 330 or so million in all of America. I looked this up because I was driving from the airport with yet another exciting technology, you know, Uber, depending on your position, how exciting that is. But it was pretty nice just to, like, not have to wait in line and just go, it's always great. And now they email your receipts to concur, which is also handy. Anyways, he was telling me that he used to drive a truck cross-country and he drove across Canada and it's just, like, empty. There's just nothing there. Which he was saying, it's such a big, big country and not that many people. So you look it up and sure enough, not a lot of people in Canada, which is interesting. I don't know what you do with that, but they get a lot of land. I guess much of it is frozen, but it's a big old area up there. Sure is. We love our Canadians. Yeah. And they put gravy on waffle fries and other fries. I don't know what's not to like. A lot of good things in that sentence. Indeed. Well, going just a little bit further south than Canada, I noticed, and you noticed this also, that Amazon bought this little company, Cloud9, that has a cloud-based IDE. And it was making me remember, I think, at the tail end of when I was an analyst at Redmonk, there was, like, this trend of in-browser IDEs. And I think the Eclipse Foundation, like, was working on a project and there were a few other things. And who else? It was another company. I forget what they were called. Yeah, you had a, yeah, you've got Code Envy, you've got Cloud9, yeah, you've got an Eclipse J, this kind of, you know, open source thing that's recently come out.

Yeah, it seemed super hot a few years ago, and now everyone, I think, has figured out their right play in that space. Yeah, I mean, it is, I think a little back in the past, back when I was looking at it, it seemed kind of clunky, but I can see that nowadays it would actually be just fine. And I like, you know, one of the things I remember when I was talking with the Code Envy people that was interesting is, it's kind of a little shade of, like, the pitch for virtual desktops or whatever. But there are, there's interesting things that happen when everything's on the server side, as far as managing the desktop and the total compute that you have available. So, I don't know, I haven't looked into that space a lot recently, but it's, as my mother would say, interesting. It seems like there's a lot going on. Have you looked at IDE-based, like, browser-based IDE things recently? What's your impression of it? I mean, it's a smart buy for Amazon, because as you can imagine, there's very, there's fewer and fewer parts of the stack that they don't own. So, if they can also make the development experience something they own, like, hey, run the browser here, and hey, guess what? Developing Lambda functions now is super crazy easy, because now it's all in our provided IDE, or what have you. You can imagine that they're trying to even simplify those people who don't have big heavyweight desktops, or the compute power to, you know, do continuous integration builds with 14 different services at the same time. That's actually where CodeEnvy pivoted, because instead of being a cloud-based IDE, they're focused more on portable desktop environments or development environments. So, get this containerized dev environment where you can go set off integration tests, and they just go spin up containers and return results and collaborate with other people. As you mentioned, this was kind of a clunky space for a little while, because it always felt like it was just an inferior version of a decent desktop IDE. And so, I think many of them have evolved now with more responsive UIs, and these other functions to do more, take advantage of server-side processing, still doesn't always solve the problem of, heck, how do I reference a local dependency? Or, how do I integrate with on-prem systems when this thing is elsewhere?

So, there can be challenges, but, you know, for Amazon, it's probably a good buy. You know, virtual desktops, I think people love and hate them. At the same time, you still like having more than just a dumb machine. But you can tell there's a lot of benefit in this space, especially as we have more of these cloud-based dev platforms. They're now actually having the IDE close to it. It could be a cool way to quickly bang out a boot app or a Lambda function or other things when it's all kind of integrated, not required integrated, but comfortably integrated. Yeah, that is interesting. Like, I've noticed, I mean, it's obviously a, whatever logic fallacy is, you've got a bum sample set. But I've noticed in talking with my friends who are still coders, and definitely when I look at our platform architects and other people demoing, that very few, sometimes people use IntelliJ for demoing. Like, someone like a Josh Long uses that. But people use a wide variety of non-traditional IDEs, whether it's something like Atom from GitHub or other text editors. And it sort of makes you think that all that horsepower you traditionally would think you need for an IDE maybe isn't always needed so much, which, you know, gets to another thing. Like, I'm always waiting for the return of, like, waiting. Like, I'm sitting on my thumbs. But I'm always curious about if the idea of rapid application development, or RAD, as I like to say it, will come back. And to your point, right, like, if you have, like, so-called serverless programming and all these things where you're sort of, like, you're not a lot closer, but you're close to the equivalent of Excel macros versus, like, full-on application coding. Like, it does, it is interesting to think about, you know, if you just sort of right-click here to, like, program something, and then because the backend is cognizant of, like, all these enterprise needs, maybe it does do all this, like, enterprise tracking, so it's not, like, crazy out-of-band stuff. But I don't know. It'd be interesting if someone logs into an application, and I guess Salesforce is a little bit like this.

Someone logs into an application, and if they have the right rights and everything, they can actually, like, program it. They can do the old, we can finally close the loop on the idea of, on a wiki, you can always just click edit and change it and do something at the programming, in the programming world. No, I think you're right. That's an interesting thing. And you touch on an interesting point, is that as well, cloud gets sold as, hey, the benefit is the elasticity when you have bursty, unpredictable workloads. Doesn't that describe most client-side development? Like, when I'm building apps on my machine, most of the time CPU is doing nothing, I build and compile my app, and everything explodes for a few seconds. Like, it's the definition of, I just need compute temporarily. So, you know, marrying these things in the cloud without sacrificing connectivity or some of the performance enhancements, or frankly, many of these IDEs are super functional. I use probably 4% of a decent IDE nowadays because I just use it to basically build stuff, not all the cool functions that get buried in. So for most people, maybe a lowest common denominator actually solves a lot of problems, especially when they start pairing. And now with many of these tools, they actually support code, you know, real-time, like, Google Docs-style code development, where I can have somebody looking and typing in the same function that I am right now. That's madness in one hand, but pretty awesome if I'm actually trying to pair with people that aren't sitting next to me. Yeah, yeah. That's interesting. Like, it'd be our Pivot Labs people are, you know, stridently into pair programming, and they seem to be, they like it in person, but I wonder if having some, I wonder what they've done as far as figuring out, like, back when there was sub-Ether edit and all these things where you've sort of got live coding on either end. That would be... Yeah, we have to be a follow-up podcast now. Yeah, that's right. Yeah, because it is like, I mean, another thing you notice is when you go talk to these large organizations we were fawning over, or fawning over the potential of earlier, they're basically like, hmm, co-located work. What else you got for me? Because that's not going to work. Right. It's, you know, you're always skating that edge between the old definition of insanity cliche

and also the actual possibilities of doing something. But it seems like when it comes to pair programming, there's no end of potential to enable remote work versus having to be able to smell the other person. Always valuable. That's right. Put that in your surveys. Yeah, what else you got here? Well, it looks like Google is expanding their cloud regions here. So that's kind of exciting. You know, this reminds me, I should go look this up, but I saw a rundown recently that said that the, I think the IBM soft layer, like public cloud, has the most geographic points, even beyond Amazon. But I don't know. That seems like it might be accurate. Yeah. Yeah. I mean, they've got probably a lot of other hosting and services. I mean, I think Amazon has, or I'm sorry, Microsoft has the most cloud regions, cloud data centers available today as they've gotten, I mean, a few dozen now. They've really gone nuts with that. But I think surprisingly from this one, most people go, I mean, when I read the news, it was Google doesn't have one on the West Coast. Like that was the first one I saw. Really? I didn't even realize that. And I think it reminds you, first of all, that Google, the cloud is different sometimes than Google. Clearly, the compute engine and search service, which has data centers everywhere. So those are not always one and the same. But, you know, good outreach. I mean, you're seeing more now in India. I think IBM just kicked one up in Pakistan. So you're seeing at this point, you wonder there's a saturation point where you hit most major geographies where for many companies, you're not more than a few hundred miles away from a cloud data center. We're not there yet. But it's interesting to see this expansion and Google continue to expand. Obviously, Amazon keeps going. So does Microsoft. So does IBM and others. Is at some point you hit peak cloud or do you just keep going into micro clouds or other smaller locations to hit more out of the way places that might not require a full on cloud node, but people who still want low latency connection to compute somewhere. It'll be interesting to see

who decides to change how they deliver cloud or do we just keep going mega data centers? Yeah. Yeah. It says here in the article, I'll put a link to it, says that they have a data center and they have data centers in South Carolina, Belgium, and Taiwan. So I guess if that's accurate, they have a lot of places to expand to. Yeah. We're not done yet. All right. Everybody's got a lot of space. And for us, I mean, again, that's selfishly in the Pivotal side. What's nice is pick your host then. So, I mean, if you'd like where Google Cloud is, fantastic. Run PCF on Google Cloud. If you prefer Azure's locations, go there. It's nice to have that choice where you just kind of pick who's infrastructure, but then sometimes who's geography from a data sovereignty perspective or latency or performance perspective. Yeah. I mean, just anecdotally and stripping the names out, it's interesting when you go talk with Pivotal customers that how, I mean, there's definitely like most people either deploy on their own infrastructure or on Amazon. I would say those are like the top two, but it's curious to see what kind of companies. And there's a, I don't know, a material handful of them, so to speak, who choose to deploy on Azure or as we've talked about before, or even Google. And it's, yeah, I mean, it's interesting. Like the pretty regular normal companies are trying to wangle that out and make it work on deploying all those different clouds. So there's definitely pull for all of that stuff. And then also, I know you're recently familiar with a lot of this. We'll have to see how this weights them with the infrastructure as a service magic quadrant, adding in more things. They're going to have to recompute their spreadsheets. Absolutely. Those Gardner people, they should, those people, they should have some like interactive spreadsheets you can go fill out. That would be fun. Like, what if they had this? And then you can see it move all around. Of course, for subscribers only. They got to make their money. That's right. That's key behind the paywall. Indeed.

So the last item that we had, and I was just reading up on this this morning, is it looks like someone's finally purchased Yahoo. There was, if I remember right, I collected together a bunch of notes on this that we'll put a link to over on my blog at Coté.io. But it looks like there was, I'm guessing there was kind of a bidding war between Verizon and AT&T at the end from all the rumors that I was reading. And then, of course, there was also someone, I think it was the former CEO from Intuit, was interested in it. And there was some PE firm. And, you know, in the past, I think people like Microsoft and Google have been interested. But it's confirmed and it'll close sometime in 2017. But assuming all the fine print and government stuff goes well, it looks like Verizon is going to buy the, let me see, I'll botch this up, but you've got what they call the core assets of Yahoo, which are basically what we think of as Yahoo, all of the internet stuff. And they're buying it for like $4.83 billion or something. Right. And then as far as I can figure, and I didn't really check all this stuff out very thoroughly because I was just having some coffee while I was doing this. But it looks like, so Verizon also bought AOL, which gets them a lot of, other stuff. And it looks like if you kind of rank by eyeballs, they're like maybe three or two or maybe even one. They're in the top three of like .com sites to use a really old term. But if you rank by actual revenue from ads, it's more like, I don't know, three or four or something like that. They actually get a very small slice of the leftovers from Google and Facebook. So yeah, I mean, it seems like having worked in M&A stuff, like I can see that the, basically, the rationale, as they say, would be like, well, the way you make money on the internet is ads. So we better buy a bunch of that. No, I mean, 2002, Richard is really geeking out over this deal because that's, and this would have been really awesome. I mean, hey, $5 billion is not chump change.

You just wonder, as you think back, Microsoft offered, what, $44 billion a few years back and heck, Yahoo could have bought Google for a million dollars, whatever it was, back in the late 90s. So all sorts of revisionist history. It's so unfair to look at those things and say, what if, because sure, if Microsoft had bought Yahoo, maybe they would have gone crazy and done amazing stuff. So it's impossible now to mockingly look back and say, look at all these bad disasters because, you know, in time, those things probably made plenty of contextual sense. But Yahoo is an interesting poster child for that company who really grew up with the rest of the internet and kind of an end of an era. Yeah. And I think, you know, for me, I think nowadays you see, you see, you see a lot of 10 plus year old tech companies trying to figure out what to do, basically. And, and I think, I think it'll be, I don't know, I probably actually won't pay attention to this, but, but in theory, it would be interesting and it's all my curiosity to kind of watch what Verizon does with it, with this, this part of their business over the next three to five years because, you know, to the point, you know, the, the positive version kind of, of what you were just alluding to is like, that's pretty cheap. Like, like that, you pick up some, some very well-known assets that have, like, I think if I remember like Yahoo Mail had like 230 million active monthly users or something. And you still have Tumblr and you still have all these other things. So you have all these things and if, if, if Verizon can basically run the business side better, which maybe they could or maybe they couldn't. Acquisitions are notoriously terrible. Like, like on average, so to speak. They, they usually don't pan out too well. But yeah, it's, along with several other companies, it'd be interesting to see how they come out the other side of reconditioning, if you will. Absolutely. Or, or the, the, what was the name of that movie? The, the golden pond era of, of their life. What was the one with the little aliens that come and like, uh, give the old people

extra life and they rearrange, range all the tiling in the lobby? Is that cocoon? What'd you think of that? Maybe it was cocoon. I'm thinking Mars attack when you say little aliens, but I don't think that's it. Yeah. Maybe there's a whole, yeah, maybe it was cocoon. I think, well, I'll have to look this up. Put it in the show notes. That's right. But anyways, there's, there's some more wrap up of that. And there's, I think there's actually a pretty good, uh, I forget the guy's name, but there's, there's a good article, uh, a lengthy analysis by this guy at Vox who, uh, it's kind of going over the history of Yahoo and, uh, a little bit of the rationale for why, why it would be purchased. That's well worth looking into. So next up, yeah, we wanted to talk about kind of the theme for the week is circle of software. So if you're not familiar with this concept, uh, our VP of engineering, Ansi did a presentation. Gosh, was it back in January? I think at the kickoff. And frankly, that was a presentation that helped seal the deal for me to join Pivotal back in the spring is I really just got a good sense of the company's purpose and vision and what we were going after. And some of the, the sense of what he talks about there and we'll link to the YouTube video in the show notes was in general was a, where is, is PCF and, and, and cloud going here with Pivotal. And he introduced this idea of a circle of software. And, you know, the idea there is that, you know, as you, as teams build software, you've got these stages, you've got ideas, of course, they come from whatever customers or internal need or whatever those ideas are. You put those into some sort of prioritization and planning process that turns into coding, that turns into a deployment process, that turns into running on a platform, that becomes something that you monitor and constantly collect feedback on and then feeds back into ideas. So this isn't revolutionary stuff. That's not, you know, I think I've basically described a good agile sprint or even a waterfall process to some extent. That is not, we're not, you know, breaking new ground here. But I think it's thinking about that in terms of the software, you know, that is the life cycle

of a stage of software. And what does it mean to have the technologies there? What does it mean to iterate in that way? What are those technologies? Does anybody provide all of those together? Should one company provide all those together? And if so, what would we imagine that integration experience to be like? And honestly, talk through a bit of the casual experience when we covered up from a Pivotal perspective is sure, I have crazy ideas. Some of that may have even come out from working with Pivotal Labs. I then use something like Pivotal Tracker to connect these things. And maybe I have an experience where I go, I want a new project. And what we do is we spin up something in Pivotal Tracker. We create a Git repo somewhere. We sand you up maybe in a cloud IDE, a dev sandbox that is already loaded with Spring Boot. It's working with Concourse to do continuous deployment to a PCF environment that's monitored closely using PCF metrics. And all that feeds back into the cycle, the next iteration. That that's one flavor of a Pivotal story, but it can't be exclusive. And so I thought it'd be fun for you and I to talk a little bit about what we think of that circle. What are some of those tech that we see? They're pretty popular at those stages. And then where do we see that friction between some of those? Because some cases you don't want to, I don't know, you want actual solutions to real problems. You don't want to manufacture problems. Where is there actual problem in those handoffs in that circle? You know, what do we think of the landscape today? What I liked about that, the concept is it mirrors like a lot of the, I don't know if it mirrors, but it's an example of the conversation I end up having with a lot of people out there in the field, which is, this sounds kind of condescending, but it's like, this is how software is done. Right? And I think by this is how software is done, you alluded to it, but it's sort of like if you look at the entire software process end to end, it looks kind of simple from the get-go, especially retrospectively,

in hindsight, when you explain it, but a lot of people don't think about the full cycle of things. And I think that's a consequence of two things, at least. One of them is just like, you know, like we were describing when we were opening, there's a lot of organizations who at the business level are looking to do software. And improve the way their software is done. And they're trying to do it in a way that isn't just sort of like as a tool, like they want it as the core thing that they, how they interact with their customers or their users. And what I think about here is like, you know, most people like will think about software as, well, the straw man, straw person I'm constructing of like, oh, I've got email or I've got an application that I use or ERP or all these things. And they kind of know that it's sort of like this, this like quicksand of like spending and schedules to customize it. And it's a little like dodgy, but there's, I don't think there's really been a very mainstream understanding of how software is produced. And so like you, you went through all the different phases and it's, it's especially the feedback part. Like it gives people an idea of, I guess how like creative and open-ended software can be. And analogously, like, I forget if I've gone over it in this, in this podcast, but the analogy I always use is like, it's like those old submarine movies that like you would see in the 80s or at least I would where like, there's always a major plot point where something breaks in the submarine, whatever it is. And you're like, you know, you've got like two hours until you run out of air. So everyone goes to their bunk and they fall asleep. Right. And then the engineer, like, you know, they go to the officer's quarter and they knock off all the tables and they spread out this big schematic and then they isolate this one little part in the schematic and they're like, oh, we just need to go like put a bolt on it or, or, you know, whatever. Or, or maybe the more extreme version is like someone has to like sacrifice themselves by going into the nuclear reactor to like adjust something. So you're telling me software is like U571.

Exactly. And I think, I think a lot of people view software like that where it's sort of like, oh, we've got this schematic and it's just kind of like hard work to go in there. And so like, they've got to find prescriptive. Exactly. Exactly. Because I hate the term software factory. Exactly. Why that this is some sort of assembly line thing that I can just hand a schematic to any sort of pool of people to crank out code is so condescendingly silly because software is often more art than science, unfortunately. That's right. And then there's the other side. I mean, you know, there's the, I forget the name of it, but there's a whole website dedicated to where you've got that cartoon of like the tree swing that the user asked for. And then all these different silos, like one of them makes a roller coaster. It's sort of like what the business analyst wanted and the QA people wanted. And then finally, it's like what the customer actually wanted was a tire swing, not like a wood swing. And like, that's the other thing is unless you like know the full end to end cycle, it's hard to come out the other end with software that you actually want. And then so I think, I think the other thing that's interesting and you know, the idea of the circle of software is like, and so what you should do is pay attention to all these phases and how you tool them and how they tie together and all work with each other. And I think what I started to see back when I was an analyst and a little bit when I was at RedMonk, but then when I went to 451 was that companies like ourselves and others are starting to basically base their product portfolio on that entire cycle of things. So instead of just being like one component of it, like an operating system or like, I don't know, network configuration, they're more concerned with enabling that whole loop of software that you have. because really like if you don't enable that whole loop, you spend so much time integrating and making that stuff work together that you become more of like a master of duct tape than really like a master of the output of your software. Right. Well, I mean, to that point though, I guess maybe controversially, if you're not committed, if you're committed to doing projects

and not products and services, then you shouldn't worry about this because if you're not going to have a feedback loop, if you're just, you know, putting together an 18-month project to ship out the latest version of ERP or to crank out a custom-built CRM solution, maybe just do what works for you because don't over-optimize on some of these stages. If you do, you know, three deployments in the life cycle of this thing and that's done and then you all move on, some of this would feel like overkill, at least to me personally. Who cares about automated deployment if you do it twice? Yeah. I mean, you're not, so, I mean, to some extent, these are great ideas. Don't incorporate them unless you're willing to actually take on the cultural change of saying software is a living, breathing thing for most every company and you have to think about it as iteratively updated, not I've released it and I've moved on and maybe that's DevOps, maybe that's agile, whatever we want to call it, that this sort of fits into a model that says any smart company, whether these are the Fortune 10 companies we will work with to a smaller shop to a startup is this is awesome. The sort of circle of software concept is powerful when you want to live in that way of working. it does not fit if all you have is a stable of monoliths that get updated on occasion and user feedback doesn't matter. Yeah. I think there's something highly accurate to that which is unless you go, let's call it most of the way, then it's sort of not worth it. Right? Like if you locally optimize on one component of this full cycle, then you won't be optimizing the entire system. And there becomes a question of like was it worth optimizing that one point? And I don't think, you know, it's easy to take that sentiment as like and therefore don't change. But it's more of pushing people to realize that there's a lot more work than just optimizing one section of it. Right? Exactly right. So it's sort of like you could really get a really good idea of how you run your requirements

and like do your PMO office stuff really well and just fix that up so you always knew exactly where a requirement was in the cycle. But if you're not optimizing the way that you're doing your coding and your testing and your ability to deploy and collect data from how users are using it in a feedback loop, then it's sort of like a lot of, I don't know, it's almost like I've got a really strong right arm and the rest of your body is just like Cheeto fed. Yeah, I mean and it's okay to still do local optimizations from time to time so I don't think we're poo-pooing saying hey if you can't make the whole shebang, screw it, live in the dark ages. But I think there's something about look, you've got to be willing to say this is where I'm trying to get to and it may take me a while and I might have to optimize each group independently until I can finally say the whole pipeline feels better but this idea that says we're doing DevOps because devs can push to production that's typically not remotely enough because is your finance team aligned? Is your project planning aligned? Is your monitoring? All those things come into actually having a well-oiled software delivery machine and if you're just focusing on one as you mentioned in my previous job working with a cloud team we had spent months using an unnamed configuration management platform to automate some data center build outs and it was great but in the end of the day we probably saved a few hours for something that we did a half a dozen times a year was it worth spending months on that? I don't know did that make as much sense as maybe doing something else? So sometimes thinking about the payback of what you're doing and figuring out are you ready for that? Do you need that sort of function? Can help you figure out where in this circle of software to really invest your time and where's your biggest clogs in your pipeline start tackling some of those versus improving those things that won't actually unclog you? Yeah it reminds me of a when was this maybe there was a good talk from Damon Edwards at the 2015 DevOps Days Austin basically just going over like how to apply value stream mapping to software and you know I mean that's a

as I like to say uppercase L lean tool where you map out end to end from thinking about some piece of software to actually delivering it and having an end user use it and then it's implied you know the feedback the loop where you're continually improving it but I think that's an area that we don't talk that's a tool we don't talk enough about in the software world is in the I don't know maybe in management consulting land they do but basically you know the good thing to start with is whatever the business process you're doing and then map out everything that's in there and then to your point almost to prioritize the bottlenecks that you'll be removing and the optimizations that you'll be doing because sure removing two hours a year is you know better than as they used to say a stick in the eye but like maybe there's a way you can remove two hours a week or something else and until you have that full end to end process it's hard to prioritize exactly what to remove yeah I mean and you mentioned earlier as we think about software as a broader discipline than just here's a bunch of you know bearded geeks in a hallway slinging out some code somewhere that instead this is something that involves increasingly diverse teams of different sort of interest areas and says look what you just described there is a big lean idea of saying let's elevate constraints let's remove bottlenecks that's something that you can even get your Six Sigma geeks going on about when you think about software and optimization so hopefully hopefully a lot of what DevOps has been about take software out of just being you know something that gets pulled together on projects that's something that you think about org wide because again you look at you know we look at our biggest customers and they're powered by software even if they're in healthcare or automotive or in financial services so this is not a cost center this is something that everybody can be involved in to make sure you build the right stuff so this sort of model I think is very inclusive to a lot of folks but I'd be interested in your take on where do you see I mean of these stages in here which

ones do you think have the biggest bottlenecks I mean where are those ones that maybe you wouldn't spend a ton of your time over optimizing right now even prematurely optimizing versus those ones that you see that say you know gosh this always you know when I talk to people this always sounds like a pain in the neck this step between A and B yeah I mean I think basically like getting it into production and and then also to a limited extent like managing it in production I mean that that's I think that's a big deal in in with respect to the fact that people don't do that as well as they should nowadays like I think I think once you get the proper tools and things in place it's it's a lot less cumbersome than it is but I mean this is like a boring old answer that spawned like you know trillions of dollars in IT spend but it's just like configuration management's really annoying like like getting even getting stuff to prod I mean we just saw a survey a couple months ago 25% of shops are doing CI at this point like there's a ton of room to still go to saying I just finished code so it can go somewhere that I can test it like that is not even remotely a solved problem yet yeah so I think I think I don't know exactly how to describe that nowadays but the idea of how do I take this hunk of code and get it reliably running the way I intended it to in another thing right like out of dev out of staging out of whatever and how do I run it in production and and that's difficult because traditionally there's a handoff ooh handoff the bad word phrase of of like the configuration and how it's set up and all of that kind of stuff and what what's always delightful to point out sometimes I mean sometimes it doesn't like give them an epiphany but if you're doing things in a very cloud native fashion there is a bit of a handoff but there's not that much of a handoff because you're running on the same infrastructure in in or even the same platform in dev staging and production right you're just kind of pointing it at

different areas and I and I think there's a there's an interesting ability to strip out a bunch of the difference in in that handoff and and whenever you reduce that reduce that variability that's what like makes that that better and then and then of course there's the annoyance of just like monitoring it and if something goes wrong so I think I think that's the biggest thing is like moving from let's call it dev to production and then the second biggest problem and you see this like in surveys all the time so it must be true but it's basically just like getting people to tell you what it is they want which you could call prioritization or requirements management or or whatever that is and that's that's like an endless cycle of suckiness like that's a really it's a really hard problem to solve because it's kind of thankless like you don't with very few exceptions like the idea of being a good product manager or designer in the all encompassing sense isn't always celebrated as much as the other things and it's it's it's a difficult job and I think I think the way that gets addressed nowadays kind of gets back to the point of like software is hard and here's the full cycle of how you do software so there's more of an awareness of how important requirements management is but then the other thing is like once you narrow down to a weekly or less cycle of deployment I think that adds a lot of interesting stress that becomes helpful stress to the system of requirements gathering that you're almost forcing the I'll keep calling them product manager you're forcing the product manager whoever comes up with requirements to almost do a painfully small amount of requirements per cycle which I think has some interesting effects on on fixing up requirements but it does I think I think if you were to I think nowadays the and maybe even over time like the

standish chaos reports always a little fuzzy about its trustworthiness but like when you look at those surveys of what causes software fail failure inevitably it's that like the requirements were bad right like something was poor with that so that's that's the other huge area and iterative feedback I mean I think that's where agile people really hammer on is because you know for most people why are we asking whatever we call it the business I hate that term but you know the idea of other software stakeholders saying this is what I want why are we assuming they know exactly what they want I mean it's I don't know if software is like pornography where you have to see it to know what it is that's the supreme court answer but there's something to it right I need to see what we're talking about and then we can say you know what that now that's not right you're you built what I asked for but that's not it and if I came out of that after 18 months you'd want to kill yourself if I came out of that of a weak software sprint we'd say all right let's sit down and figure out what it is that you did like or didn't like and let's iterate on that and so as you said I mean it was very keen point there when I was running product in my last job that it was good to see the teams constantly purposely try to shrink their release window because that would force them to find areas that were inefficient like regression testing or requirements management like you said where all of a sudden the product manager had to be much better about upfront understanding acceptance criteria the requirements have that queued up well ahead of time because I can't spend two days debating sprint contents when I have a week-long sprint like that's a horrible waste of time exactly so you can do that if you have a three-month sprint who cares you spend two days on requirements what's it matter boy that is super wasteful when I'm trying to ship every week so it's a really cool pressure point that forces you to get better and let you accept the fact that you might throw away stuff after every sprint because you didn't get it right but it's better to do that constantly than assume that you can magically lock requirements and then start development yeah it reminds me of a good Texas startup CEO story where like the first startup I worked for we had like a very very

awesomely classic Texas CEO and I remember he was he was talking to one of our customers he's like check this out I've got this magic whiteboard I just write stuff on this whiteboard and those boys over there in the next room they code it and tomorrow it's in production you know like essentially like which because we were on like because we were a bunch of high school people didn't you know didn't know any better back in the CGI bin days and like you know there would be an idea and you would put it in production and well I mean you would code it up and put it in production now that's half of it right and and the way I think about that is I forget where I got this notion from but something I was reading a while ago pointed out that like software is incredibly fungible it's it's you know it's agile you can make it do whatever you want now you can also unintentionally build up so much technical debt and just like swampiness that you can't make it do anything because you're like stuck essentially so you've got to guard against that but basically that's the thing about software is like it can kind of defy a lot of rules of reality like it's not like you know it's not like the physical world where you can't create an Escher hallway of just impossible illusions but in software you can do kind of whatever you want as long as you write it correctly and so now so you can have that magic whiteboard but I think the important thing that like back in the late 90s the was not implied is like and also I'm going to have a lot of bonkers ideas and they're also going to code it incorrectly but we can go back and fix it and so this this sort of like humbleness of like yeah we don't really know exactly what's going on so what's important is that we build in a process that allows us to make mistakes and not have that bring things down and also learn from and correct those mistakes and I think that's one of the huge philosophic things that hopefully has has really crystallized and hopefully is percolating and it's crystallized over the past five years is like software is really fungible and we're also

allowed to make mistakes because it can be it's resilient we can roll things back and the only way we're really going to make it good is if we do make mistakes and we study things like we've got to get rid of this idea that we're going to do things perfectly the first time and then we can learn and improve things yeah and I think that that touches on there are a couple of other areas I would point out where I think there's there's friction I think your deployment one's spot on but you know I have more appreciation now I think for bootstrapping a project is going from I'd like to start something to actually getting all the machinery in place while the devs are coding on it and so I do like the idea of thinking well how do I kind of go from I'm ready to go to spinning up whatever my project planning tool is to my dev workspace to the right libraries to the right services the right things I can deploy to you know I don't want to have a three-week warm up while I get vagrant images figured out and I'm you know figuring out my git repo structure so I can see a lot of value and I don't think anyone is totally solving this yet we mentioned code envy and companies up front that are trying to help with that but I don't know if I've seen anyone totally solve that go from zero to productive developer on some sort of bigger project in a matter of minutes or hours I think that's a friction area that you know I'd love us to help solve and I know we're doing some work there and then the other one I think the monitoring side is is you know just on a call this morning with one of our monitoring partners and we talked about the fact that I think nowadays nobody cares somebody cares at most developers do not care about the busyness of their server or maybe even the business of their service they care about the app service as a whole like how is my as you say you know my airline service working it's made up of a million components but what really matters is the health the outside in inside out health of that service because other things are changing all the time underneath containers and services and hard drives and so thinking about that differently collecting feedback monitoring it and then also taking in human feedback as you said I mean it's also finding out someone didn't like this or no one is using this feature and how do I take all this sort of data and turn that back into ideas

that feed an iteration I don't see that as a solved problem yet again a lot of interesting areas potentially for machine learning and data analytics and other ways to glean insight from usage patterns and data consumption but that doesn't seem like that's a done problem and still there's friction there yeah yeah no that I'll have to write this down we should we should talk about monitoring at in a future episode because you know that's that's like the software I used to write when I was at BMC a while ago and it reminds me of a meeting I had two weeks ago where someone brought us in one of our customers brought us in to kind of go over how they were doing things to basically be like what do you make of that right like to give them some input on it and one of the one of the the monitoring insights that they had was that they primarily cared about exactly what you were saying as we used to call it synthetic user monitoring or I even have it wrong but transact synthetic transaction monitoring and back in my day when I had less gray hair or none the prototypical example would be buying a book right like search for a book put it in your shopping cart give it your payment details and make sure you can buy it and the sort of conceit of of user of transaction monitoring is exactly what you're saying is like we could monitor everything including like disk space and CPU but really we should just make sure we can make money like you know if if basically our data center is on fire and yet mysteriously we're still like selling books then maybe we don't care that it's on fire I mean that's a ludicrous example but it's sort of like you know getting down to the root cause of problems can sort of be helpful in many cases fact right yeah yeah do forensics that stuff matters a ton but it doesn't necessarily light me up right now in terms of priority yeah yeah and and then what you really want like I was putting it out the wrong way but like it you probably don't want to build up to knowing that your

Christmas tree is red essentially of all your alerts right you want to start at the top and say like what's the user experience like and then once things start to go yellow and red it's good to go down and dig into the details now of course if you know that if you run out of disk space on the database cluster then things will go bad that's probably a good idea to monitor that but like you know it's it's not like back when I used to do things where basically the the technique was monitor everything right like get get the get the mib for the thing you're monitoring and just like monitor all that because you're probably going to need it but that seems like a a pretty good way of going about doing monitoring and I think also why log collecting so popular because logs are one easy to get and they're good for like after the fact monitoring in sort of near real time versus like thoroughly monitoring all your your wingdings essentially well that I think I think I think the idea of the the circle of code or all these things it's it's a good it's a rich vein for future topics to go over so we'll have to touch on that some more and absolutely coming episodes so speaking of making software I think it's it's next week that we're finally going to have our SpringOne platform conference August 1st to 4th it'll be very exciting I'm actually going to Las Vegas later today for the GE predix conference so I'll I'll do some some scouting see how the city's doing and I'll get I'll be there twice in a row and so we know I think there'll be I'm assuming maybe Ansi will have a talk himself but there'll be people talking about all this the the point the points in the the circle of software you know and we talked about it several times you're both low low down on the the coding side all the way up to I don't know I don't know what else to say other than the business on the business side and there's there's there's some good tracks that'll be useful to see how people are solving these issues so again that's that's next week and I think if you go to SpringOne platform dot io you can read the full agenda we've got everything you can even book your sessions now to with the scheduler so get in there oh I

should go check that out and I'll put a link to this in the show notes but you can use the code Pivotal hyphen Coté hyphen 300 if you haven't registered already to get $300 off and then you can like you know buy me a croissant or something as and with that extra $300 that you have or some Vegas servanter for $3 oh that sounds lovely we'll go to one of those bars that's attached to a liquor store just really class it up that'll be good times so as always this has been Pivotal conversations you can find us in soundcloud at soundcloud.com slash Pivotal conversations or itunes or any place where you can search for podcast I think we're even in the google play store now and you can also go to pivotal.io slash podcast to find the show notes for this and if if you get the chance it would be great if you went into itunes and and left a rating for this or or a review or if you just recommend it to people who you think it might be useful for it that's that's always helpful to get the word out because the more people we have listening the the more happy it makes us which really what else do you want than that that's what we need so with that as always thanks for listening and we'll see everyone next time

Tanzu Talk · 🍕 Get more pizza.