Abi Noda: Chris, excited to finally have you on the show. Thanks for your time today.
Chris Chandler: Absolutely. Appreciate you having me.
Abi Noda: When we met to chat last week, you told me about your, I think seven-year journey, around developer experience and productivity at T-Mobile, and one of the things that stood out to me was that you mentioned that the past five years had been focused on DevX, but the past three years had focused on developer productivity. I want to start by asking you to share a little bit more about this progression and what’s driven that change.
Chris Chandler: Sure. When I first started picking up DevX, it was when it was becoming all the rage, right? Everybody’s trying to make developers happy, we were trying to retain developers. It was foosball tables, and free meals, and you have all the stuff to try to court developers. It started from that ethos of you want to be able to make sure that they’re happy, they’re productive, but at the end of the day, it’s that productivity, that’s the reason you’re trying to make them happy.
You want to have developers that are engaged in what your company’s building and what you’re doing, that they’re helping to take the business requirements, turn them into logic, and delight our customers. At the end of the day, that’s really what a developer, being a developer is all about, is helping with that transition. Yeah, it came very much from focusing solely on the developers and their experience, but as you start to get far enough into that, you realize, well, I can only take this so far without getting into what we now would call a platform engineering mindset.
I can only do so much around the inner loop or the local development environment. You need to start thinking beyond that and start thinking about, okay, with all the tools that they take or that they need to build whatever it is they’re shipping, how does that glue together? How do you reduce friction? How do you ultimately light up a developer value stream across all those platforms? That’s where it’s still the same end goal.
I still want my developers to be happy. I want them to enjoy working here. I want them to think that, hey, we’ve got best-in-class tool chains, and I don’t feel limited by the tool sets that are available to me. I want to feel that I can be creative, and I can make our customers super happy with what we have, and I don’t want them to feel wanting. To me, it’s just a next step of that evolution is how do you then turn that into business results? At the end of the day, I got folks above me that are funding a lot of these efforts. They want to get returns on value.
Like I tell a lot of the developers that I mentor, a company is nothing but a pile of cash being placed on different bets. It’s always important to be able to link what it is you work on to how that ultimately benefits the company. Doesn’t mean that you can’t have self-satisfaction from it. Doesn’t mean you can’t derive any other value out of it, but at the end of the day, if you can’t articulate that value, and you can’t show how, “When we did A, B, C, it resulted in these great outcomes,” then don’t be surprised whenever you go ask for funding for the next thing, and you can’t get it.
Abi Noda: Last week, when we were talking, you described what you’re doing as sort of, how do we light up the value stream, which I loved, and we’ll talk more about how you’re doing that. I want to ask you more again about the switch from talking about things in terms of developer experience to developer productivity. Your foosball joke really struck a chord with me, because that’s an analogy we use to sort of joke about situations where it seems like developer experience has a marketing problem sometimes.
I’m curious, take us a little bit deeper into what was the switch that, what triggered that change? Was it an executive just saying, “Hey, what are we doing with all this stuff?” What drove that transition?
Chris Chandler: Well, I think some of it is a bit of a culture change. We had some leadership that, we’ve sort of done the pendulum from infinite developer responsibility, all the way through to, I wouldn’t call it Draconian control, but we’ve been across all those spectrums over the course of our history, where things were either extremely mandated, or extremely open and free.
Part of it was one of those pendulum swings, but the other part is, again, it really comes back down to if you want to get the funding to do the bigger, better thing, you kind of have to put the adult pants on and say, “Okay, yes, we want all these things to be easier to use, and we want our developers to be happy, but we have to drive those outcomes.” Really, it came from that. Also, if you sort of take a systems thinking approach, you really want to apply that theory of constraints, and go find the bottlenecks, and iterate, and keep attacking those.
To do that, you kind of have to move beyond developer experience into the entire SDLC lifecycle from end to end, from the time that business or the leadership comes up with a requirement, all the way through to we’re delighting our customers with it, how do we shorten that path? How do we remove as much friction from it as humanly possible? Again, like I said earlier, I still feel it’s in service of the journey, it’s just sort of a maybe different evolution or a different way to look at how to get to that at that end goal.
Abi Noda: This is a question I get asked often, and I’m sure you’ve faced this question, but in your words, what is the difference or what is the relationship between developer experience and productivity?
Chris Chandler: I kind of think of it as the iceberg analogy, right? Developer experience is sort of the bits that you touch and you feel. If I do a good job with developer productivity, I’m doing things that you don’t even know, right? In an ideal world, if you do the right things and you take those golden paths, I’m dealing with things you don’t want to deal with, like asset management. I’ve got a base image, a container image for you that is CVE-free, and you’re not having to worry about picking that stuff out.
At the end of the day as a developer, not that you shouldn’t care, but you kind of shouldn’t care, right? It’s what you package inside the box. You don’t need to be UPS and have an entire delivery chain to create something cool to put in a box to go ship it to your customer to make them happy. You really focus on what’s inside the box. The rest of it, you should be able to lean on other people. That’s where I see the developer productivity aspects coming in is, how can I take that sort of pain and friction away for them?
Keep in mind, I’ve got two different customers in this world. I’ve got my higher-ups who want to see that return on investment. They want to see the multiplier effect of using common bits and Lego, and then I’ve got the developers. I could totally make my leadership happy and make my developers miserable, but at the end of the day, that’s not the right thing. I could totally give developers all the freedom in the world, and we have 6,000 different versions of the same thing and can’t keep it compliant and govern it, and that’s not going to make my leaders happy. It is all about, how do you balance those two out?
Abi Noda: Yeah. I really love that answer. There’s so many ways to answer that question, which is why I was curious to get your thoughts. I talked to so many leaders who will say, “How do I get execs to care about this stuff?” Developer experience, productivity, whatever you want to call it, “How do I bring the other VPs or even our CTO along? How do I get people to pay attention? How do I get them to care?”
As someone who’s been on an evolution and on a journey to iterate on probably how to do that and how to interface with the rest of the business, what’s your advice to leaders on how do you get aligned with other executives, and how do you get people to care about developer productivity?
Chris Chandler: I forget where I hear it, but there’s a quote that I’m sure you’ve heard a million times, but it is like, “You can bring your opinions. I’m going to bring data,” and I find that data is always what is going to drive any audience, but executives especially. What do they want to see? They want to see dashboards. They want to see lines going up into the right. You want to be able to have that data to reinforce your theories. By the way, sometimes it helps prove that your theory wasn’t right, and that’s okay.
You want to have that data to show that, “I had this hypothesis. If we do ABC, I’m going to get this result out of it.” In being able to have that data to say, “It’s not a gut feel,” I can empirically say, “This was our situation before we applied this thing, and we have every reason to believe, a high level of confidence to believe that change resulted in this different outcome.” The next time you go back to the well, and you want to ask for, “I need more money for this,” or, “I want to do that,” or what have you, being able to come back and prove that success.
It’s partly in the tooling, the process, all that, but it’s partly you. You have to be able to go sell it. It goes back to the piles of cash thing I said earlier. If you make it enticing, that, “Oh, if, okay, we put this amount of investment here, we got this sort of outcome, okay, we’ve seen that happen two or three times. We have a reason to believe that this is going to be successful. Let’s keep going with that.” I’ll give you sort of a flip side of that.
For the longest time, I’ve been pitching that we need a giant developer productivity engineering organization. I’ve been pitching that it needs to be product-led, and there’s this product layer on top that thinks about developer productivity as a value stream, and really has a product mindset. Underneath that, you have all the platform teams, the folks that run Kubernetes, or manage how you get on the cloud, or whatever, and go on down the stack, with developers ultimately as the customers of that org.
There’s nothing wrong with that vision. It’s really hard to swallow when it’s on a PowerPoint and you don’t have any data behind it. Getting to a question that I think you’ll ask, because I’ve heard you ask it a bunch of times, where do you start? How do you get going? Start with the simplest thing that you could do on your own that you can go prove that data from. As an example, I am sort of a Rebel Alliance, just to use the unicorn project term, went and started building things like common helm charts and common base images.
We didn’t ask for permission, we just went and did it. It’s relatively low effort and pretty high payback. Then now, we can start to compare, going back to data, okay, how CVE-free are these teams versus the ones that picked the open JDK image that hasn’t been updated in two years? Then it becomes really easy to make that argument. Now, I’ve built my first success, and then you just build the steps from there on out.
Don’t get me wrong, I want that big giant org I talked about, but I had to be realistic that I can’t get all that. I can’t just say, “Hey, Netflix does it. They have 20% of their workforce doing this.” It’s like, “Okay, great. We’re not Netflix.” The mistake everybody makes, they see all the great things they do and realize it takes a certain culture, it takes a certain mindset. Yeah. To me, that’s how you go about being successful, and that’s how you go about, again, layering success upon success to get to that end goal.
Abi Noda: Definitely the layers is key, incrementing your way toward that vision, and I’m excited for you. Sounds like you’re on course, at least pointed in the right direction.
Chris Chandler: Yeah, it’s off on the horizon there somewhere, but yeah, yeah, we’re getting there.
Abi Noda: I wrote an article actually just this morning, talking about this problem of how do you get leaders to care? I discussed similar things as you’ve brought up, the importance of data, in particular, the importance of benchmarks, if you can get those. Also, not just data, but ideally, being able to speak in terms of dollars. One of the comments I got about this topic was really interesting, made me think.
Someone actually asked, because the article is about how to get your CXOs to care, and someone asked, “Is engineering productivity something execs are even thinking about? Are they up at night, worried about engineering productivity?” I’m curious, we may not know the answer, but what do you think? Is it something that CXOs at your organization are thinking about, and how are they thinking about it? They’re likely not thinking about it the way we think about it.
Chris Chandler: Well, I’m definitely a few levels below the C-suite, but if I had to put my hat on and be one of those folks, it’s all about, again, that pile of dollars. If I can get more productivity, and not just productivity, but I’m delivering not just more often, but also delivering safely, right? It’s very important. Keep those things in balance. If I could do more with the same, what leader at that level isn’t going to be happy with that?
That’s, again, to your point of being able to put dollars on things, and going back to my earlier comment about force multipliers, really, I try to think about it in those terms. I’m not going to make a developer write code any faster. If we look, there’s all these stories, all these studies, and I forget what I was listening to recently. They were talking about the amount of time that a developer, oh, that’s what it was, it was on… Oh, geez, Nilay Patel’s podcast.
Anyway, they were talking with the CTO of GitHub, and talking about how when they’ve been building Copilot, they started off on code completion, but now they’ve realized there’s so many other things. You could apply AI to things like a code review. I got a merge request summarizing that for me, so I don’t have to take on the cognitive load of figuring out what this MR is all about.
It’s really about how can you find those places where they’re not going to do the thing any faster, but how do you remove the things that aren’t the thing? How do you remove the friction? How do you remove the lost time? If I can decrease, let’s say, the time that they have to wait on a pipeline to build, to then go test in an integration environment, I can take that number. I know my blended rate for what a developer costs me on average. I can take that number.
See, I shrunk that down from five minutes to seven minutes. Okay, that three minutes I gained, I can multiply that by that other number. You can extrapolate that out and boom, now you got a number. It’s like, “Okay, we put one, two people on this thing, went and got the data, found where that friction point was, eradicated it. Here’s our outcome. Let’s go get the next one. Let’s go get the next one.” You just keep the flywheel going after that.
To me, getting back to your question, I don’t think they sit up at night thinking about, are my developers productive enough? Sometimes it’s one of those things where you don’t know, you don’t know. Having folks that love getting in there, and digging into the weeds, and finding those sources of friction, and getting rid of them, those folks are invaluable. To me, that would be my message to any C-suite is go find those kinds of people, enable them, let them go kick rocks and find the friction that you’re not even aware of. You’ll be very surprised at the numbers.
Abi Noda: Shifting gears a little bit, I’d love to just dive into more of what it is that you do in your work and where your time is spent. I understand your organization owns a lot of the developer tooling, everything from GitLab to HashiCorp, a lot of the destination platforms, cloud infrastructure, databases.
One of the things you told me when we met was that you spend a lot of time on figuring out how to get things to play nicely together. Say more of what you mean by that and how you actually do that.
Chris Chandler: Yeah. A lot of my job, it would fall under the other duties as assigned, and with me assigning them to myself. It’s almost like being a rogue agent and going out and finding those sources of friction I was talking about. The other thing that I use to sort of drive what I try to find and work on is thinking about it from having that empathetic mindset of an average developer, because I’m an average developer.
I’m actually an ops guy who learned enough code to be dangerous, so I can easily relate to what it’s like to not be eyeballs deep expert in JVM tuning or whatever. Sure, I know some stuff, but yeah, don’t get me a line on that. Yeah, a lot of what I try to do is think about, how do those pieces fit together? Like you said, we own GitLab, we own our managed Kubernetes offerings, we own cloud, and all the things you can get to on cloud, databases, tons of stuff.
The idea is I wouldn’t expect the folks that run HashiCorp for us, that run Vault and Console for us, to be deep, deep experts in how a GitLab pipeline runs, or what the best path is to take a value from one of those platforms, and get it into a config map or a secret in Kubernetes. There’s this Venn diagram of where all these things overlap, and for me to expect the Kubernetes team to, again, understand deep JVM tuning or, “Oh, you should totally restructure how your classes are ,” I don’t expect them to know that.
Having a team that can sit in between and know enough about each of those areas, right? Again, not deep, definitely much more broad than deep, which has kind of been my career overall. I’ve been able to pivot from one thing to another thing to another thing pretty quickly, but I’m not the guy to solve your O to the N scaling problem. That’s not me. I do feel where I excel is figuring out how to put those pieces together, and how to put them together in a way that doesn’t just work, but that is repeatable, scalable, and has sensible defaults.
That’s the other thing, you’ve heard me talk about Lego and composability, sensible defaults are the other thing. It reduces that cognitive load. If you make it to where the thing just does the thing, the way that 80/20 way should be, okay. You’re going to make most people happy. By the way, don’t hide that behind walls of abstraction where you can’t get in and tune it. Set some defaults.
When people are ready to grow into changing those defaults, have it documented, be able to make sure that they can get to the information they need to know how to tune that knob the right way. Those are the mindsets and thoughts I put into as I go find those sources of friction around all of our different platforms.
Abi Noda: You’ve shared the principles and philosophy around how you think about what a good developer experience looks like and how you minimize friction. I want to ask you about the more logistical and organizational side of how you go and figure out the problems and the friction. Very tactically speaking, how do you do this? Are you just sending an email to different engineering leaders and setting up one-on-ones? Do you have some sort of monthly meeting kit? How are you actually having those conversations and building those relationships?
Chris Chandler: Yeah, there’s a few different ways. One is my role is a member of technical staff, it makes it sound like I work at a help desk, but actually it’s an old Bell Labs term. You can think of it as a staff engineer, essentially. My other MTS peers kind of align to these different domains, and our job as MTSs are to find those gaps between all the domains where there are things that need to be solved, or if there’s something cross-cutting, like developer experience or developer productivity, figuring out how that peanut butter is across all those.
First is, yes, every other week, all we MTSs get together and talk about what’s new, what’s going on, if we have challenges, if we need assistance, if we want thoughts. It’s a guild, if you will, that we can go bounce stuff off of each other. That’s always helpful. If I don’t know exactly where to plug in, which leader’s the right leader to get engaged, or who owns a particular tool, or what have you, that’s usually my first go-to. Second is just over the years, I’ve established those relationships.
One benefit of doing what I do is I don’t live over here in database land, and I think about databases, the caching, and all that. My job is to kind of, again, be broad, to understand all those different pieces. Just by the very nature of doing that, being in this role and trying to solve that gap, I’ve gotten to know a lot of people. A lot of it is just that relationship building. It’s amazing how much… At a minimum, video calls help. I see a lot of people that still, we’re a bit of a mixed culture.
I got certain circles where if you don’t turn your camera on, you get shamed, right? Others, the whole meeting goes by, and it’s just a bunch of people’s avatars. One of the things that I learned, because I was at Cisco for 17 years prior to coming here, I never had a… Well, I would say never. I rarely had a boss who was even in my same time zone, much less my same city or state. I got used to having leadership and my peers to be remote, and video calls were a huge part of making sure you maintain that connection.
Never underestimate the human side of things. Just even the 30 seconds of asking what people did or whatever, it pays dividends. It sounds silly and it sounds trite, but it really does actually, in the long run, because at some point, you’re going to need a favor from them, and when you’ve built that relationship, it’s easier to make that ask, and it’s easier for them to say yes. It doesn’t guarantee it, but I’ve found that not discounting the human element is a big part of it.
Abi Noda: makes sense that your role is a lot about finding the friction that exists between different things, and connecting the dots, and accordingly, being able to know all the people responsible for those different dots, and have a relationship with those people would be really important to success in your role.
Chris Chandler: Well, yeah, and if you’re going to ask something from them, going back to our thing about data and all that, you have to be able to show them how, not just it’s going to benefit the company, but, “Hey, by the way, people are going to like your platform or tool more,” or, “This is going to reduce your support burden.” When we have everybody using this Helm chart to deploy to your Kubernetes cluster, guess what?
They’re all deploying using the same chart, which means you now know how they’re deploying. Your support team’s not going to spend 30 minutes trying to rip apart their templates and figure out what goofy thing they did that they copied off a Stack Overflow five years ago, and nobody even knows how the hell it works anymore. Being able to, again, going back from empathy, being able to put yourself in the shoes of the person you’re asking the ask of and say, “Okay, well, what would convince me?” I hate to say it, but what’s in it for me is going to be a part of everybody’s calculus.
Abi Noda: Absolutely.
Chris Chandler: It’s just how we’re wired.
Abi Noda: Yeah. Well, we could go on for hours, but we need to shift into our last topic, which I’m really excited about, is a platform that you all have developed called Starter Kits, and the platform is actually patented, and I’m going to ask you about that later. From what I understand, what we’ve talked about, Starter Kits is a platform somewhat similar analogous to Backstage, and it’s part of a broader platform that you’ve built called Dev Center.
To start, maybe just introduce people to what Starter Kits is. Then I’m going to ask you about the journey of how it got funded, and how you built it, but let’s start with a little introduction.
Chris Chandler: Sure, yeah. Like you said, at the end of the day, the final result of what you get out of Starter Kits is very similar to Backstage’s software catalog, right? The idea is, as a developer, I provide some inputs where I want the repo to be built or to be stored whenever it’s done doing its thing, and various config options, so on and so forth. As a developer, I get a repo, and now off I go.
There’s some technical nerdy details about how we implemented it that we could get into. The other thing that’s really different with what we did with Starter Kits is a lot of the software catalog stuff really begins and ends with scaffolding a code repo, and it kind of just stops there. Backstage, it’s going to assume that, okay, you’re using maybe the GitHub plugin to then run actions, or you’re going… Whatever it may be.
There’s all these different pieces that things will get subsumed out to other parts of the platform, or maybe even completely outside the platform. We’re a GitLab shop, and so the nature of GitLab is most everything you need is kind of in GitLab, right? I’m not using Jenkins in Artifactory or whatever. It’s all sort of together. What’s nice about that is that it allows us to think about how do we provide the whole experience.
Let’s say you want to write a Spring Boot API, and you want to deploy it to Kubernetes. If you come to me with where you want the final product to be put in GitLab, some basic information, what version of Java you want to use, an open API spec, because again, it’s an API. We’re doing the right thing and writing open API specs, I can go not only scaffold all your code, which any generator, I can use Spring Initializr and go do that and that. There’s nothing super special there.
I’m also going to pre-bake in things, like we have a standard security library that has things around helpers for validating JOTs, and pop tokens, and things like that. We have a common logging library. We also fold in those things I’ve been talking about before, the common Helm chart, the common base image. All those things come together, and then they get an end-to-end CI/CD pipeline layered on top of it, because again, just GitLab brings all that functionality together.
Now, as a developer, going all the way back to our discussion about when I have a contractor come on, and how do I make them productive day one, if I point them at a Starter Kit, the very first commit that runs on that, deploys for their dev environment. Yes, it’s an empty app, it has no business logic in it, but it deployed to dev the very first time, and now they didn’t have to think about, oh, how do I create a Helm chart? Do I use Istio or NGINX Ingress?
All these things that either we ask developers to take on, or going back to resume driven development, they choose to take on themselves, where they just, “Oh, cool, I’m going to go nerd out about all this stuff,” when ultimately, sure, let’s test the boundaries. Let’s create some new golden paths if needed, but sometimes you just got to ship the thing. It allows folks to be productive day one, and by the way, do it in a way where all those bits I talked about are centralized.
That Helm chart doesn’t live down in your repo, the pipeline doesn’t live in your repo. Those are all pulled in and referenced at pipeline runtime, such that when there’s a new requirement, my team could go implement that, or again, it’s inter sourced, anybody can implement that. In fact, I’ve had multiple contributions for different features that are like, “Oh, cool, I didn’t even know we needed that. Okay, cool.”
Review it, make sure it’s backwards and forwards compatible. Cool, fold it in, off we go. Now there’s a new capability added to the paved road. Yeah, that in a nutshell, is what Starter Kits are about, and you’ll notice that I said Starter Kits, right? I’m not trying to replace the cockpit for all the other things. I don’t want to be a layer on top of GitLab. Now, I got to understand GitLab’s RBAC model, and as features change there, I got to bring that back in.
Very purposefully meant to start you on your journey, but also use those common Lego in a way that we can evolve and iterate those centrally, and developers, to the extent that we can, don’t get for those new requirements.
Abi Noda: The build out or creation of Starter Kits predated Backstage being open source from what I understand,. I want to ask you in a minute, a little bit more about more differences between where you’ve ended up and what you’re seeing in terms of pros and cons of organizations that are adopting Backstage. Before that, I want to ask you, especially given that this predated Backstage, how did you get this funded? How did you make the business case for this?
Honestly, a lot of organizations that I meet that are doing this sort of thing, a lot of their business case is actually just built on, “Hey, Spotify does this thing.” How did you get this funded before this type of platform was a hot thing?
Chris Chandler: Yeah. Yeah, exactly. It took a little bit to land on it, but honestly, as far as funding goes, we really just begged and borrowed resources from a few different places. I inherited Dev Center from a team that had built it before me, but some of the resources from Dev Center and then myself, we all collaborated together to build that initial version of it and to kind of get it kick started. A lot of it borrowed some patterns. That team was already using some generator patterns, so we just sort of built on that goodness.
It was already directionally correct, and then we just sort of helped elevate it a bit and expand the catalog. The team that was building that was very focused on APIs, so there were no UI Starter Kits. Now, we have React Angular Vues, stuff like that. Before, it was really just all Spring Boot and that was it. We brought in Node Express, and Python, and a few others to help round out the catalog, but it goes back to the Rebel Alliance type of thing.
Be creative, and think about what’s the thing you can do with the least amount of resources, and without asking for this giant commit? I think that’s why Backstage ends up being a popular choice for a lot of people, because it’s like, “Okay, well, technically, I don’t have to pay for anything.” Yeah, you need to divert time, and resources, and have folks understand react, and all that for the care and feeding of it, but you’re not buying a license. You don’t need a giant team necessarily to run it, depending as to how you run it and manage it.
Abi Noda: Yeah.
Chris Chandler: Yeah, it’s really just a whole lot of big borrowing and goodwill.
Abi Noda: That’s how you do it.
Chris Chandler: Yeah.
Abi Noda: Yeah. I know you’ve followed Backstage, the developments and that whole ecosystem, so now, I don’t know how much time it’s been since Starter Kits was created, but looking at the problem sort of in hindsight or current state, what are some benefits or what are some things you’ve learned about how you’ve approached the problem, versus how Backstage solves certain problems?
What makes you… I know you feel like what you’ve built is better for your organization, so what are the trade-offs or what are the advantages of what you’ve built that you see?
Chris Chandler: Yeah, and I think you put it right. For us, it’s better. I will not sit here and say that we’re better than Backstage. There’s some things in the Backstage ecosystem that I think are phenomenal. I love the idea of centralized docs. I love the idea of just, again, using those common Lego to do the common things, but where it doesn’t quite match up for us is Kubernetes deployment, for example.
We generally do that out of our pipelines, and a lot of times, the tools like Backstage, the RBAC model doesn’t quite align to the underlying platforms and how we have things built. GitLab integration, for example, there is a token, and I know there’s been some folks, different vendors that are trying to solve this problem, but you essentially have one Uber token that needs to do everything, and for various reasons, we don’t have everything in GitLab default open.
It’s more of an opt-in model or an invite only model, where you can only see a project if you’ve been expressly invited. We solve the discovery problem different ways. We have a system called Clearwater, which is a central repository for all of our API specs, and we have a thing called API Explorer that sits on top of that that provides that sort of browse and discoverability functionality, and we already had that in place even way predating Backstage and Starter Kits, right?
That’s been around since I’m going to say 2014. Again, the team I inherited Dev Center from, they’re the ones that built that as well. Again, API-centric team, so they built a lot of our API tooling. Anyway, long and short, I absolutely love the energy and the spirit with where they’re going. It’s just for us, we found it just didn’t quite match up with some of our requirements, especially given being a larger enterprise, security, controls, compliance, bringing things like SOCS, it gets really, really fun really fast.
Being one Uber console that overlays on top of all of that, I mentioned that I originally started off with that cockpit model and decided to land on Starter Kits, and just generate the thing, and twiddle the stuff centrally, and I don’t have to be a replacement. That was actually for a reason, and that illustrates some of those reasons.
Abi Noda: Yeah. Tell me about the patent process. Also, just why? Why did you patent it, and what was involved with that? Just tell me the story.
Chris Chandler: Well, I think most companies obviously encourage patent creation. You want have a set of IP that you can help build and protect your company on. Yeah, really, when we looked at it and realized… When you think about patents, it’s less about the idea and more about the implementation.
Abi Noda: Right.
Chris Chandler: Again, from an idea standpoint, very similar to Backstage, very similar to most any code generator, right? I could say JHipster is similar to it. It’s CLI and it’s all prompted, but it’s the same idea. Give me some inputs, and I’m going to blow out a repo for you. What’s different with us, and this gets a little bit into the nerdy bits here, but we separate the code generation part from the rest of the assets that go along with it.
In the example of Spring Boot, we have a Spring Boot generator, and it could care less whether you’re deploying to Kubernetes, or Azure web app, or whatever you’re deploying as, it kind of doesn’t care, because it’s only concerned about generating code. Then we have the ability to union in assets from other places. Based off where you’re going, I may layer in a completely different POM.xml, because if you’re deploying to this other place, maybe there’s different libraries you’re going to pull in.
For example, maybe I’ll pull in a library, if you’re going to be in Kubernetes, I could pull in a library around Docker and containerization that may not make sense if you’re an Azure web app, as case in point. The pipelines will be different, right? Sure, they’re all the same up to the build stage, but then they’re going to diverge from where I go to deploy and whatever my post-deploy steps are. The idea there is that we… By the way, you can use any generator.
In fact, we had, going back to that workforce transformation team I talked about, when they were running that training program, they actually used Spring Initializr as their generator. They’re like, “I don’t want to write a generator. We don’t care so much about exactly getting the right code. It’s more about just teaching the process and teaching the tooling.” For them, it’s real quick. They just use Spring Initializr, they brought in their own READMEs and their own pipeline file, and boom, they’re off to the races.
That was the idea. It was, again, composability reuse. If I seem like I’m repeating myself, I’m repeating myself. A strong tenet I try to always come back to is how can you decompose the things in a way that you could rearrange them however you want later?
Abi Noda: Well, congrats on the patent, and thanks for walking through a lot of the ways you’re thinking about your work around developer productivity at T-Mobile, and some of the things you’ve developed and created. This was great conversation, Chris. Thanks so much for your time today.
Chris Chandler: Thank you so much, and really honored to be invited. Appreciate it.