CYA Practices in Software Development

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. Thank you for tuning in. We are here just coming right through your ear holes. Building Better Developers, Developer podcast once again. In this episode, we're going to get into a little CYA essentially. It's, yes, you could talk about documentation or communication, but at the end of the day, it is a little bit of a CYA kind of a topic. And the reason this came up this time is I had a customer call today that was, it was initially, it's one of these where like, hey, here's the agenda. This is what we want to talk about. Great. And so we get into the call and everything kicks off. And right away, the first item we start talking about, it's like, I think that's already there. And sure enough, it's there. It's a non-issue. It's already been taken care of, taken care of months ago. It's just, this is one of those where you have somebody that is not the frontline user and they don't realize necessarily exactly everything that's going on, which is also an interesting thing we're going to talk about because this is somebody that gets regular just doesn't probably read the statuses very closely. And so, you know, sometimes you have to look at how you communicate such statuses. But then he had another item. This one, we got into the call and he realized, oh, I'm not sure I got the budget for that. So let's like hold off on that. So it's, he like throws out that, you know, that, hear it. And then it's like, oh, wait, wait, maybe we're not going to do that right now. And then he got to another one and it was, well, we need to look at it. And it turned out it's one of these things that the data they were looking at was wrong. It only worked for new data, not old data. He ran into it with the old data. It was something he had explicitly said, we don't want to deal with the old data. We're only going to do this for the new data. And so suddenly the entire agenda, it was basically the call ended up. He's like, wow, it's really good talking to guys again, at least, you know, as one of those versus, you know, nothing, nothing really useful came out of it other than just, you know, a little bit of FaceTime with the customer. So I guess, well, you said that you've had some stuff this week that's that's or recently that is in that same line. So what is the, what has been your experience along those lines lately? So recently, especially so with a lot of us, we have side hustles. I also still work for full time job for a software company. And one of the complaints we've run into recently is we started rewriting three pipelines of our application. We had some legacy software. We decided to just start writing it. The problem we ran into is we started this project six months ago and we really didn't have a clear roadmap as to what was going to happen in Q1. Well here we are in Q1 and we have deadlines that are in 30 days. Well we have code that is where the business thinks we're at one place, but we're really at another place. And if we actually had understood that, oh, this deadline is coming, we would have put on something sooner and said this kind of little short, mad dash to the end in this last sprint or two. The other thing I've run into is even within the rewrite, some of the code we're putting out there is very cumbersome, very large and very hard to follow. So one of the things as we talk about this, the CYA is what do you think about coding standards with CYA where we actually write clean code that documents itself so when we come back we don't have to struggle and try and figure out what was done? I think that is one of the CYA aspect of well documented code is actually a very interesting tack that I don't think we've talked about it. I don't think about it as much, but it's actually it's a really good point because it is something where you will run into situations and this is something we ran into recently as well. We had a we've talked about this. We had a client that they had a very old version of software. There's a bunch of upgrades. And so we ended up going through and doing some upgrades and then it's ended up being moved on to somebody else. And it is something that one, we want to have that roadmap of what did we do so we can we need to do if we're going to particularly if you're going to like do it to a say a staging server but now you got to do updates to your production server so they've got to be in sync you want to make sure that you have that basically that roadmap of how did I get from point A to point B but also from a CYA point of view if somebody comes in and takes over your code and they say hey this was this was a mess this was just this was worthless code or they wrote all of these bugs into this stuff and sometimes you will have a situation where okay yeah you wrote you wrote bad code occasionally do that but there's also times where somebody comes in and they end up not understanding what was built they don't read the documentation they don't look at stuff well shame on you if you don't have documentation because if you didn't give them documentation then it's not their fault they didn't read it but if you did it's nice having that paper trail essentially which is why I don't know why anybody in the modern age would not use version control while they're developing I think the best thing you can do for yourself is get in a habit even and I've had projects where they don't officially have version control I have my own git repository you can throw it out you can do it github for free save it off like do labels do everything at least commit I would say at least commit and push daily at the absolute minimum I very often will do it based on big chunks of code and then don't be afraid to like to put some tags in there or branches or everything else particularly if it's if it's a team go ahead and branch off of it work on your branch and then merge that thing back then you know exactly what you've done you have something well documented and you have that CYA you can point to this is what I did this is how we got from point A to point B and this is where I made mistakes and this is where other people made mistakes and pointed their finger at me exactly which is kind of funny which is why I kind of started this conversation at the code level kind of talking about clean code for a couple of reasons one essentially your code is the source of truth right no matter what documentation you have what wikis you have you know what may be written on you know your tickets or as far as what's been done at the end of the day what's in the code is really what's there what the application does so if you document your code and you write it cleanly you essentially have your blueprint as to what the application does right there if you're doing Java you know include some simple Java docs and if you're not really good at using Java docs or some type of you know code documentation write better code you know write descriptive code so that as you're reading the code you can almost read it as a use case that's one approach the other thing I want to kind of now take us from the code level to a tier up so as developers and even project managers engineers we've been through the process of projects where like you said you talked to customer and he's like oh we did this six months ago we forgot we didn't get it done that kind of gets you to project management tools like Atlassian bitbucket like you said get repository and code reviews so where do you see those kind of working for CYA to an extent because at the end of the day as developers we're not necessarily the ones putting those in but we have to use those to kind of record our work oh I think that is those are great tools to use I think we overlook them way too often they're way too often I've been I've been on a development team and they have coding standards that include code reviews and in regular commits and branches and pull requests and all of these things and you'll see that people will commit code and their comment will be you know fixed it wrote some code fixed a bug it like that uselessly in specific now sometimes it's it's nice and you'll have a and but it's sort of a crutch is people refer back to like for example a JIRA ticket number so I worked on some code I saw ticket you know one two three four five six and so you can at least go to the ticket and see what it applies to but I think you're still not using it as well as you could because you're not really saying anything about what you did unless you're going back to that ticket and you're fully commenting that out you're better off in your code commits to be able to have use the space that you have there to talk about what what were the changes what are the key pieces you did and if you have to write a book when you do a commit you're not committing off enough you should be doing stuff in you know a little bit more bite-sized chunks so that you could look at your history of commits and sort of see what you did because that gives you that source of truth and then with a code review even better because now it's I had this commit and that actually is going to sort of help confirm it because they're gonna do a code review they're gonna look at your comments are gonna say what did you say you did does the code do that they're gonna help you out and so it's a really good I mean that's like a rock-solid CYA kind of thing because now you have not only your your system of truth of your source code but you have the history the audit trail of how you got there and if you're if you're in a public company if somebody's coming in and they're gonna your company is gonna go public then that's one of the things they're gonna look at is do you have those processes and procedures in place so that you can rebuild where you were six months ago and definitely so that you can rebuild whatever your current version of the software is all right so for the third point with this if you were to actually put in good QA practices in place where you actually have tests unit tests that test the white box testing the code you have your regression test that tests the black box testing or you have the integration test that tests all the integrated pieces together then your tests actually become your documentation your tests become the use cases as to how the application is gonna work and it is as you work the code and the code breaks something you have to go fix the test which changes the use case and you know what has changed so your stories kind of migrate with the application if you forego the testing and go the documentation route your documentation can become stale you could make six months worth of changes to the code and your documentation maybe six months old or your API's might not be right and you send that out to a customer like it doesn't work what's going on so that's where I think if we kind of flip the model on its head where we as we write these business cases or we write these use cases from the project management side to the developer if we write them with testing in mind and you kind of put that test driven approach in place then there really is no excuse for you not to have CYA from the beginning from the moment you get the requirements you can say okay here's how you test this here's how this is supposed to work you write that test first and then you write the code so then at the end of the day you have you know clear as day that your test works as expected that your code works that's true yeah I think that's a that's a good point is your your documentation can go stale easier than your tests can your test but your tests can also I think that's a it's a very good point but I also think that you have to make sure that you are keeping your tests up to date as you go I've seen a lot of situations where a company has got just awesome bed of unit tests and maybe even some good regression tests but they were sort of like version one and now we're version 2.0 of the opposite of the application and all that stuff still works because that core stuff isn't being touched but they didn't maintain it along the way so you do have to you have to have that discipline to continue to do that and not just do it initially and we do this so often with documentation everything else is we build everything out we do it all right and then we start writing we get into the implementation point and stuff starts going out the window because we don't have time to do that so we're gonna write the code we're not gonna write the test so you do want to make sure that you and this is where the CI CD stuff comes in that continuing integration and continuous integration and deployment and having your test built in and making sure that it's with code reviews to make sure that when there's code written there are tests that go with that code that are also being committed so that your whole system your whole process is being updated as you go now that does dovetail into another point i wanted to talk about a little bit is we'll talk like saying something and nobody's listening which is the CYA part of doing a status and documentation and tests even if nobody cares so even though your tests are there and you're seeing you know you've got the test results that you can always point back to it becomes difficult to say the least it's sort of depressing to be doing all that work and doing the right thing and nobody cares you're not seeing your manager's not seeing it or just as like okay great you did your test or they you know that they never you send a write a status every day and they never read it those kinds of things i don't want to talk about get your thoughts on that is like from that from your point of view it's like when you're sitting there and you know you're doing the right thing but nobody cares how do you motivate yourself to keep doing it anyways well one of the biggest motivators for me that makes me always try to follow the best practices the test driven development approach is simply i don't want to be the one that puts a piece of code in there that takes the system down that costs my company a million dollars now i've been in a couple situations in my career where code has gone live and we've actually started costing customers money the moment it's turned on you don't want that not only are you potentially on the hook financially you could legally be on the hook especially if it's like patient information you don't want to expose that stuff you don't want to be a part of a violence and so to me i stay motivated because of that it's not so much that my manager wants this or you know to me at the end of the day i want to put out the best code that i can and make sure that the software i write is the cleanest and that basically if i touch code i leave it in a better place than when i came in i want to make sure that the person that comes behind me can easily read my code follow along and know what happened and be able to work it if there's a problem or if they're making change that is one of the biggest not caveats but one of the biggest things i've seen with a lot of junior developers they don't do that at all they just quickly let me hack it out okay done move on mid-level developers they're a little more methodical they're a little more documentation they spend the time to try to make sure that they do it right but again they're under deadlines so they kind of still rush through to get things out and then you have the more senior engineers where you know we could be under time or high pressure we could be in on a project that's under staff and that what are we going to do we have to make shortcuts but you try to make the shortcuts not so much on processes or quality but just try to make sure that you keep what you're doing as simple as possible and not bloat your code so you stay like hyper focused you have to make one change make that one change but make it the best way yeah i agree i think that's the you know that's the key to all of this is that the the reason we should be doing this while it is we talked about the cya as our topic for this one and that is a that is a huge side effect benefit of doing things the right way but it is these are also things that will help us build better code this helps us it's going to be easier to maintain it's going to be easier for us to go back even if we're the maintainer and figure out what did we do if something breaks we can figure out what code changed so we can like get to that break faster if we have to look at our entire code base every time we've got a bug we're in trouble if we can look back and say well we only changed these five lines of code then most likely those five lines of code are where the break occurred or somehow are related to it so that at least gives us a starting point and that is where we become more efficient and it's we're going to be better as developers and i think that's why more senior developers when you start as a junior you just you just do what you're told usually that's just most of us are that way but then as you get further along you get a little more confident and realize that the processes and procedures are there for a reason that they protect the customer as well as us as well as the software stability itself and so there's a reason that these these practices are in place and it's not these aren't things that we can just you know take a shortcut and say oh this takes time we're going to throw it out instead we need to be more specific about it and maybe change the scope or as you said sort of focus maybe you don't you know maybe you don't architect the most incredibly perfect solution to it but instead you simplify that down but then make sure that simple solution is so much better it's like a it's like a car if you've got a if you want to go build a Porsche from you know from scratch then you get halfway into it and you run out of money then you're not able to do anything but if instead you said hey i'm just going to build myself a bike so i can get from point a to point b then you're going to get there faster it's still going to work it's going to be solid you don't have to have a bike that's going to fall apart versus you know the Porsche that falls apart it's a i know it's a crappy analogy but it is one of those things that we that you run into is it's better to have something lesser and solid that's rock solid than it is to have a whole bunch of features that half of them don't work and there's so many products that are on the you know that are strewn over the high the internet highway or whatever it is that failed because that's exactly what they did they tried to throw too much stuff at it and it ended up falling under its own weight can i add one thing to that in terms for developers regardless what level you're at one of the biggest mistakes we can make when we go to write code when we go to take an assignment and go do something we don't take enough time to review the ticket we don't take enough time to make sure that all the requirements are there or potentially some of the unforeseen edge cases that might be very edge but may not be for like a simple like date paper if you were to have like a start date end date for a search of data you know you would have an edge case well what happens if they put in a date that is outside of the range or put an end date before a start date yes that's an edge case and a lot of people would test that but some companies won't test that because it's like well that's not what the users are going to put in and typically that could cause some weirdness with the system or break the system so essentially as an additional point to cover your ass or the cua is make sure that before you even do anything make sure you understand the tickets make sure you have all the requirements and make sure that you understand the edge cases so when you do write your code again this kind of gets back to testing you know how to test it you know what it's supposed to do and therefore you're writing what should work and if it's all agreed to on in the ticket all that's defined if something breaks you can refer back to the ticket and say okay if that's an edge case that was not considered we need a new ticket yeah i think that's one of those things like your mom used to always say you know eat your vegetables brush your teeth and read your requirements thoroughly i think those are the kinds of things that we need to like you know think about because some people see it and whether it's uh communicating or receiving it is the developer being sort of you know obnoxious or rude or something because they're like well wait a minute i've got more questions about this but it's not it's about getting those details out and being able to discuss those so that when we build it we know what we're building and we don't go halfway into it and then have to change stuff rewrite all the other things that could come out of there's a lot of bad stuff that can come out of surprise requirements that pop up or edge cases that suddenly are you know a lot of times like nobody's ever going to do that and then you find out that half of your population does those are the kinds of things that you have to watch out for and they can they're what cause delays in software they cause you know the overruns in budgets and all that kind of stuff is because the the requirements piece is shortcut way too often and we do it as developers too we just read through it like oh yeah i got it no problem i get it i understand it and then you realize that no you didn't because you didn't you didn't think about these half dozen different cases that are maybe very critical they may not be edge they may be things that like oh this probably happens fairly often and you find out way too often that it does so i'll give you your last thought on this one i was just going to add one additional piece to that so along with that the other thing to kind of keep in mind is when you're dealing with trying to do things right you're dealing with requirements and those weird edge cases you know if you again think things through you'll be in a better place the other thing you might also consider is as we continue this weird shift in the economy shift in our business practices and shifting in the software model we've seen big corporations do the shift left or the moving testing to the developers we have fast to fail where we have to let's get something out there and see what the customer will do with it well while those approaches are well and meaningful they actually bring up more pitfalls that you really need to make sure you understand how to see why otherwise you're going to be in trouble yeah i think that's definitely that's good point is that sometimes you don't want to get the ugly thing out there because then it's like yeah they'll tell you right away that it's failed but then they may decide that it's failed so much they don't want to talk to you again so you have to watch out for that and that's what we have to watch out for is failing by going way too long on a on an episode so we're going to wrap this one up yeah just in case that you've got some limit to your podcast listening time frame today as always it's just an email at info at development.com if you've got any questions topics anything like that that you want to reach out you can check us out at developer.com there's blog articles there are links to the podcast to the youtube channel to all kinds of other fun stuff that's out there fun for everyone well maybe not everyone but for enough people go ahead and check out the site and we're just going to continue with this season we're going to continue work on our way through some of these common business problems that we're hitting and share those with you so 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 podcast 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