On this sponsored episode of the podcast, Ben and Ryan talk with Matthew Groves, Senior Product Marketing Manager at Couchbase, and Cory House, the founder of Reactjsconsulting.com and a Pluralsight course author, about how to increase velocity without increasing pressure on your engineers, whether cloud native technologies can help (or hurt), and how to design your toolchain so it improves velocity. When some people hear the phrase “developer velocity,” they cringe and think about delivering an increasingly large number of story points during a sprint. Others push to tighten feedback loops for engineers in order to remove the roadblocks between writing code and getting it into production. But few will understand that much of the “feedback” in that loop is human, so giving them a little more slack lets them provide feedback faster. After all, if you want a fast highway, you should have fewer cars.
Having trouble with understanding your team’s productivity outside of frameworks and tooling? Create a backlog and work through it: Instant Agile! How much of that backlog you work through is a good baseline measure.
The Stack Overflow blog recently featured an article from Stack Overflow’s Director of Engineering, Ben Matthews: Does high velocity lead to burnout? That may be the wrong question to ask
If you're interested in seeing how Couchbase’s SQL database solutions can help improve your team’s velocity, check out Capella.
Cory House helps teams deliver successful React projects through his consulting business, ReactJS Consulting.
If you want to learn more about Matt, check out his LinkedIn.
Congrats to Lifeboat badge winner,
, who threw a great answer to rescue the question,
Display button with inline CSS
.
[intro music plays]
Ben Popper Hello, everybody. Welcome back to the Stack Overflow Podcast, a place to talk all things software and technology. I am Ben Popper, your Director of Content here at Stack Overflow, joined as I often am by my wonderful colleague and collaborator, Ryan Thor Donovan. Ryan, how’re you doing?
Ryan Donovan Good. You just love stepping on the ‘Thor’, huh?
BP Well, you're out in the Pacific Northwest. I'm sure you're feeling the Viking vibes today. So Ryan, we had a recent piece up on the blog about developer velocity from one of our own engineers, and that is going to be the topic today. When you hear that term, what does developer velocity mean to you?
RD Well, I think it's one that people use in a lot of different ways. I think the general sort of developer velocity is how fast you're delivering value to your customers. I think there's a lot of ways you can measure that.
BP All right, terrific. Well, we have two great guests today, Matthew Groves and Cory House. I'd like to welcome you both to the Stack Overflow Podcast.
Matthew Groves Yeah, thanks for having us!
Cory House Yeah, thanks for having me.
BP Of course. So Matthew, let's go with you first. Tell the audience a little bit about yourself. We usually do a quick flyover. Who are you, how'd you get started in software and technology, and what is it you do day to day now?
MG Oh gosh, how I got started. Well, probably like a lot of kids in the ‘80’s, I got a TRS-80 from my parents and learned a little bit of Basic on there and really liked it and pursued that into college and so on, and been working as a developer my whole career for the most part, working as in-house developer, consulting, product development. What I currently do is I actually am in marketing now, in product marketing. I work for a company called Couchbase as kind of a voice of a developer inside of product marketing. So if you're not familiar, Couchbase is a NoSQL JSON database, which I'm happy to talk about more, all day in fact. But we're very interested in helping developers achieve more, become more efficient, ramp up faster, be more productive and flexible, which is what we're going to talk about today.
BP Okay, terrific. Cory, give the audience a little flyover. Who are you, how'd you get into the world of software and technology, and what is it you do today?
CH I am an independent consultant, specializing in React. I’ve been in React for, gosh, almost a decade now because it seemed to have legs and I author courses for Pluralsight. I do onsite training and virtual training, speak at a lot of conferences. And when I'm not doing all that I'm writing software for a variety of different companies.
BP To get things started, let me put it to the two of you. Matt, from your perspective at Couchbase, high-level what is the idea of developer velocity? What's the first thing that comes to mind? And after explaining that, maybe talk a little bit how that relates to the particular business organization that you're in.
MG The first thing that comes to mind with velocity for me, and this is probably unfortunate, is points and points estimates. How many points can we deliver during a sprint, because the last time I was building products that's how we measured velocity and estimated features. But ultimately, I think you kind of nailed it early on. It's really just how much time does it take to go and deliver a feature from start to finish, or part of a feature from start to finish, and how do we measure the time involved there? And then I think what I'm more concerned about for this episode is, is how can we make improvements in that area? How can we help developers to be more efficient and deliver stuff faster or in fewer amounts of points?
BP And Cory, from your perspective, would you take issue with any of that or feel the same way? Anything that particularly excites or rankles you the way points does for Matthew?
CH Well points isn't the first thing that comes to mind for me. I think for me, the fundamentals of it is the idea of a feedback loop, that if you're talking about the developer velocity, I'm a believer that if you can optimize for your feedback loop being more or less instantaneous then you're likely to see developer velocity go way up. And when I think about the jobs that I've had where I struggled to get things done or to estimate or to even stay focused, it was often because of feedback loops. I would find myself going, “I've got to wait for this compile,” and it takes long enough that I go get a coffee and then I find myself distracted in water cooler conversation or on a website and that adds up. It's a bunch of paper cuts through the day. So for me, that's really become my focus in modern times. If I feel like my feedback loop is slow, then I feel like job number one is for me to find a way to make it faster.
MG Putting it in terms of feedback loops, a really interesting way to look at it is if you look at the Agile software manifesto, it was kind of about getting those feedback loops down from the waterfall of months and months or years to a couple weeks at a time. If you look at concepts like extreme programming and pair programming, that's all about getting really fast feedback. And test driven developments, getting instant feedback while we're in the process of building a feature. So I think that's a really good way of looking at it and you can't always get the feedback loops down to deploying the same day. Not every team can do that yet. But that is a very nice goal to shoot for– reducing the time it takes for me to get feedback on something I'm working on.
RD A while back we ran a blog post sort of on a similar subject about how to reduce that to as fast as possible. I think that's interesting that the blocker isn't necessarily the developers doing the work, it's getting some sort of feedback on your work.
BP When you talk about feedback, are you talking about feedback in terms of approvals, in terms of validation, in terms of collaboration? When I think of developers it's like, “Somebody needs to prove this PR,” or, “The system needs to run some tests to make sure I'm not going to break anything,” or, “I've done what I'm supposed to do, but until somebody does the other half, it's not complete.” So talk to me maybe about those different aspects of collaboration and coordination and where you would tighten up the feedback loops and where it's been bad or where you've seen it fixed well.
CH Yeah, I love that you brought that up because you're right that it's a lot more than merely how fast is my compile is, or how fast do I get an answer that the code that I just wrote works. It's everything. I mean, I've worked on teams where I felt like my feedback loop was slow because pull requests would be delayed because nobody was willing to step up and review code. Everyone felt too busy. It's part of the reason that Lean and Kanban in general is something that I enjoy. It’s that mindset of freeing people up a bit where they feel like they can actually dedicate the time to do code reviews. Because again, it's that old metaphor of a highway that is completely full of cars tends to jam up, so you've got to give people some level of slack to be able to review code and also feel like they don't merely rubber stamp it, that they truly give meaningful feedback. And that is in other areas too. When you think about, I'm writing the code but I need quick feedback from a product owner or from a designer, from someone else who can provide me the assets that I need or answer nuanced questions about the implementation, all of that speaks to feedback loop too. So there's a recognition that you can take a developer who would otherwise be highly successful and highly efficient and put them in an organization that provides them a slow feedback loop around all that ecosystem that I just talked about, and you can find them being unsuccessful. You can find them being frustrated and perhaps even not liking their job and not fully realizing that that's perhaps why. That there are these things that are outside their control that they might have enjoyed in a previous position. And I've seen that bad enough. I remember at one point being in a job where this was such an issue that I thought maybe I just didn't like writing software. Maybe that was the problem. And it just turned out I was in an environment where it was just not fun to write software.
RD So how do you balance that and measure productivity? Matthew talked about the bane of story points as a measure of velocity. How do you understand velocity if you're not just looking at the tickets and the story points?
CH I'm a believer that there's no easy answer to that question, although that doesn't mean that it's not worth asking. I look at it as though the search for that is going to depend greatly on the team. I was a manager at one point and frankly I wasn't very good at it because one of the things I liked to do was manage like a developer, so I started thinking about how I could basically automate myself out of a management job by, “Okay, I should just need some metrics here. Largely I should be able to look at spreadsheets and manage my team more like they are numbers rather than people.” And I'm ashamed to say that, it's just a fact. I wasn't very good and I can see in retrospect some reasons why. Because again, I was looking for those silver bullets and thinking I could say, “Okay, John is not as good as Sally because Sally did twice as many pull requests.” And you go, “But you can't just look at pull requests because they all are not created equal. All tasks are not created equal.” There's no substitute for being in the trenches enough where I can truly see the measure of value and work that one person is providing versus another. Now that's not to say that metrics have no value, because I will say I just had a conversation a couple weeks ago with a director who pointed out that their most productive employee had merged 400 pull requests within the last six months, and their least productive had merged two. Now, that's enough of a difference that I think there's something there. Now, maybe those two pull requests were just amazing, but I've got to think that there's more to know there. So metrics are not worthless, but they do need to be considered as merely part of the story.
BP Yeah, it's interesting. There's been a number of large articles recently about the increase in productivity measurement tools, especially as a lot of workers go hybrid and remote and folks in management want to understand how they're doing, their velocity, their productivity, their contribution. Not just developers– articles I've read recently talked about people who work as chaplains. Literally any kind of job where they want to have some oversight and they're not seeing you in person all the time. I think your point is well taken. There must be some difference between 400 and two. But again, getting back to data health, is that person who did 400 doing busy work because they know that they're scoring points and the person who's doing two hates it and only does the things that matter? We had a few people from Stack Overflow on once or twice who've been engineers here 8, 10, 12 years, and their job now is to delete code. Their job is to take things away and chip away the monolith and make it easier to deal with and easier to read. So it's always interesting to think about what is the right metric and how do you keep evolving that, because once you set it then people start to game it. So Matthew, I brought this up at the beginning, but can you reflect a little bit on how developer velocity relates to the work you do? Either how this happens at your organization, or ways in which you've seen some of your tools and platforms impact this for clients?
MG So at Couchbase we're a software company so we make products, so it's very similar to teams I've been on in the past where it's product development. I'm not on the engineering team currently at Couchbase, but I can tell you about how it's worked in past product development teams that I was on. So one of the things that Cory brought up was measuring individual productivity and I think there's some value to that, yes. But I think one of the benefits we have as software developers is that we're actually building something that has an artifact, it can be shipped. So if we can create a backlog of things we want to build in our product and we can prioritize that backlog, well then right there we've got what someone I used to work with called ‘Instant Agile’, where it's just about seeing how much of this backlog we can work through and that will be our measure of our productivity. Not, is Matt doing better than Jamie, or is Steve doing better than Alice? It's a measure of how good is our product doing? How much do we think we could have built and how much did we actually get to build? And so measuring a team productivity, that kind of takes some of the ego out of it too, I think. I guess your second question was what is Couchbase doing to help the developers be more productive? And there's lots of things that attracted me to Couchbase from the beginning as a developer. It's a NoSQL database, which I've always found interesting the kinds of things you can do with NoSQL databases and the kind of flexibility you have with JSON data for instance. But one of the things that made Couchbase unique to me was that it's not really a NoSQL database where I had to throw out all my knowledge of SQL from years past. I could have a SQL engine available to me immediately in Couchbase, which is a rarity in the NoSQL world. And so I had kind of a more gentle learning curve to start learning how to use Couchbase there, and that kind of familiarity I think is a key to reducing the amount of stuff that you have to learn. There's always new stuff to learn. Cory and I both make videos for Pluralsight and there's hundreds and hundreds of different technologies that we could learn that all do cool stuff, but how do you decide which one is actually going to help you, which is worth your time to invest in? So having some familiarity there kind of makes that learning curve a little easier, and that's one of the things that I think Couchbase is doing to help developers be more product.
BP There's a white whale out there for me– I once found a Reddit thread on our programming, and it was an academic paper about why churn in the IT industry as they called it but they were looking as software developers is so high from individual contributor to manager or product manager. And the answer to your point, Matthew, was that it's one of the careers that demands you to learn new things at such a rapid pace that you have to devote a lot of your time in work or outside of work to keeping current. And people eventually say, “I'd rather be a manager of people and have my skillset,” or, “I'd rather be a product manager and check off my story points.” I just think that's one of the things that's so fascinating about this particular career. I call it the white whale because I'm pretty sure I read this paper, I guess I might have dreamed it, I haven't been able to find it since. But they had empirically shown that churn out of this industry for that particular career role was much higher than comparable careers with comparable pay and levels of education and things like that.
RD So we're talking about the tools and the sort of pace of change in software engineering. I'm wondering if the sort of proliferation of new tools and cloud versus on-prem and all the testing and CI/CD stuff, is that helping developer velocity or is it getting in the way?
MG I'm actually very curious to hear Cory's perspective on on-prem versus cloud, because from my point of view, being able to spin up a service in the cloud without having to go through a bunch of installation and yak shaving, that can be very good for productivity and velocity, that it's someone else who is managing the patches and the bug fixes and all I’ve got to do is just click the go button and then start connecting to the API or whatever and get to work. But I think there's also a case for having something that you can spin up locally in a repeatable way that you might be able to share with the team. So I'm very curious. I know Cory's a little more in the front end area of things so that might color the answer there, but what do you think, Cory?
CH I think if I had to choose a single binary answer, I would say that it's a net gain, but I also recognize that I find it frustrating at least partially because as someone who moves between projects, there's increasingly this expectation that you're going to be comfortable being productive in whatever cloud platform sits out there. And it is not trivial to jump between Azure and Google Cloud and AWS, especially when all of them have dozens of different offerings that are constantly changing. They are specialties in and of themselves. So I've certainly felt the headwind of that and I also feel like on the other side of that coin though, I certainly don't long for the days of having servers sitting in the closet down the hallway and all of the complexities that came with that, because that certainly in the end soaked up way too much of my time as someone who really just wanted to write code. So I love that cloud platforms have made so much more approachable to people. I do have concerns around how it's also very easy to end up wasting way too much money on accident because you left something running. Some of that feels almost deliberately designed in a way that might create that mistake. But I feel like in particular, if I were to pick something that has really improved feedback loops, continuous integration just as a practice is fantastic. But it is a double edged sword too, because I have been on teams where ironically it felt like continuous integration was the thing that was holding us back because people were waiting for a slow CI build before they would move on to a new task. And that CI build, when it starts taking 30 or more minutes, you're going, “Oh boy. Is it really worth waiting at that point?” Maybe you go ahead and move on. So there is certainly an opportunity to find ways to speed those flows and to also not use those as a bottleneck for potentially moving on to the next task.
BP I know both of you have worked at a lot of companies, and Cory, it sounds like you enjoy that freedom of being able to consult on projects. When you go into a company, to what degree as you mentioned with cloud platforms, or Matt, as you mentioned with SQL, do you like to know the environment and that helps you and makes you feel comfortable, gives you developer velocity, and to what degree do you like to bring in custom tooling? Do you think custom tooling within organizations or for yourself specifically is a good thing? Or is that the kind of thing that is going to become a drag on developer velocity because it's going to lead to a lot of folks you're working with being unfamiliar with the tools at hand?
MG I think I've already weigh in that I like familiarity. I've used SQL literally my whole career and even in the NoSQL world I continue to use it. As far as custom tooling goes, I don't have anything against it as long as the reason for it is necessary. I've come into places before as a consultant and they built some sort of custom data center management data access system and it was not necessary to do that at all. It was just a lot of extra work kind of just because the CIO or the CTO had a whim or wanted to get too involved in the code, that sort of thing. So I think as long as the reason for it is necessary I have no problem with a custom developer tool.
BP And Cory, how about you? If you look at something and you're on a team, you've been brought on as a consultant, then they're saying buy versus build, what do you look at to make that decision?
CH I certainly default to buy these days. Although when I say buy, recognize that often the price is free. I really just mean you probably want to start by leaning toward standing on the shoulders of giants and using what's already there, especially in the front end space. It is exceedingly rare to find a situation where there's not something out there that is largely similar to what is needed, and usually on the money if I actually shop around a bit. Now, I do recognize though that there is a place for custom, and the place that I'm finding custom makes sense is around the idea of custom dev tools which has become a focus for me of late. And it's an idea that I'm trying to really evangelize more because it's surprising to me how many teams are still not doing this even though it's not a particularly new idea. And I think partially it's because nobody's found a way yet to create a broad framework for helping this proliferate. Because by definition, custom dev tools have to be made custom based on your situation. And when I talk about these, I'm talking about things like being able to force an error from a particular HTTP request, being able to say that this request should take 500 milliseconds and this one should take 2000, and I want to assert that a spinner shows when this first one's going on here, I want to test the time out of a call, I want to change feature toggles, I want to be able to change between users. All those things tie back to what I was talking about before, this idea of a feedback loop where I want to see the results as quickly as possible. I shouldn't manually have to go log in as a user during development. I should just be able to click a user and I am that person. I should be able to switch between users and override my roles and rights and responsibilities. And also all of that should be capable of interacting with my automated testing tools so that my automated tests merely say, “I want to be this configuration,” and it magically happens. And everything that I just talked about there involves me, the developer, writing a lot of custom code. And again, there are tools that make this story easier, but increasingly what I'm finding as a consultant is that I'm helping companies do what I described there because there's no silver bullet for automating what I just described. Everybody has their own APIs, some are GraphQL, some are Rest, some are Soap, and so on, and everybody has different front end technologies. So that mix and match means that you're really going to need to write custom code to get the sort of behavior I described. But once you do, you're in this wonderful situation where your feedback loop is instant and you don't have to go back to some database for instance, to change data, to be a particular person with these rights, roles, responsibilities. You can just set settings and the application manifests, which is a lot of fun.
BP Yeah. I like the way you described that. You had a lot of passion for it. It's interesting what you said. You do have to go in and figure out how to create this set of tools, this particular suit of armor, this mouse trap for this problem. But once you do, then you can get into the flow state. You can just start making the changes you want and you can just start working through things and you're getting them done very rapidly, and that's not only efficient, as you mentioned before, for a developer, it's enjoyable and then you want to be on that job and you want to work there more. You might recommend it to somebody else. So developer productivity, but also sort of the retention and the way people feel at work, which can have a big impact on their velocity.
RD Speaking again of velocity, the post we ran was based on a comment I saw saying that high velocity is a good pathway to burnout. I'm wondering if there's a way that high velocity turns negative, or if there's a bad way to measure velocity.
CH I think it all hinges on the interpretation of that statement. Because I think what they're really saying is, “Shipping as much code as possible every single day like you're a robot leads to burnout.” And if that's how they interpreted it, then sure. But when you said that statement, that wasn't what popped into my head initially. I was merely thinking about it as actually the 180 of that, which is the more luxurious it is for me to do my job as a developer because I get the answers that I need efficiently, then the less likely I am to burn out because my job doesn't have friction. And that's really what this conversation is about to me– removing friction by making sure that people can get the answers that they want as quickly as possible. And sometimes that's a technical feedback loop and sometimes that's people getting you documentation and assets and code reviews and so on.
MG And I think I would want to check out that article about burnout because to me when I'm coding, I'm enjoying it, I'm happy coding. But there's a certain point in a project or a company where maybe the expectation is to ship X number of features, and shipping those before a certain date would require me to put in 20 hours extra a week, 30 hours extra a week, and so on, and I've been at places like this before. And doing that kind of extra heroic effort is oftentimes rewarded in companies, which I think is unfortunate because it kind of sets the precedent that the best people give up their personal lives and their family time to make sure this product ships, which is I think a sure recipe for either burnout or very unhappy people. So, when you say, “What are some good measurements? What are some bad measurements?” I think again, focusing on the project and the team and not on an individual is a good way to measure it. And you may be worried about a free rider problem there, maybe someone who's not pulling their weight at all, but that should be relatively obvious to the other people on the team without having to look at a graph or a metric to back it up. You just know that they're not putting in the work, they're not putting in the time, they're not being as productive as they could be. But I think that's a relatively rare problem. I think it's more common to worry about people putting in too much time and being driven to do that by project managers or leadership or whoever.
BP Yeah, I think what you say makes a lot of sense. It's all about understanding that you need to set a healthy culture, that if you allow folks to become overly competitive and model that behavior they can burn each other out. So important thing to remember.
[music plays]
BP All right, everybody. It is that time of the show. We want to thank the winner of a lifeboat badge. This was awarded 21 hours ago to Alohci. Thank you Alohci for coming on and getting a lifeboat. You got a question with a score of -3 or less all the way up to a score of 3 or more, and your answer has a score of 20 or more. You explained why the button doesn't appear inline in your CSS. Asked seven years ago and it's been viewed 20,000 times. You've helped a lot of people get their button inline. Matt, for folks who are listening, what's happening at Couchbase, what should they be excited about or looking forward to over the next year?
MG Well, if you work with databases or you want to work with databases, I suggest checking out Couchbase Capella. This is Couchbase’s managed database as a service. So we talked about cloud services, Couchbase is a flexible fusion like I mentioned, some of the best things about relational like SQL and Acid applied to a JSON database. If you want to try out a 30-day free trial, no credit card needed, go to couchbase.com/products/capella. And one other thing I'd like to mention if I could is the Couchbase Playground. So if you don't want to even go this far as to create a cloud account, couchbase.live is a fully in-browser experience for running some interactive code samples, little mini IDE right there in the browser, and interact with Couchbase without leaving your browser of choice. So check that out at couchbase.live.
BP And Cory, for folks who are listening, if they want to check out some of your courses or I know you do a lot of speaking, check out some of your upcoming engagements, where can they learn more?
CH Sure. My courses are published on pluralsight.com. I also speak at lots of conferences across the United States, occasionally overseas as well. You can also find me at reactjsconsulting.com. I do onsite training for front end teams, helping people transition to React, but more broadly just helping improve developer velocity at companies in the front end space.
BP All right, everybody. I am Ben Popper. You can always find me on Twitter @BenPopper. You can always email us with questions or suggestions for the show, podcast@stackoverflow.com. And if you like the show, why don't you leave us a rating and a review. It really helps.
RD I'm Ryan Donovan. I edit the blog here at Stack Overflow. You can find the blog at stackoverflow.blog, and you can find me on Twitter @RThorDonovan.
BP All right, everybody. Thanks for listening and we will talk to you soon.
[outro music plays]