Working with Legacy Code, with Rahul Rajeev

Episode 89 · 40:08 · SRT · archive.org · all Tanzu Talk

Well, here we are at Vox Days in Singapore. It's very exciting. I just saw Josh Long talk. He gives a good, I was noticing he gives like a good 20-minute introduction, just talking about the bird on the book that he has. But it was fun nonetheless. Why don't you introduce yourself? Yeah. Hi, I'm Rahul. I'm a software engineer here at Pivotal Labs Singapore. Just a little bit about myself. I've been part of NEO from before Pivotal acquired us. And so all in all, I've been here for around four years. Oh, that's longer than me. Oh, wow. You know where all the secret bathrooms are. Yeah. So I've seen the office grow from a really small number to a much bigger space, grow into a bigger space. Also have been part of a lot of different projects, everything from like startups to like government agencies to multinational companies that include like banks and have worked in like lots of different domains. Yeah. It's been one of the great things of working at Pivotal Labs. That is an advantage you have like doing work like Pivotal is you get exposed to a whole lot of things. Well, so we were talking earlier about how some of the projects you've worked on, I mean, it's for larger organizations and, you know, a characteristic of large organizations is they tend to make a lot of money, be large. Otherwise, they would be non-existent organizations. That's true. And in the IT area, I always figure like that implies they have a lot of existing software that makes a lot of money. And we call that legacy. Right. And I don't know. I mean, the jokey thing I always think about legacy is like legacy is that software that like you have to change, but you're really afraid to change. Otherwise, you just call it software. But you've had the chance to work on some of those things. And I mean, how would you characterize these legacy systems, the software? I think even before I get into like what I've seen that could be labeled legacy, this very interesting thing that someone told me sometime back that really stuck with me

was computer science is the only place where legacy is used in a negative connotation. You don't say Albert Einstein's legacy as left behind. Yeah, that's funny. Right? So it's a shame that many times when we are building software, we don't think about how it's going. We're not leaving something in a state that is to support the future engineers who are going to help it. And when care is not put into maintaining your software and maintaining a high code quality, it basically becomes really hard for anyone else who's going to be working on it in the future. Yeah. And that is why we call it like label it legacy software. And it's like something that you don't want to mess with. Yeah. Yeah. No one calls it like heritage software. Yeah, basically. Yeah. And so why do you think that is? Why do you think it hasn't become common practice to avoid it going legacy? Like, and as an example of that not happening, I mean, I'm sure we could always as an industry get better at unit testing and testing. But it seems like over the past 15 or so years, it's now part of a developer's mindset that like I do the tests, right? So we somehow fix that. But how has it come about that this creating legacy is still something? I mean, even, I mean, testing is definitely one part of it. So the fundamental thing to think about is when we are talking about testing, the primary goal of testing is to get high confidence. And the reason for high confidence is just to let you refactor more often. And that gives you the freedom to leave your code at a very high quality. So anytime you see something that could be optimized, you could go back in and fix it. So I wouldn't say that just adding tests for the sake of adding tests is going to solve that problem. You need to have the right kind of test to give you the confidence and the freedom to refactor often. Oh, right, right. And oftentimes, what I've seen is although you have tests, the way it is tested is really

rigid, or you're not testing the right things, which are the risky parts of the system, all the tests are so flaky that you can't actually trust your test code base. So in those scenarios, developers tend to be reluctant to go back in and make changes to parts of the code that they don't understand intimately. And that is one of the things I've seen contribute to legacy code very often. Yeah, I guess there is a healthy fear of screwing things up that developers have. But then if you don't have the safety nets of tests in there, which I guess, like, I mean, one of the only books I've ever found about legacy code is, it's pretty old now, but it's that Michael Feathers book. Yes, working effectively with legacy code. Yeah, which starts off with one of my favorite, I don't know, Zen things. You probably remember it too, but it's like, what is it? To change legacy code, we need tests. But then legacy code is code without tests. So what do we do now? Yeah, I think that book has kind of held the test of time. And it's something that we still recommend to clients. Because oftentimes, when people see the practices that we follow, like test-driven development, it is, it seems very intuitive to apply it to something like a greenfield project where you're starting from scratch, when before you write your first line of code, you write your test. That, although it is a mindset shift, it's still something that's easier to palette. Right. But what's harder is, in most cases, like you mentioned, like these big companies that have been making a lot of money and have these systems that have been, they have been working, but they're not, they're not, they're very rigid and people are scared to go. They can't be evolved. They can't be evolved. Yeah. Every change that you need to make to that system takes a lot more time. So in these cases, companies want to know, companies and teams want to know how can they start doing TDD? Do we only test things that we build, like new things we build?

Even then, since you're working with this legacy system, you need some kind of security. So there are some tactical stuff in that book that we still recommend. Yeah. So what are y'all, when you're working with people, what do you recommend for them? And then, you know, part of that is what works well and doesn't work well or is challenging? Like how does it play out? Yeah. So one of the things that I think the book covers really well is that you need to have few really high value automation tests that document the existing functionality so that whenever you are making new changes to the system, you're not breaking existing functionality that other systems are relying on. So that's just like adding like that basic net. But that aside, the main thing that we try to look at is most often these kind of legacy systems tend to be this like very opaque, monolithic applications. We try to go in and find these domain boundaries, trying to find where does it make sense to slice and dice the system so that we can maybe it could be like we rewrite parts of it. We may pull things out and make it separate services, but it's effectively just finding these boundaries that we can wrap more tests around and then slowly like do this iteratively till we are able to make them really well factored code. Right. And if I remember the feather stuff, one of the words he uses is like you find the seams. Like the, and nowadays you would say boundary. Bounded context. Yeah, yeah. And, and, and, and along those lines. So in this context, how do you, how do you figure out those boundaries? I mean, I mean, like, I don't know, you could pick a simple domain, like bill paying or reservations or whatever, but how would you, what's a good example of what a boundary is? Oh, this is, this is a really tough question. I mean, I don't really have a good answer for this, but the way generally when you talk

to one, one thing I like to do is I go to these teams and ask them, okay, why don't you draw, draw me a component diagram? Like, tell me what are the boxes and arrows and just tell me what are the systems that interact with each other. And by systems, I don't mean separate deployments, but it's just like different components. Like what is your mental mark? Yeah. And generally they have a really good sense and you can really extract that out. That's, that's interesting. They sort of like already know the boundaries. They just may not think about it that way. Exactly. So that is already the case. Most often these tend to be really intertwined, but that's where we can help them try to extract it. That is one. If that doesn't help, the other approach is, I really believe in Pivotal's way of having the balance team and we take cues from the design and the product requirements to see what would be a bounded context. So we kind of try to find a ubiquitous language where we have this common terminologies across business, technology, and design. And those terminologies kind of help us, help guide our decision on like whether this makes sense as a bounded context. And so in that instance, is it, is it often the case? So you have, just to simplify it, you've got the, the business's conception of, of the boundaries and then the, the developer's conception of the boundaries. And are those things often the same or do they conflict or how does that line up? I've seen surprisingly, in most cases, they line up closely. Oh, that's great. That is good because generally they get the requirements from the business and they generally use the same terminologies. That is good. The other reason they end up lining up is Conway's law. So the people who are like high up decide, okay, these are the things that I'm, I've been talking about. These are the things I promised my CTO. So I'm going to make these teams. Oh, that makes a lot of sense. So these teams, so Conway's law is that the structure of a code base reflects the communication

pathways of your team. So if you have two different teams and you have like a team that is like a booking team and the other one is a reservation team. So it's so handsome that there's a booking bounded context and the reservation bounded context. The level of separation between these contexts depend on the discipline of the developers in the team itself. But generally that's an easy way to see like, okay, that seems like a scene which you could pull out. Yeah, yeah, yeah, that's interesting because it's, it's very hopeful and, and it's almost like, again, like there's the, there are these latent boundaries that people don't realize they've, they've put that work in for. And then, and in the context of legacy, I imagine it's very helpful because as you're saying, it starts to make that opaque black, black monolith, so to speak, like a lot more understandable. So, so let's say you've broken up a couple of boundaries, then like, what's the next step for, for doing, and, and I always like to ask a question and then keep talking. So it's a pardon that tick, but, but I'm guessing what you do is, so our, our main problem with, with updating legacy stuff is we don't have good enough tests. And so we're trying to break it up so that then we can put tests in place and then we can start changing it. Right. And then, so, so then going back, we found the boundaries, you've got the monolith. So then what do you do? So, um, oftentimes what ends up happening is, uh, what we like to think about, think of as the app continuum. You, when, once you like one end of the app continuum is when you have like, um, uh, opaque monoliths. Monoliths. And the other end is having like lots of well-structured microservices. Right. Because you could have like a distributed monolith, that's a terrible thing, but like, if you think of like completely, um, decoupled services and a monolith as the scale, we are basically trying to shift it towards somewhere in the middle where you want a well-structured, um,

well, um, uh, a monolith that has separation across functional boundaries. And, um, the benefit of doing that is you have testing at multiple levels. So you can have unit testing, you can have integration testing between closely coupled, uh, components, and then you can have like, uh, automation testing for the whole system or even like one extra level of testing for how this system works with other systems that, um, exist in the organization. So, so, I mean, is it, uh, to ask a, it's not obvious, but a simplistic question. Is it, do you find that it's extremely common that people only test outside the box? Like, like for example, if you followed a classic three-tier application thing, I mean, you've got pretty, pretty good boundaries and, and you would expect that people would have tests in between them, but maybe they don't. Actually, uh, that's an interesting one because there we are talking about whether we want to do, how do we find these boundaries? Oftentimes it becomes really easy to say, okay, database is one boundary. My service is one boundary. My controller is another boundary. So this is my three boundaries. I'm going to test between. What we, uh, you could definitely have unit tests for each individual one, but when we're thinking of having like integration tests, you want to split across functional vertical slices. So that's a good insight. Yeah. A little bit of the, uh, database layer, a little bit of the services, a little bit of the controller, but they make sense together. So they all work together to fulfill one user requirement. And I guess that's a characteristic of a, of a boundary in the BDD sense is that it's from the perspective of an end to end process instead of database or controlled here or UI. Because at the end of the day, your controller, the framework you use, the database choice, everything is an implementation detail. And the real crux of the value lies in the business, uh, business models and the domain itself. Okay. And that's, that's what you are customizing for your clients. So, and so I guess in that context, then it would make a lot more sense that people hadn't

thought about these, let's call them, uh, I always get my vertical and horizontal, these vertical slices as, as the boundaries. And people probably haven't been writing tests on, on that boundary, but they might've been writing tests on talking to the database. Exactly. Yes. So, uh, sometimes we see that, um, so it changes from different, um, in different engagements. Like one of the common ones I see is there's just unit testing. There's no integration testing whatsoever because unit testing is easy to understand and easy for devs to start writing. So that's one, the other extreme is there's no unit testing. There's no like, uh, component level testing, but there's like, um, end to end integration testing of user flow. So they basically bring up the whole app and have automation testing where some of the, the code goes and clicks actually physically clicks buttons and type stuff. Just like classic APM stuff. Yeah. Like the classic style of automation testing. So what do they think about? So what often happens is in either one of these scenarios, what, uh, the problem we face is there's no, uh, there's not a really good testing pyramid. So we don't have like a good distribution of, uh, uh, good mix of, uh, having a lot of cheap tests and a few very costly tests, but highly valuable tests, because you want your code base to be, uh, um, your testing, uh, your tests to have high confidence. So you provide you high confidence at the same time, be very cheap because you want to be able to run them as often as possible. And they shouldn't take more than, I don't know, a couple of minutes to execute end to end. So, right. So you want to have as much of your testing done in the lower levels where the cost of each individual test is very small. That makes sense. So you want a lot of unit tests, but you also want to have these very high value, um, integration tests, but very few of them. So you need to be very selective. That makes sense. So having a good balance between these different levels of testing is what I find being, uh,

one of the most common shortcomings of the testing. Yeah. Yeah. Cause I guess it's a kind of a fallacy to think that the, uh, with unit tests, that the sum is greater than the parts, but in fact, the sum is less than the parts. Or, I mean, so to speak, like, like you can't just, you can't just sum up all your unit tests and be done with the whole system. You need to actually write system-wide sort of. There are, there are different, uh, there are different things that you're testing at each level. Right, right. At the unit level, you're just testing each individual unit behaves the way it's expected. At each, um, each level above that, you're trying to see how they interact with the, uh, these units interact with each other and so on. So the, the type of confidence you get at each level of testing is very different and all of them are equally valid. So I, I, I mean, tell me more about this concept of confidence. You keep, uh, you keep mentioning it in, in, in the context of all of this, right? Like what, that sounds interesting, but what, what do you mean by that? Okay. So the, this is something that I've recently been thinking about a lot as well. Um, oftentimes when we start talking to clients about, you know, testing is important, you should make sure that your, your code is all very well tested. Oftentimes they're like, okay, how do I track this? And they jump onto this, uh, vanity metric, what I consider vanity metric, which is code test coverage. Right. So I want to really be careful about when I'm talking about good level of testing. I don't want, I don't mean test coverage. You just need the right amount of testing to give you high confidence because that's the goal at the end of the day. If you are aiming towards getting a test coverage as close to a hundred percent as possible, it's actually, there's like diminishing returns. You just, you can make do with like 80 percent or 90 percent, uh, in different projects. Like I've been on projects where the code coverage has, uh, the test coverage has been like 97 percent. And sometimes it's been down to like 80 or something. But at the end of the day, we, all we want to track is that, um, we are having the confidence to deploy code to production.

As soon as I see a green CIP, I don't want to, if I see green, I should be able to deploy. Right, right. Yeah, that's that like abstracting that several layers up. It seems like there's a ongoing, uh, there's like an, in the area of thought technologies, so to speak, there's an ongoing like tension between, I don't know, absolute thinking versus relative thinking. That's the wrong framing, but it's sort of like, you could think about coverage that you have. You have a hundred percent coverage. So everything's green. Yeah. But do you care? Right. Like, like, just because you have a hundred. It doesn't matter to you. Yeah. It's just a vanity matter. Yeah. Just because you have a hundred percent coverage doesn't actually mean that it's good. So it's, I'm, it's, it's good to make sure you're covering everything, but it's also good to make sure that you're confident that that means your software is of high quality. And so how do, how do you, how do people like track that? Like, do you just ask them or do you do the thing where five people vote and you take the average of it? Or like, how do you figure out what that is? I mean, there are ways, like you can obviously do the voting thing that you talk to the team and ask like, what's our confidence in our test right now? Yeah. But yes, this is one of those difficult things because it's not easy to estimate confidence. Although you have some tells, like one of the easiest ones is if you, if you can ask the data, hey, I see a green CI board. Can I deploy your code to production? And if they're like, yes, that's, that's a sign that, yeah, there is enough confidence. And that's what we are aiming towards. The further away it is from that ideal state, the less reliable your test. That uses like a Nassim Talebian kind of trick, which is like, he would call it skin in the game, which is to say like, if you want to get good, I don't know math stuff, but if you want to get like good probability predictions from someone, you have to make it so that if they're wrong, there's a consequence. Right. And then, and then so they're still going to be wrong because it's probability and stats

and stuff, but like, it at least makes them put in that extra effort. Just like you're saying, you would go to the developer and say like, all right, it's Friday. Can we deploy this code? If something goes wrong, you're going to have to come in on Saturday. Now, if you tell me we can't deploy the code, you can still leave for the weekend. We'll come back on Monday. It's totally fine. Yeah. But I just want to make sure that you're confident in this code. Yeah. I mean, obviously like we don't, I'm not encouraging anyone to come back on Saturday. But I mean, it's just a demonstration of how you have some consequences. It's one of those things because there are a few vanity metrics, like for example, like velocity, right? The actual number of points per week. What you're aiming for is not like crazy high points. You're not saying like, I want to aim for 50 points of velocity this week. What you want is consistency and you want to see it growing week after week. That's what you're aiming for. Similarly, in your test coverage, you want to see a relatively high number, but there is no hard and fast rule that if you are able to hit 95% test coverage, your testing is on point and you don't need to worry about anything else. No, that makes sense. Because I've been in organizations where the technical leadership decided, let's put a number, let's put like 80% test coverage. And if you don't hit 80% test coverage, you can't deploy your code. Yeah. It's really easy to get high test coverage because you can just have one test that exercises all your code and never actually test anything. Yeah, that's true. Exactly. You can reduce the raw number of tests. You can market, you can really get around these kinds of metrics. And as engineers, we are really smart and we find easy solutions to solve these problems. Right, right. But getting a high test coverage number, it shouldn't be the goal of the team. It's a happy side effect. Right, right. And so, all right. So, we found our seams or our boundaries, we've got some tests in, and we have confidence that we could do these changes. So, then what do you do? Like, how do you, I assume the next step is you actually make the changes?

I mean, we are making changes all throughout this. Right, right. We don't just say, okay, let's take two months to sit and refactor all your code before we start making changes. Okay, okay. So, in general, what we like to do is we start with something, we start with one single user functionality that we have talked to users, we have validated it, something that's important. We have made sure that businesses invested in trying to solve this one problem for their users, and we start by implementing that new functionality, and along the way, slowly refactor the parts of the existing code that this new piece of code touches, and so on and so forth. And we slowly want to change as much as possible, but it starts with that one seed. We don't want to go boil the ocean, we want to start small. Right, right. So, you sort of attack, correct me if I'm wrong, but you attack the big picture of testing, right? Like, we have to test it, we have to be confident that we can test the whole system. We add some level of, because at the end, again, we need confidence. And then very early on, when you've identified some boundary, you actually go in and start making changes to the code. Yeah. Almost, maybe not exactly in parallel, but very early on. Yeah. And then you have overall confidence that the system can be checked, and you're really adding more tests to that little component that you have. And what do you find, like, I don't know, like, what's the oldest type of code that you found that you go in and change? Oldest type of code? Or not type, but like, do you go in and you're like, oh, this was written 10 years ago, and you have to change your... I've actually been part of a project where we were trying to replace something that was written 15 to 20 years ago? Mm-hmm. It's a really old piece of code, but we kind of, the... It was written in a mainframe system, and the decision was made that we will replace it rather than trying to update parts of it. Right. Because it no longer made sense to do that. So, it was part of, like, a slow replacement.

So, because this was a backend system, we could go by API endpoint by API endpoint. Oh, right. So, you could just replace the actual implementation between the API... Yeah. So, we would just, like, route the new API endpoints to our system. Right, right, right. We could do that. Okay. So, that's sort of a way, if you have to make a decision, like, we're going to rewrite this code, or, you know, update the code, or we're just... Let me rephrase that. We're going to modify this code versus we're just going to rewrite it. We're going to, like, get rid of it totally. I mean, it's always a decision, yeah. Yeah. I am wary of just asking people to just rewrite whatever doesn't work. Yeah, it's expensive. It's very expensive. And, basically, although you would be getting a lot of velocity and everyone is happy, devs are happy, in reality, users are not getting any new value. You have to first reach, like, at least value parity to the existing system before you're able to provide new value. Yeah. Right? So, you would spend... You're expecting your clients and the dev teams to invest months or maybe even, like, years of effort trying to replace the system and doing the whole time the company is not releasing new functionality. Yeah, and then the software just acts exactly like it did before. This is scary. Yeah, exactly. So, you don't want that. So, there has to be a very clear reason, there has to be a very clear goal for why we are doing what. Yeah, that's always a part of... And we're not the only ones to do it. But part of the labs process and overall pivotal approach, I think, is good is, like, someone should care, right? Yeah. Like you were saying early on, like, you need to identify the business side of things and find out what they need to happen. And that's ultimately what you're servicing, right? Like, if you've got to do all this rigmarole that we talked about of updating legacy code, the end is still, like, we need to make the software better, not just update it or whatever, which I think that's really easy for people to track up. And then also, it's not only the nerd's fault, it's also, like, the business people, they need to know that they should be involved in that and be pushing for it, that they should expect

it. Yeah. I mean, oftentimes, in our projects, the technical aspects are not the most challenging things to overcome. It's often just changing the mindset or trying to make sure that the different parts of the business and the different parts of business, IT, design, user support, all of them are working together on trying to solve something. So, the thing I like to remind devs is that, you know, anything can be built, but should it be built is the question. That's right. Yeah, you could do whatever you want. And so, in doing this work, are there sort of, like, common tools that you end up using a lot and that come up? Like, what, like, like, if you were to get your, I guess, in the world of software, it's metaphoric, but your metaphoric toolbox together. Like, like, what are the things that you try, you typically want to start with? Like, do you have, like, code scanners or, like, do you use a lot of, like, you know, auto refactoring things or you right click on a mouse button and it does stuff or like, what? I don't even know. So, what are the things that come up over and over again? There's a lot of different tools that we use. I mean, but we keep it really light for the most part. So, we do, I like IntelliJ and it comes with lots of- Everyone around here seems to like that. Yeah, exactly. So, I like IntelliJ and it's an easy way. It's good to, since just stepping back one step is one of the things that we try to focus on is pairing and that is our way of introducing new concepts and making sure that we are able to ramp up new devs or, like, our counterparts from the client side. And when we're doing pairing, it's often nice to come up with a shared understanding on the tools, languages, and frameworks that we're going to use for this duration so that everyone is comfortable. So, I can't be writing in Vim while my pair wants to work with Emacs. It's not going to work. So, we both have to, like, one person has to be like, okay, I'll work in your way. Yeah.

So, oftentimes we come to that agreement on what tools we use and we try to standardize at least, like, some things around, like, code style or just, like, auto-refactoring. IntelliJ does a really good job because you have plugins that do that. Right. So, like, you can have the Google Java styling if you're using Java. Similarly, JavaScript has lots of different style existing available style guides that you can use. So, that just makes sure that the code looks similar from different pairs. And it's one of those low-hanging fruits that really helps the readability of your code base. Other than that, one of the other tools that we set up very early on in our system is having a repository and having a continuous integration system. So, one of the happy side effects of test-driven development is that you have a lot of tests and good coverage and you can rely on a machine to run your tests every time anyone makes changes to the code base. Right. And the CI will be our automated pipeline that promotes code between different environments. And each time it promotes the code and it gets closer to production, the level of confidence in that particular build is higher and higher. Yeah. And once you're happy and everybody is, like, signed off, you can just automatically just deploy it to product. So, it should... We try to make it as seamless as possible to get to production because getting to production is as easily as possible is very important. Yeah, yeah. Because it shouldn't be something that, like, okay, fine, let's all stop work. Let's freeze our code today. And then next one week, we are just going to do prod support. We don't want that. We don't want it to be a big ceremony. We just want it to be, like, a regular thing that we can do anytime. Yeah, that makes sense. That makes sense. So, as part of these processes, sometimes we do have some tools that can do, like, security vulnerability checks. It can do, like, test coverage, just one thing.

We sometimes, especially when we're working with really old systems, which we don't fully understand, with lots of conditionals and things like that, we sometimes opt in for a mutation testing tool. Wait, what's that? This one, these are some tools that can, what it does, it goes through your actual code. And oftentimes, when you're doing test coverage, it's a static analysis. It looks at the lines of code that are being executed. But when you do look at mutation testing tools, it goes through all the possible code parts. Oh, okay. All the possible execution parts in your code, and then it flips some ifs here and there, and sees if any of your tests have broken. That's interesting. So, suppose you flip an if, like, a fork in your logic, and nothing breaks. That means there's one part of the logic that is not being tested. And it will give you a report that talks about it. So, it's a really interesting tool. I've used it only once, and, yeah, it was for a very specific module, which we didn't have visibility on. I'm not really sure how it scales. I've never tried it. Yeah, yeah, yeah. It seems like with certain types of code bases, it would run longer than we live. Yeah, and, yeah, that's it. We try to keep it really light. Most of the other things that we introduce, most of the other practices are some things that we introduce while working together. So, we have a lot of whiteboards, so we try to jump up there and draw lines and boxes to have these shared conversations. We have regular retros to understand what the team's feeling. Yeah. Lots of meatware, as it were. Exactly. And so, I mean, when you're working with older languages, do you need, like, tools to, like, comprehend COBOL or something? Or, like, does that ever come up? Luckily, I've never had to work with COBOL, but there have been some clients who have come to us asking about, like, working in these kind of older technologies.

We would like to have some domain experts and maybe language experts embedded into the team so that we are able to, you know, help each other out in making sure that the clients are successful. Yeah. My understanding of COBOL is as long as you keep the cap slot key on, then you're an expert at it. You just need to do that. Yeah. And oftentimes, if you're working with COBOL, it's not just the COBOL. It also comes in, like, a mainframe. It's all the ancillary stuff. Yeah, yeah, yeah. And it's, like, deploying things to it is really difficult. And working, if you're not working on-site, it's very difficult. So there's lots of challenges. Right. And we try to resolve them case by case. So then finally, before we wrap up. Okay. So as you're going through this process, like, and you mentioned a little bit of this, but what are, like, what's your sort of, like, starting amount of, let's, I don't want to say just metrics, but the reporting that you do. Like, you know, you've got the test coverage and you might have reporting about the confidence that you have, but are there other things that come up when you're in the meeting with the managers or, you know, meeting with yourself is one thing in retros. But, like, when it's time for the monthly review of should you still get funding and how is this going? Like, what do you present to those people? So at the end of the day, what we present is the real product. So if you're deploying often enough, we always show the real product and be like, here it is. Feel free to play with it. We try to steer clear of reports because often they give you a false sense of predictability This is just like a unit test coverage stuff, right? Like, you get obsessed with the report. Yeah. But at the same time, we are working with organizations that have been doing these strict deadlines, burn down charts, burn up charts, whatever. So we can obviously generate these reports. We use tools like Tracker has a really detailed analytics tool that lets you see how you're progressing

through the different stories and different features, which is something that we can use. But in general, we try to steer clear of those. Well, just reporting on the work being done. I mean, it's generally good enough and whichever direction you're burning, like that would make sense because then it seems like the conceptual thing you have to tell people is this is representative of us delivering features basically, right? Every time we complete one of these tasks, it gets us closer to business value or whatever. And that's what the task represents. Each one is user value. Right. And every point that you're delivering is one point of user value. Right, right. And it's definitely a mindset shift. It is oftentimes difficult conversations, but clients generally trust us because they are coming to Pivotal Labs for a reason. And oftentimes what we tell them is this is going to be very weird. This is going to be uncomfortable. You just have to trust in us. Try it for a couple months and you will really see the value in it. And that's what I tell all my client devs and my peers when we're working on a project. All right. Well, how long have you been living in Singapore? I've been in Singapore for now eight years. Oh, eight years. So pretty long. Wow. So when you came here and you've been here this whole time, what is one food item that they only have here? Or it could also be a food item that's elsewhere, but it's in a certain style here. Or is there not one? Singapore, the beautiful thing about Singapore is that it's like a cultural melting pot. You get cuisines from pretty much anywhere in the world. And sometimes it's like a slightly different take on everything. For example, we have Indian food in Singapore. It's like from, it's kind of Malaysian Indian food. Right, right. It's like Pratas and Roti John.

It's like a very different thing from Indian food from India. Right, it's sort of like American Chinese food. Basically, that's one. You also have chicken rice, which people always tout as the one thing you have to try. So what's chicken rice? Oh, chicken rice. It's basically boiled chicken on top of fragrant rice. Oh, okay, okay. It's relatively healthy. And it's delicious as well. I bet it's healthier than those like hanging slabs of bacon that I see everywhere. Yeah, you get that as well. Right, right. One of my favorite combination in Singapore, just because of the diversity, is you get like really good craft beer with dim sum from like, you know, Chinese dim sum and malay satay. Put these together, it's a delicious meal. Oh, yeah. So then along those lines, the other thing I'm always interested in is like how people go up the ceremony of how they eat things, right? And, you know, like for example, well, let me ask you this one. You probably figured this out. It's popular here in Singapore and elsewhere. You get one of those big cast iron pots that's all like sizzling. There's even in the mall, there's like this little strip that's like, cook it your way or whatever, but like, so how do you operate that? So I get one of these meals with this pot, it's all sizzling and usually it's dry. Let's just take the dry one. There's no soup and each thing is kind of perfectly compartmentalized on its own. And I might have some little side condiments. Like what do I do with that? I think, I don't think I've received like official instruction on how to do this, but generally what I end up doing is I just let the meat cook with some of the condiments on it. Oh, that's you flavor the meat as it's cooking. Yeah, I flavor the meat as it's cooking. That's good. Yeah. It's delicious. Okay. And you cook it to the level you want. And once you're pretty much happy with how cooked it is, you can just mix it all together and then... I see.

That's fascinating. So the whole point is the meat is still cooking. Yeah. I'm repeating back what you said and you season it with the condiments and then the act of mixing it with everything else cools it down and stops the cooking and then you can eat it. Yep. Wow. That's a good idea. That's kind of like the, you know, when you go to Korean barbecue and you get the uncooked stuff and you cook it exactly the way you want. It's similar. But I don't think it's like a Singaporean thing per se. I'm sure that's the way it works everywhere. Yeah. The hot plate that you're talking about, I think it's a Japanese thing. Yeah. It's at Korean restaurants a lot too. It's a Korean. Okay. Yeah. Well, I mean, it could be both, but that's where I always get it at a Korean restaurant. That's awesome. All right. Well, that's good. Well, if people wanted to, I don't know, catch up with you or see what you're doing, you got like a Twitter account or anything like that? I'm not really active on Twitter, but my Twitter handle is, it's Rahul Rajiv without any of the bubbles in it. So it's just R-H-L-R-J-V. And that's the same as my GitHub account. And if you are hearing this from inside Pivotal or even outside, my email is rrajiv at pivotal.io. Well, there you go. Well, thanks. Well, thanks for going over this. It was great. Sure thing. It's great talking to you. Well, as always, this has been Pivotal Conversations. If you want to get all the old episodes, you can go to soundcloud.com slash Pivotal Conversations. And we also post show notes somewhere. I know, at pivotal.io slash podcast. Usually every Thursday or as I do nowadays whenever I get around to it. So we'll see everyone next time. Bye-bye.

Tanzu Talk · 🍕 Get more pizza.