You just do a good enough job and then the code tests itself and then stuff like that. I think it's a positive indicator of people acknowledging that they do spend do need at least more time to keep things in check and to ensure that the code-based project and a piece of technology grows in a steady way.
Yeah, there is hope that not only shipping code is the way to go. Also taking care of the rest and how it integrates is a big important role.
We also have some questions from the audience and I'm gonna just go to them. And the first one would be, which tool are you using to go through this process or tools, if more? So, yeah, it's a good question. I guess if it's about specifically, specific tools that help you in these processes, unfortunately, it is a quite like a human-centric process because in my mind, okay, if you have tools, for example, for things that I talked about, like maintaining a certain level of code quality of coding guidelines. If there are things that can be automated then it's not even worth mentioning the process. Like you just have all the formatters, you have linters, you have CI pipelines that kind of validate everything and just keep things in check.
For everything that cannot be automated, it means that also there's not really a tool that can highlight things. You can start looking at things like code complexity, but I would say, always take that with a pinch of salt, make sure it's not like the, you don't just, you can have tools that help you, but you can never rely 100% on tools if there are things that cannot be fully automated. For example, we did rely on things like the node prune is one package that you can run on bigger code basis to just give you packages and modules that are unused, that sometimes some of those things are not easily spotted. So, there are some solutions out there, but unfortunately I would say the vast majority of processes that I talked about are kind of manual and require some sort of human ownership, so to say.
Indeed, indeed. And now that you mentioned human insight, Marie Kondo got appreciation. Ah, nice. People said that they loved that you call it the Marie Kondo method, but it seems that this person doesn't have necessarily issues to convince the business side that they need tech depth done. But in general, what would be your approach into convincing the product manager, the product owner that tech depth should be considered more and should be just not just brushed away?
Well, I think the classic, a classic answer for that is, you know, always, if you need, like if you don't have, you know, the ownership over that, if you need to convince someone, you probably will most likely convince them with some sort of numbers, graphs, like just the idea that hey, you know, six months ago or one year ago we were shipping features at this rate, now we're shipping at that rate, and like, this is a difference. And this is, you know, we clearly have a problem, you know, developer experience has been slowing down or things like that.
Yeah, I think I'm personally fortunate to have worked in the past years in an environment where I think everyone is kind of on board on this, so it's more like about the ownership. Like we more, most, it's more like about us having to take the ownership to doing the process rather than having to ask permission for it or something like that. But yeah, there's always, I think there are always metrics that you can pull from how fast people are delivering. You can also get just the, get the feeling of how the team feels about things. Just have a, if you're in a position to do that, have like a one-on-one with each engineer in the team and just have the common concerns voiced for everyone. So it's clear that it's got like a common front that the team does against this problem that's growing.
Yeah, István, what I was saying this is that I wanted to mention that sometimes it's also mentioning the risks and put yourself in the situation that the product owner, product person will see that something is going wrong because of this. And we literally got the question right now as it's big related to that. That isn't it irrelevant to product some of the certain refactoring tasks may take place a long while the feature development, meaning that we mentioned that we can decide and put this time but for product they could literally take off the table that. Why should it be distinct and visible to product teams?
So when I mean product teams, I mean, it should be visible to everyone that's concerned with them. So like, it's not like, you know, some engineer in the shadow does the refactoring and others just to prove it.