Transcript
Speaker: Hello, hello.
Speaker: It's Artistry of Code again, including Artur Wolny, Grzegorz Godlewski and Mark Urbanowicz.
Speaker: In the episode number 23, we're going to talk about some important decision that almost every developer at least once in his life needed to make together with his team, maybe with Architect, which is the decision between picking the brand new
Speaker: designed but unknown, unfamiliar for the team solution versus implementing its own solution using the tools that the team already knows.
Speaker: Before we start, remember to follow us on Instagram, Facebook and on other social platforms and subscribe our channel on YouTube, follow us on Spotify and other podcast platforms.
Speaker: Here we go.
Speaker: Welcome to the Artistry of Code podcast, where we, together with our guests, are seeking ways of doing things right and having fun with it.
Speaker: Software, architecture, soft skills, teamwork and other crazy buzzwords.
Speaker: Are you ready?
Speaker: Let's bring more value to the business.
Speaker: Okay, guys, so I know that each of us, at least once in their life, had this opportunity to make that decision between something brand new and something we already know, including me.
Speaker: Even quite recently, I had some...
Speaker: decision to make when implementing the log streaming functionality.
Speaker: In my case, I also needed to make some decision to make the development faster and deliver the proposed scope as fast as possible, optimizing the resources needed, human resources.
Speaker: of course.
Speaker: So I could choose between implementing some custom-made solution in the Node.js, our beloved Node.js to connect the log stream to
Speaker: in particular outputs like CoreLogix, Logs.io, Splunk, or other services, versus using some known tools that we already have, including data pipelines tools.
Speaker: In my case, that wasn't that easy, especially when the time is short.
Speaker: And finally, I made that choice to try out a new solution, which is actually very interesting because it brings new challenges.
Speaker: But guys, tell me, what are your experiences with that problem?
Speaker: What examples can you give from your career?
Speaker: I can recall the example from the past, which wasn't really about the completely new project, but it was about addressing the issues with the existing project.
Speaker: So with the
Speaker: quite large IoT platform, we were struggling with the performance and the resource consumption and everything around it.
Speaker: There was the proposal to maybe switch to the new language.
Speaker: In that case, it was Go, Golang proposed.
Speaker: And we had one enthusiast who was trying to push this forward, which was for sure interesting for him and for us as well.
Speaker: But in the end, even though we saw the benefits of this potential move, in the end, it wasn't really followed this way because the lack maybe of time for all the developers
Speaker: who would have to learn the completely new language, which would be a big challenge for the maintenance, for sure.
Speaker: And also maybe from the company as well, because the learning curve for the whole team would be quite high and would incur quite a cost.
Speaker: Yes, so Marek, in this example, you actually have chosen the new tool and try it out.
Speaker: Can you tell us how it went?
Speaker: What was the feedback from developers?
Speaker: I would say that the feedback at the beginning was like people were interested.
Speaker: I was also interested in like learning something new.
Speaker: But in the end, it was the outcome was that we mostly focused on improving the existing solution with the
Speaker: tools in Node and basically improving the whole code in TypeScript and improving the solution architecture and everything instead of switching to the new language.
Speaker: And the outcome, I would say, was pretty good even without switching the language.
Speaker: Yeah, so we're finding ourselves quite frequently in the situations that we have to choose.
Speaker: What do we do next?
Speaker: How do we act in terms of choosing technology, solutions, languages?
Speaker: And each and every of us has a set of drivers which are helping out in that decision making.
Speaker: Some of them are business related, specifically if we need to have a short time to market, probably.
Speaker: trying to take something new, which we don't know, without any external consultancy or any even borrowed expert on the team, which is going to bring us up to the speed with that technology, probably is not going to like...
Speaker: function.
Speaker: Nice thing about the example which you guys give in regarding trying to switch in the middle of the project to go that was actually blocked due to organizational aspects.
Speaker: Like when you start to ask yourself a question, OK, if I'm having a team of like 20 developers which are fluent in Node.js and only one enthusiast will go.
Speaker: Am I going to build up the product on the foundation of a single person which might leave the company?
Speaker: Do I plan to hire additional gold developers in order to support the product, which was at that time already productive?
Speaker: So it was in production, right?
Speaker: So these were like some organizational aspects which definitely played a part here.
Speaker: Yeah, it's an important driver and we also mentioned that when we were in some previous episode, we were talking about some hype on technologies and it's actually undoable to quickly switch from one language to another in the team.
Speaker: I also am thinking about
Speaker: the organization aspect of other teams around because usually developer teams are focused on creating the code, creating the solutions, and then we have some kind of maintenance DevOps teams that needs to create a deployment procedure for the application.
Speaker: And it might be another challenge for them to cope with the new technology, new aspects.
Speaker: Of course, we might say, okay, but it's like if we as a team provide the artifact like container image, for example, then it may be slightly easier, but it's not only about deployment.
Speaker: It's also a problem solving on production.
Speaker: With new technology comes new problems.
Speaker: that we will need to solve.
Speaker: Yeah, and that's like being mindful of others and the long-term consequences of those technical choices is very, very important, right?
Speaker: So when I'm running a team, I typically tend to lean towards to technologies and solutions which the team in its current form can support.
Speaker: So if I'm not having people around which are
Speaker: knowledgeable enough about certain piece of technology which we choose i definitely discard this on one hand due to the fact that i'm asking myself the question if that person is going to be woken up by an on-call phone like in the middle of the night will they be able to deal with the problem or will just have the problem till the next morning and then perhaps we're going to have some external help from the vendor or somebody from the support on the vendor side to help us out right so these are like
Speaker: things which you might not think of as a developer, but I think you definitely should.
Speaker: Because we as developers, we like new thingies.
Speaker: We like to write code, but we tend to be very isolated in our thinking and not consider the long term there.
Speaker: So for me specifically, when it comes to choosing the tag, I'm totally driven by the organization.
Speaker: So if we have to deliver,
Speaker: something on some time, then I'm going to pick the solutions which are going to secure that delivery date, so to speak.
Speaker: And that I will choose technologies which I feel will be feeling confident with when they're in production so that I can say with enough confidence, yeah, I'm okay with having that there and I'm going to support that and I know that my team members will also.
Speaker: Yeah, I totally support this sentence.
Speaker: But on the other side, I would just say that sometimes I can recall some cases that the learning for the team can be required because it depends on the members of the team.
Speaker: It can end up that we don't have the knowledge in the team yet around something.
Speaker: But during the decision making process, we can find out
Speaker: that this is really like the best and the one solution and going with something which we know isn't really a good step because it will give more tech depth, for example, instead of giving that the proper solution.
Speaker: So this is like something which we should also consider during making the decision.
Speaker: That's very important thing that you mentioned.
Speaker: And I actually reminded some sentence from my pajamas, which was stated and I could see it in the mirror for quite a time, which was said, each and every achievement started with a decision to try.
Speaker: Yeah, so that's a very important thing.
Speaker: If you want to try, at least, you know, creating a PLC, we won't actually know
Speaker: what might be the outcome.
Speaker: So it's probably worth a try.
Speaker: The POC is quite a good idea for it.
Speaker: If we, of course, have time for the POC, if we are given that opportunity by the business, we need to follow that.
Speaker: And that's important thing, keep the timeframe given by the business because it might be our last POC otherwise.
Speaker: The POCs are a very nice thing in order to try things out.
Speaker: And I definitely see it as a thing to do so that we expand and we allow people to learn and allow the teams to grow.
Speaker: The thing is, like you've rightfully stated, Arthur, it's all about timing.
Speaker: So if you know that
Speaker: you're running a project which is like really having a three months run time and after three months this might not be even used by anyone because you're trying to check if you have a market fit with your solution.
Speaker: Probably going with the things which you don't know isn't a good idea.
Speaker: And also this time span is not good for learning.
Speaker: I mean, the organization wants to learn if this problem, a solution fit together, right?
Speaker: this is where we focus on but if we're running a product and that product has long-term visions right not like very short-term but long-term visions then it makes a lot of sense to try out new things in a poc form and what i also saw happening and i think this is the right way of doing things really is that if you have enthusiasts which are trying to do a poc they will learn something but
Speaker: at some point, it's very advised to take an expert from outside of your organization and put it in on the team for a period of time so he can really help in deploying the technology in the project.
Speaker: Because when you're about to start with a new tech,
Speaker: You probably need an expert who's going to do some knowledge transfer, who's going to bring you up to speed.
Speaker: So for me, that's the advised path to externalize that learning.
Speaker: So you need to have a teacher to learn you.
Speaker: Otherwise, you can learn on your mistakes and trial and error.
Speaker: That's fine if the company is going to be fine with it, if there is no time scale necessary here.
Speaker: But I found it very frequent that we hire experts from places like Microsoft.
Speaker: So if you had Azure, you had some black belts in Microsoft, you had an enterprise agreement, and then you get some help from those black belts, specifically from the vendor.
Speaker: So that's one of the paths which I used to utilize.
Speaker: We had this opportunity together to participate in one of those POC sessions.
Speaker: But I also need to show you, maybe we will attach it to the description, the GIF that was showing how the help of external consultants in the company looks like.
Speaker: It's quite funny.
Speaker: So hopefully I will manage to find it.
Speaker: If not, we will cut it from this recording.
Speaker: So if you hear this, the gif is in the description.
Speaker: But what I liked also from your sentence, quite a long set of sentences, was when you need to check the market if your solution fits, it might be beneficial to start with some, even not the perfect implementation, but including the tools, using the tools that you know.
Speaker: So let's say some simple solution in technology
Speaker: the Node.js if you're working in Node.js on a daily basis because you're going to deliver it quite fast.
Speaker: It will most probably satisfy some subset of clients that you will, for example, give it as a beta feature or some closed beta feature.
Speaker: or distribute it using the A-B tests or other feature flight-based solution for a limited amount of clients.
Speaker: So you can check if they're actually liking it, if it fits their needs.
Speaker: And then in the process, when you see that it's actually, they caught the bite, then you can create the POC with some right tool for the job.
Speaker: So designed tool for the job and gather information about it.
Speaker: Yeah, I would say that this approach, like with maybe even step further, like doing full A-B testing, maybe if the organization allows it.
Speaker: So we have time, we have money for this.
Speaker: And we have like two, maybe three ideas even to pursue.
Speaker: This is like the perfect world for developers.
Speaker: We can do like two or three different solutions.
Speaker: put it on A, B or C testing, see the performance, see the user experience, because it may vary also for some reason, and then make a decision based on some metrics and all that stuff.
Speaker: But yeah, this is not often the case.
Speaker: Yeah.
Speaker: of the money.
Speaker: Most importantly, it's not always the developer's decision, right?
Speaker: So doing this way of doing things, really, a movement of the whole organization, because you need to collect those.
Speaker: And I kind of think that we as developers
Speaker: we rather tend to have a smaller area for like decisions specifically.
Speaker: And one thing came to my mind when you guys were talking about the like trying things out in a like simple form.
Speaker: I think what can be leveraged in such situations is really clean architecture.
Speaker: And what I mean by that is that if you know that
Speaker: if you're having your application and then you have a new problem to solve, like let's say that's the log aggregation shipping stuff or implementation of a PubSub, you essentially know that you probably would like to have messaging.
Speaker: Let's assume you've did the homework and you know that you need to have messaging.
Speaker: But in a moment, you're going to have to choose whether you're going to use Redis PubSub, RabbitMQ, Kafka, even Hubs, whatever.
Speaker: Now, what you can do in order to secure
Speaker: your code base a little bit is to really abstract or provide proper interfaces in your application.
Speaker: So you probably would orient your application towards send a message or send a notification and then delegate all the details into the particular implementation of that interface.
Speaker: So that you can deliver your business
Speaker: With Redis, so let's say you're most fluent in Redis, so you would like to implement this using Redis PubSub.
Speaker: Fine.
Speaker: Just make sure that you're going to abstract this on an interface level so that if you have a customer service, it's going to have a dependency on a messaging service which has very simple methods.
Speaker: And then you hook in the Redis implementation behind.
Speaker: And later, if you recognize during A-B testing or whatever that, OK, we're going to go with Rabbit, you try to swap it.
Speaker: That doesn't go always so smooth, but it increases the changes.
Speaker: Yeah, that's a nice way from the books how to behave and to be open for another changes in the application without the need of reorganizing everything on the way.
Speaker: But it's not that easy, unfortunately.
Speaker: And especially in startups, sometimes you...
Speaker: There's a feeling like some technical decisions are almost written in the stone and doing some adjustments to be open to other possibilities is not always welcomed.
Speaker: But yeah, we developers learn when we really need to do it and then it costs like twice the price than it could.
Speaker: Okay, Gary, so I felt that we went from the aspects of decision to actually approaching the decision.
Speaker: So now to summarize it, I would like to ask you, in what situations would you pick brand new solution designed to solve the problem?
Speaker: I would pick it or at least consider it, put it on the table if I would have knowledge in the team, for sure.
Speaker: And if I would have a confidence that we can support it, if I wouldn't have it at that point in time.
Speaker: And we would end up, for example, with the conclusion that we shouldn't pick anything else because this is like the best one and anything else will be like,
Speaker: a hack or something i would first like if we would have time i would like allow to like maybe get some trainings maybe get the knowledge in the team and sure that like with us the team not as like one or two developers as a team we feel confident with this solution and that we will be able to maintain it and support it because even the shiniest solution won't work if we won't be able to support it yet
Speaker: I would also add to this that if we have enough time, so if we know that, for example, the feature that we are going to deliver is not crucial for the company, it's not critical one, and our brief estimation says that we have enough time to try out new things without a fear that we will not deliver.
Speaker: Yeah, I think it's similar to everything almost in the software development, like always to be pragmatic.
Speaker: So, yes, I find myself often in the situations where the best approach is to like talk with the organization, talk with the team and like sometimes often decide that, yeah, go with some simple stuff first.
Speaker: and follow with the better solution later on.
Speaker: So deliver what we have to deliver to the customers, deliver what we have to deliver to the business, and then follow with the better solution.
Speaker: When it comes to me picking a new tool for the job, that's possible when I feel confident that this is going to, with high success, fit to the problem.
Speaker: Because sometimes I can think like,
Speaker: I can think that GraphQL is going to be a solution.
Speaker: No, I need to know it.
Speaker: And in order to know it, I need to do some reading.
Speaker: I probably need to try it out on localhost, not with my product.
Speaker: This is typically what I do, is that when I'm having a new piece, I firstly create a small side project.
Speaker: just to try it out with like a hello world example some very simple concepts because if i would try to test it with my product i'm going to have the whole overhead of mine product right now in order to quickly assess that so i'm firstly doing a lot of reading and i'm trying to you know like have a feeling about this by having a very simple project like super simple project with it
Speaker: And if I gain confidence that I understand this and I feel that this is getting me where I wanted to be in terms of it's really going to solve my problem, then it's fine.
Speaker: Adding to the thing which you talked about, having the time.
Speaker: If I'm having a five-week project and I'm right now having a five-week project at Gollum,
Speaker: I'm not going to choose things which I'm not knowledgeable of.
Speaker: But if I have the time for it and I will do some reading and I'm going to make myself sure that I'm able to do it with this, then it's fine.
Speaker: And that's also very important that
Speaker: I learned this knowledge first because in a moment I'm going to try to sell it to the rest of the team.
Speaker: And if I want to understand this and I will get questions, it's going to look really wrong if I'm trying to introduce a technology to the team while not even looking as an initial expert in that field.
Speaker: So yeah, that piece is very important for me.
Speaker: So making things understood for me so that I
Speaker: I verify that that's going to fit, and then I can take it to the next level.
Speaker: Now let's take it opposite when you think it's better to pick the technology that we already know.
Speaker: and I will let myself start it.
Speaker: So I think that when you don't have certainty that the new solution that you consider is going to deliver exactly what you need because you can't
Speaker: figure it out from documentation or you didn't create a POC like Grzegorz mentioned, then it's most probably better to stay with what you have and start with this approach, deliver MVP, and then think about switching to something better if it does not perform well.
Speaker: I would stay with the current solution, which is like, for example, working production already.
Speaker: If the cost of the change doesn't justify basically the move, because we have to make the proper decision, put the cost on the table, put the benefits on the table.
Speaker: And as more radical the change is, I would expect really big and drastic changes in terms of the quality, the performance and everything.
Speaker: So, yeah, and always like check to the organizational aspect, not just the technical one.
Speaker: And for me, the time and the value to be delivered is the main factor.
Speaker: So if I'm having a very short delivery time, like in weeks, then I definitely stick with what I know instead of new things.
Speaker: The other situation is what I don't feel confident about using the new thing.
Speaker: And by confidence, it's not only what I've explained earlier that I need to do like the POC and reading and understand stuff like that.
Speaker: But sometimes let's put it into an example.
Speaker: If you're willing to or wanting to exchange the messaging solution, that's probably touches like a myriad of places in the system.
Speaker: So if you don't foresee the consequence or all the necessary changes,
Speaker: for that move and a lot of people get affected.
Speaker: Well, probably I need to be more sure.
Speaker: I need to have this more thought through in order to proceed with this idea.
Speaker: So I'm not going to go with it.
Speaker: So for me, like in cases like that, I stay.
Speaker: I will simply stay with things that I know.
Speaker: This might sometimes be discardable work.
Speaker: Like, so I'm going to do things just for the time reasons which other things may do fine out of the box.
Speaker: Okay.
Speaker: But me doing this with that thing is going to take twice or twice longer.
Speaker: So that's the reason why I probably skipped.
Speaker: Sometimes a good feeling when you are trusting in yourself might be a good advisor.
Speaker: Some businessmen said that usually engineers are not good businessmen because they need to analyze everything while good businessmen make a decision in seconds.
Speaker: So guys, thank you for that.
Speaker: I think we reached the end of this episode.
Speaker: Thank you for your insights, for your experiences.
Speaker: And now, our dear listeners, it's time for you to share with us your experiences, your thoughts on what we said.
Speaker: So don't hesitate to leave us a comment, to follow us on our social platforms and talk to us.
Speaker: Yeah, we are.
Speaker: willing to hear your feedback on the topic.
Speaker: So thank you very much.
Speaker: See you next time.
Speaker: Bye bye.
Speaker: Take care.
Speaker: Bye bye.
Speaker: Make good decisions.
Speaker: Bye bye.
Speaker: That's all for today.
Speaker: Thanks for spending your time with us.
Speaker: Visit our page on Facebook and Twitter, leave us a comment under the episode, subscribe to the updates and share it with others.
Speaker: We would like to hear your feedback so that we can prepare more interesting content for you to enjoy.
Speaker: Hear you next time!
