Crossing the Finish Line

Welcome to building better developers, the developer podcast where we work on getting better step by step professionally and personally. Let's get started. Hello and welcome back. We are continuing our season where we're looking at mistakes, mistakes, errors, all kinds of fun things like that that we have grown from, learned from, and often those have been stepping stones to success down the road. So making mistakes are not the end of the world by any stretch of the imagination. This episode, we're going to look at, I will call it crossing the finish line. Now, there are multiple situations where I've run into this similar kind of story in the past. And it's an interesting one because in particularly the more recent situations, it has been a mistake that a customer has made and has sort of been beneficial to me, although I try to keep them from doing so. And it does raise tensions because it ends up being something that I sort of benefit from where they don't. And by benefit, I mean, it is essentially what's happened is the project gets drawn out longer than probably it needed to be. Now, the situation I'm going to talk about is probably one of the more egregious of these where we really poured a lot of time in some stuff that didn't need to be or they could have been done better. And while I tried to do so, it was hard to convince them otherwise. In this situation, we're building a website for someone and going through the normal things you do. And we've been progressing at this point for pretty good. Been working on it for a few months. We've got a lot of the core functionality into it. It's one of those where you have the function, the primary functionality is more or less there. And let's say it's 90 percent there. There are some things that we're still refining a few edges. And the we're really into like the reporting and it's more like usability, things of that nature. And in this situation, we had it was it was sort of an MVP, but not really. It's one of those where you have an MVP, but it needs to be polished enough and nice enough because it's going to go sort of be the lead for selling the project, the company, the organization, the business idea. And what we got into that was the challenge here is we got to a point where we were looking at some reports and there was, I don't know, a dozen things that were improvements, were either fixes or improvements. Most of them were improvements on the usability type of side. So you could say it's a fix. You could say it's something more than just adjusting how things look. Because it was it was important. Now, what we ended up doing and we're at this point, we're probably at our budget, maybe a little over budget. I mean, it's so it's sort of on track, but there's obviously some additional things. And the customer is OK with that. They say, you know, we're we're going to spend some extra money, some extra time to add some additional features to it. However, this is where the finish line thing comes in. We had a couple of pieces that, like I said, that were 90 percent done and we're coding on these things and there's these report things coming in that are reports, requests, change, can you change this? Can you change that? Can you do this? Can you do that? And they were not. And in this case, the one I'm about to go through, they were not nailed down yet. So this one turned out to be really centered around dates and how dates were displayed, how they were entered and how they're displayed. Just dates, not just sort of throughout the application. But the focus tended to be on, you know, like a report at a time, things like that. So while we're still working on a few of the inputs, there were these reporting requests that were coming in that what ended up happening, the way it was looked at it was those things need to be held off because we're not done nailing down how the data is going in. So if we start chasing down how it displays coming out, we may not, we may be doing extra work that we don't need, or things may change that are going to cause problems later. And the challenge here was the customer got hung up on a couple of reports that said this has to look this way. So the focus shifted from let's get all of the data entry right. Let's cross that finish line and say that we have an application that it's source and its ability to gather source data is, you know, we'll say complete or static or stable or set or code freeze, whatever your terminology wants to be. And then we'll worry about the output of that, the reporting of that. Well, that wasn't the case. And so we spent probably, I think at TowerDot we spent a good three or four weeks because what would happen is we'd go in, we would change up a report. So that it displayed exactly the way they wanted it. And then we would come back around to some of the data entry things. And those made some changes to how things were done that now meant that the source data was a little different. So that meant we had to change all the output. So it ended up being something where you would, it was sort of backwards. You would fix the output so that displayed right. And then you'd go back and change the input, but then had to go change it all the way through to the output again, so that it handled things correctly. Now, what should have been done from the start was, you know, something that was like a, a formatter or something like that, that basically it doesn't really matter what gets put in and it does, that it's always going to put it out in a certain way and then just code those inputs. Although that still would have been a little bit of an issue because we still would have had to keep coding it, handling those, those various inputs, which is eventually what happened because it was one of those that, this is part of my mistake. When it first came in, the first request was like, Oh, okay. We'll just change this thing. It's, you know, it's a simple fix where at that point it should have been, wait a minute, is this possibly going to change again? Are the inputs going to change? Let's back out. Let's build a, you know, a smarter solution, a control or something of that nature, so that it's not as date format in this specific case. And actually, because we ended up using it throughout the application, let's make something that's not date format specific where we can just take in whatever, kick out whatever and have some sort of setting, you know, that we can do to sort of a switch to flip for each of these, whatever format it is, it's coming in and whatever format we want to display, because it did become something where there was, depending on how you were out, the data was being outputted, if it's being output to a form, there was one format that we, we needed to use because of the date calendar controls we were using. It was going to report, it needed to be a different format. And so the, you know, this is where my mistake in this case was, is that not backing that out and recognizing that sooner rather than later and saying, Hey, this, this is something that obviously we've got a couple of different ways we need to deal with this piece of data. So we're going to have a little, you know, a smart class that's going to be able to deal with that, that we're going to have one format in the database and we don't really care. And then we're going to allow different formats to come in to convert to that database format and different formats to display formats that all are going to be coming from that, that database format, whatever it is. So it's one of the, and it's, this is a pattern that we have talked about back when we had the season on patterns. Basically it's a translator type of a class. And so we lost a couple of weeks where it was, that was really the focus was, let's get this, you know, let's do this right. And then we go back and we change it and like, Oh, wait, now it works here, but it doesn't work there because now we've got to make that, that change percolate all the way through the system. And it was somewhere in the middle of that, that I realized, Oh wait, we, this is not a one-to-one mapping. We've got a couple of different ways that we have to take data in. And we have a couple of different ways that we have to display the data, different formats in both cases. So we need to, instead of quickly, you know, which is, which was part of it. It was these estimates that like, Oh, okay, we can come in and we can do this low cost quick, you know, sort of a quick and dirty solution. It was, it became obvious that it was racking up enough. That's like, wait a minute, we need an actual solution, not the quick and dirty. No, back to that crossing the goal line thing. If we had solved or completed the problem of let's get all of our data in, then one probably would have seen that control already. Cause we would have seen that there's two or three different ways for the data to come in two or three different formats. And those all have to convert to a single format. And then when we did the reporting side of it, the outputs, we would have just said, Oh, well we can take this multi input thing and turn it into a multi output thing, which is what we eventually did. But it wasn't until we cross that finish line of getting those, at least for those forms and those pages, getting that data in and looking at what we were going to need to do for our interface and for usability and all of those kinds of pieces, it wasn't until we looked at that, that it made sense that, Oh, this is not a straightforward, simple kind of, you know, mapping of data from point A to point B to point C. And it essentially looks the same all the way through. And like I said, this is something that I've seen many times where you get near the end and this is, this is the biggest challenge I think in dealing with, whether it's yourself going through things or it's a customer, you know, manager, what boss, whatever, is you get close and get past that 80%, you know, especially when you get to that 90, 95% mark where you're almost there. So there's more or less this assumption that goes on in people's heads, or maybe it's just a blind spot where it's like, okay, well, this is done. And so now if I tweak this little thing here, this little thing there, that's what I should be doing. It's, it's done. And now I'm just polishing off the rough edges, but if it's not done a hundred percent, then there are going to be some things changing. And what you end up doing is you are changing one area while another area is changing, and now you end up in this trying to hit a moving target kind of challenge, which is always going to make things worse and cost more time. And like I said, as you get close, it gets harder and harder to say, wait, stop, pause, whether it's to yourself or somebody else, let's finish this piece. Let's get this across the finish line so that it's a, it's working correctly. And it's really, at this point, I'm talking about like functional covers, the requirements kind of thing. And then we can work on making it pretty, uh, another one, making it faster. I've seen this a lot where you get towards the end and there's this performance or tuning kind of series of tasks that comes in. A lot of times I've seen this with websites where somebody's building a website and it, it gets near the end and the customer says, Hey, this is, when I do this, this and this, it's too slow. It's taken 10 seconds when I, it should only take a few seconds and 10 seconds. This is not going to work. So it needs to work faster. Well, that's important. That's something you have to fix. But if you're still changing the data entry, the source data for whatever that page or activity or vent is, then the tuning you do may not be sustainable throughout. It may be that you tune it and you make it work and then the data changes again, you know, the inputs or the structure, the schema changes again, and now you have to redo that, uh, that performance tuning. And so the challenge becomes to have a finish line and to know what that finish line is, is to basically say, let's, and it really turns out to be almost like a, that's like an MVP type of, um, a calculation is do I have an application that does what needs to be done that solves the problem and solves it consistently and effectively. And then if I do then, and I know that that's fairly static, that the, the way I'm solving the problem is something that I'm not going to be changing anytime soon. I mean, there may be a complete refactoring somewhere down the road, but I'm talking like, you know, in this version, it needs to be stable because then when I go do all of these little, the polishing and, and tuning and those kinds of things, at least I have, I'm working on something that is not changing underneath me. Because when you're working on that thing, that's changing underneath you, it's going to be frustrating. It's going to be difficult. There may be work this loss, it's going to take longer. There's just so many challenges that come from that. And I cannot emphasize enough. The closer you get to the end, the easier it is to do this. And on the flip side of it, or another part of that is it becomes, uh, what we've talked about before, where you have this thing that you keep, you know, you're like almost done, you're 99% done. And you start making all of these little changes. And what you're doing is you're not, you're not really fixing. Now you're getting into these little enhancements because you are, you're polishing the solution and it's not that those are not valuable, but it's that instead of having something that's done, it's still in progress. And I've seen this, as I said, a lot of times where it's been sort of a benefit to me, where as a, as a consultant or a, you know, some sort of a situation where there's a project that is not fixed bed, that it's, yeah, you're continuing to get paid because you're continuing to do work and where the customer could claim victory, cross that finish line and say, yep, this is what it is. And then go, you know, test it, use it, make it, put it into production even, and then come back a month, a quarter, a year later and add a lot of these enhancements in, or at the very least push it into production. And on the meantime, have development going on it instead it's blocked from production because they're keep coming in all these little things that it's like, okay, this week we're going to finish it, but oh wait, no, there's a few extra little tweaks here and there. Let's go ahead and get those into this. And it, it does become something it's like shoving stuff under the, you know, the carpet, like the dirt, you know, you sweep and you sweep it under the carpet. And initially you can do that. It's like, okay, yeah, we can throw that in there. We can throw that in there. We can throw that in there. I had one customer, we had this thing done probably in three months and it was a year before they finally declared victory and put it into production. And that last nine months, they were all these little minor type of things, but it kept being, yeah, we can put that in there. We can put that in there. And I think part of it is they didn't want us to just go away and not be able to hear from us again, but it was also something where there was value in that application three months into it. And they really didn't start getting that value for at least probably another six months because it was towards the end. They finally started putting that in front of people in essentially in a production sense, so they could take advantage of what had been built. So bottom line is when you get close to the finish line, look at making that final push to finish and all those little adjustments that can be made. Have a way to set it up and say, Hey, we'll finish and we'll do a 0.01 release afterwards that will cover all of these things so that you can continue to have the focus being on solving the problem and not for lack of a better term, making it look pretty or making it solve the problem better, get to a finish line, declare victory, and then move into those improvements. It helps your sanity. It helps avoid things like death marches, but it also avoids things like huge cost overruns because what you ended up doing is you're moving the finish line. And if you move the finish line, then it's going to change. All your estimates were, are moot at that point. They're useless because they were estimates for a different finish line than the one that you are now aiming for. That being said, I probably overran my finish line on this episode, but that's okay because we'll be back with more and hopefully a couple of minutes was not too much extra to take up your time today, but as always go out there and have yourself a great day, a great week, and we will talk to you next time. Thank you for listening to building better developers, the developer podcast. You can subscribe on Apple podcasts, Stitcher, Amazon, anywhere that you can find podcasts, we are there. And remember just a little bit of effort every day ends up adding into great momentum and great success. One more thing before you go, develop a new podcast and site are a labor of love. We enjoy whatever we do, trying to help developers become better. But if you've gotten some value out of this and you'd like to help us be great. If you go out to developer.com slash donate and donate whatever feels good for you, if you get a lot of value, a lot, if you don't get a lot of value, even a little would be awesome. In any case, we will thank you and maybe I'll make you feel just a little bit warmer as well. Now you can go back and have yourself a great day.