Detailed Notes
Welcome back to another insightful discussion on software development! In this episode, Michael and Rob delve into the critical topic of CYA practices—Cover Your Ass practices—in the realm of software development. As seasoned professionals in the industry, we've encountered our fair share of challenges and learned valuable lessons along the way. Our goal today is to share some of these experiences, insights, and strategies with you, our audience so that you can navigate your own projects more effectively and avoid common pitfalls.
Understanding the Importance of CYA Practices
We start our conversation by reflecting on recent experiences with clients who inadvertently overlooked crucial details in their project agendas. From forgotten tasks to budget uncertainties and unexpected data issues, these situations underscore the importance of robust CYA practices. Whether it's about status reporting, communication, or documentation, having a clear paper trail ensures accountability and transparency.
The Role of Clean Code and Documentation
One of the cornerstones of CYA practices is maintaining clean code and thorough documentation. Michael and Rob emphasize the significance of writing code that is functional, well-documented, and easy to understand. Clean code serves as a source of truth, enabling developers to navigate through the project's intricacies efficiently. Additionally, comprehensive documentation acts as a blueprint for the software's functionality, facilitating smoother transitions for future developers or team members.
Integrating Testing into CYA Practices
A crucial aspect of CYA practices is integrating robust testing methodologies into the development process. We discuss the importance of test-driven development, where tests serve as documentation and use cases for the software's behavior. By prioritizing testing at every stage, developers can catch bugs early, ensure code reliability, and mitigate risks associated with unforeseen edge cases.
Navigating Challenges and Motivating Team Members
As developers, we often encounter situations where stakeholders might find adherence to CYA practices tedious or overlooked. However, we stress the importance of staying motivated and focused on the long-term benefits of these practices. Whether it's adhering to requirements, addressing edge cases, or maintaining testing standards, prioritizing quality over shortcuts ultimately pays off in the form of stable, reliable software.
Embracing a Culture of Accountability
In a rapidly evolving software landscape, embracing a culture of accountability is paramount. Everyone from project managers to developers plays a role in upholding CYA practices and ensuring project success. By fostering open communication, thorough documentation, and a commitment to quality, teams can mitigate risks, streamline development processes, and deliver exceptional results.
As we conclude our discussion, Michael and Rob reiterate the importance of CYA practices in software development. By embracing documentation, clean code, testing, and a culture of accountability, developers can navigate complex projects more effectively and mitigate risks along the way. Remember, the extra effort invested in CYA practices today can save countless headaches tomorrow, ensuring success in the ever-changing software development landscape.
Thank you for tuning in to another episode of Develpreneur. We hope you found this discussion insightful and valuable for your own software development endeavors.
Additional Resources
* CYA Documentation: Getting Started With Consulting - https://develpreneur.com/cya-documentation-getting-started-with-consulting/
* Cover Your Assets – The CYA Anti-Pattern - https://develpreneur.com/cover-your-assets-the-cya-anti-pattern/
* The Importance Of Writing Readable Code - https://develpreneur.com/the-importance-of-writing-readable-code/
* Clean Code Handbook Software Craftsmanship - https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
* Behind the Scenes Podcast Video - https://www.youtube.com/playlist?list=PLxXUHr7mZ-jF8Ip1xF8LUyY97Uzh5QWRq
Transcript Text
[Music] well hello and welcome back we are here once again going through another uh little discussion here between myself and Michael we are talking about RB Consulting we talk about Invision QA we talk about develop andur and the building better developers site and all things that are sort of you know bugging us a little bit and Lessons Learned along the way as we are launching advancing and rebooting some companies so figure if nothing else you know you can hopefully uh learn from some of our mistakes and not suffer the same pain points we are and uh welcome in Michael what's how's your day going pretty good uh it's been a pretty good week so far uh how about you it has been uh it's been a fun one it's uh this is one of those it's a had a great interview today or meeting today with a customer and these are these are the fun ones that you occasionally get because he he sends me an email and he's like hey we want to talk about A and B and C I like okay great we'll talk about these things and we get into the call and the one had already been done had been done like months ago and he'd forgotten about it the other one he suddenly realized he wasn't sure he had the budget for it right now and the other one uh he was like well I think we're going to do this but I'm not really sure about the value and that was sort of the same thing as he ended up sort of backing out and saying oh well maybe it was one of those that was uh it only worked on the new data they didn't want to go back and fix old data and it turned out that it works fine with the new data he was dealing with W cany data so one of the things that he had explicitly chosen to do he got bit by so this is I think this is one that will lead us into I think our podcast this time I want to do a little um I guess we'll talk about like cya kind of stuff because this something I don't think we've talked about recently as much we have touched on in the past but it's the idea of like status reporting and communicating and making sure that you're you're clear on what's being done and also that you have essentially a paper trail of some sort so you can look back and say what did I get done and when did I get it done sound good does that sound like a fun topic for this time around oh yes definitely uh in fact we've had similar conversations uh at work and I've had similar conversations with customers along those same lines so I I love this um so why don't you kick it off then with kind of the use case or where this came into play this week with uh these customers we'll do so while you guys get to see us kick this off on the audio side again hello and welcome back thank you for tuning in we are here uh just coming right through your ear holes building better developers developer podcast once again this episode we're going to get into a little cya essentially it's uh 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 uh it initially it's one of the 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's 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 front line user and they don't realize necessarily exactly everything that's going on which is also an interesting we're going to talk about because this is somebody that gets regular status 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 ah 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 parro 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 was really guy good talking to you guys again at least it was one of those where just 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 uh so with a lot of us weide hustles I also still work for a 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 road map 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 things were at one place but we're really at another place and if we actually had understood that oh this deadine coming we would put more hands on something sooner instead of this kind of little short mad the end in this last Sprint or two uh 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 uh as we talk about this uh the C is what do you think about coding standards with cya where we Write Clean code that documents itself so when we come back we don't have to struggle and try to figure out what was done I I think that is one of the the cya aspect of well documented code is actually very interesting Tac that I don't think we we've talked about 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 have 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 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 we want to have that road map of what did we do so we can we can figure out what we need to do if we're particular if you're going to like uh 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 uh basically that that road map 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 you know they wrote all these bugs into this stuff and sometimes you will have a situation where okay yeah you wrote you wrote bad Co code occasionally we 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 a 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 uh I very often we'll 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 exact 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 winkies you have you know what may be written on you know jur 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 you essentially have your blueprint as to what the application does right there uh if you're doing Java you know include some simple Java docs uh and if you're not really good at using Java doc uh 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 uh that's one approach the other thing um I want to kind of now take this 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 talk 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 at lassan um bit bucket uh like you said get repository and code reviews so where do you see those kind of working for C 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 uh 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 and 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 a wrote some code fixed a bug it like that uselessly INSP specific now sometimes it's it's nice and you'll have a and but it's sort of a crutch as people refer back to like for example a jro ticket number so I worked on some code I solve ticket you know 1 2 3 45 6 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 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 going to do a code review they're going to look at your comments they're going to say what did you say you did does the code do that they're going to help you out and so it's really good I mean that's like a 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 going to your company's going to go public then that's one of the things we're going to look at is do you have those processes and procedures in place so that you can rebuild where you were 6 months ago and definitely so that you can rebuild whatever your current version of the software is 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 test unit test to test the white box testing of the code you have your regression test to test the blackbox 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's going to work and 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 forgo 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 may be six months old or your apis might not be right and you send that out to a customer to 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 uh 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 could go stale easier than your test can uh your te but your test 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 test 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 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 off 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 well we don't have time to do that so we're going to write the code we're not going to write the test so you do want to make sure that you and this is where the cicd stuff comes in that continuing integration 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 um we'll talk like saying something and nobody's listening which is the cya part of doing like status and documentation and tests even if nobody cares so even though your tests are there and you're seeing you 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 you're not seeing your manager is not seeing it or just as like okay great you did your test uh or they you know that they never you send a write a status every day and they never read it those kinds of things um I didn't want to talk about get your thoughts on that is like from that from your point of view is 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 um 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 cost my company a million dollars an hour uh I 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 it's turned on you don't want that um 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 hip violation 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 happen and be able to work it if there's a problem or if they're making change that is one of the biggest not caveat 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 high pressure we could be in on a project that's under staff and now 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 hyperfocused you have to make one change make that one change but make get the best way you 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 COA as our 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 you 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 and 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 got a if you want to go build a a Porsche from you know from scratch and 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 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 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 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 screwn 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 uh regardless of 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 picker if you were to uh 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 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 CIA 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 the in the ticket that's defined if something breaks you can refer back to the ticket and say okay 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 well nobody's ever going to do that and then you find out that half of your population does and that's those are the kinds of things that you have to watch out for and that 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 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 may be 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 uh and those weird edge cases you know if you again think things through uh 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 a lot of big corporations do the shift left where they're moving test 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 c otherwise you're going to be in trouble yeah I think that's definit that's good point is that sometimes you don't want to get the ugly thing out there because then it's like yeah you 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 um you know just in case that you've got some limit to your podcast uh listening time frame today uh as always show an email info development.com if you got any questions topics anything like that that you want to reach out you can check us out at develop ur.com there's blog articles there are links to the 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 uh that's 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 it's really important on an audio version is to make sure that you have like a little finger thing like next time because that's so important these are the things that you get from a video that you don't get from the audio is all of the like extra gesturing that goes on then you realize people that are talking with their hands does no good on a on a podcast so I think that about wraps it up for us this time on the video side as well so I can like this wraps us up or something give a little hand motion there um and we'll just continue on we've got like you know we we have these conversations all the time and uh this one uh has been a good another one we just sort of like jumped in it's like hey what are we running into because like you guys we are here all the time running into new every day it feels like we've got a new problem to solve and you know six different ways that we need to solve it so it's h however we can help each other out we're more than happy to do so uh can go ahead and subscribe to the channel and you'll see whatever our latest stuff is you get it when it drops we're doing this twice a week Tuesdays and Thursdays podcast drops the latest video is going to drop basically the video version drops at the same time so you're really not losing anything if you want to listen to podcast you get it at basically the same time that you could get the the video it's just whatever you know whether you want to watch us or whether you want to hear us listen to us while you're going around in your drive time and you know doing your Uber Eats or whatever it is you happen to do so we want to thank you for your time uh as always leave some comments out there let us know what you what you think subscribe and let us know uh what are some things you'd like to see us to talk about in the future if you've got anything in particular that youve has been bugging you we'll be more than happy to either cover it maybe here or you can shoot us that email and we'll uh we can take that offline and and talk to you that way way as well we're always looking for ways to solve problems and yeah we have a bunch but we're always looking for more so any uh parting thoughts from you Mike yeah the only thing I would like to add in addition uh if you are watching the video uh just make sure to check out the notes section in uh YouTube or go out to developer.com and check out the blog for the podcast we do put additional links in there to other material and also to some of the software that we talked about within the uh conversations that we have uh good point yeah I always I forgot to say and you know links in the show notes because that's almost always going to be there there's going to be links to us and where we can other places that we reference so I think that'll wrap this one up we're going to go get back to our normal non-developer lives and you guys have a great one and we will talk to you next time
Transcript Segments
[Music]
well hello and welcome back we are here
once again going through another uh
little discussion here between myself
and Michael we are talking about RB
Consulting we talk about Invision QA we
talk about develop andur and the
building better developers site and all
things that are sort of you know bugging
us a little bit and Lessons Learned
along the way as we are launching
advancing and rebooting some companies
so figure if nothing else you know you
can hopefully uh learn from some of our
mistakes and not suffer the same pain
points we are
and uh welcome in Michael what's how's
your day
going pretty good uh it's been a pretty
good week so far uh how about you it has
been uh it's been a fun one it's uh this
is one of those it's a had a great
interview today or meeting today with a
customer and these are these are the fun
ones that you occasionally get because
he he sends me an email and he's like
hey we want to talk about A and B and C
I like okay great we'll talk about these
things
and we get into the call and the one had
already been done had been done like
months ago and he'd forgotten about it
the other one he suddenly realized he
wasn't sure he had the budget for it
right now and the other one uh he was
like well I think we're going to do this
but I'm not really sure about the value
and that was sort of the same thing as
he ended up sort of backing out and
saying oh well maybe it was one of those
that was uh it only worked on the new
data they didn't want to go back and fix
old data and it turned out that it works
fine with the new data he was dealing
with W cany data so one of the things
that he had explicitly chosen to do he
got bit
by so this is I think this is one that
will lead us into I think our podcast
this time I want to do a little um I
guess we'll talk about like cya kind of
stuff because this something I don't
think we've talked about recently as
much we have touched on in the past but
it's the idea of like status reporting
and communicating and making sure that
you're you're clear on what's being done
and also that you have essentially a
paper trail of some sort so you can look
back and say what did I get done and
when did I get it done sound good does
that sound like a fun topic for this
time
around oh yes definitely uh in fact
we've had similar
conversations uh at work and I've had
similar conversations with customers
along those same lines so I I love this
um so why don't you kick it off then
with kind of the use case or where this
came into play this week with uh these
customers we'll do so while you guys get
to see us kick this off on the audio
side again hello and welcome back thank
you for tuning in we are here uh just
coming right through your ear holes
building better developers developer
podcast once again this episode we're
going to get into a little cya
essentially it's uh 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 uh it initially it's one
of the 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's 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 front line
user and they don't realize necessarily
exactly everything that's going on which
is also an interesting we're going to
talk about because this is somebody that
gets regular status 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 ah 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 parro 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 was really guy good talking to
you guys again at least it was one of
those where just 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 uh so with
a lot of us weide hustles I also still
work for a 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 road map
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
things were at one place but we're
really at another place and if we
actually had understood that oh this
deadine coming we would put more hands
on something sooner instead of this kind
of little short mad the end in this last
Sprint or two uh 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 uh as we
talk about this uh the C is what do you
think about coding standards with cya
where we
Write Clean code that documents itself
so when we come back we don't have to
struggle and try to figure out what was
done I I think that is one of
the the cya aspect of well documented
code is actually very interesting Tac
that I don't think we we've talked about
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
have 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
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 we want to have that road
map of what did we do so we can we can
figure out what we need to do if we're
particular if you're going to like uh 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
uh basically that that road map 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 you know they wrote all these
bugs into this stuff and sometimes you
will have a situation where okay yeah
you wrote you wrote bad Co code
occasionally we 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 a 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 uh I very often we'll
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 exact 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 winkies you
have you know what may be written on you
know jur 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
you essentially have your blueprint as
to what the application does right there
uh if you're doing Java you know include
some simple Java docs uh and if you're
not really good at using Java doc
uh 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 uh that's one approach the
other thing um I want to kind of now
take this 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 talk 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 at
lassan um bit bucket uh like you said
get repository and code reviews so where
do you see those kind of working for C
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 uh 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
and 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 a wrote some code fixed a bug it
like that uselessly INSP specific now
sometimes it's it's nice and you'll have
a and but it's sort of a crutch as
people refer back to like for example a
jro ticket number so I worked on some
code I solve ticket you know 1 2 3 45 6
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 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
going to do a code review they're going
to look at your comments they're going
to say what did you say you did does the
code do that they're going to help you
out and so it's really good I mean
that's like a 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 going to your
company's going to go public then that's
one of the things we're going to look at
is do you have those processes and
procedures in place so that you can
rebuild where you were 6 months ago and
definitely so that you can rebuild
whatever your current version of the
software is
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 test unit test to test the white
box testing of the code you have your
regression test to test the blackbox
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's
going to work and 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 forgo 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 may
be six months old or your apis might not
be right and you send that out to a
customer to 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 uh 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 could go stale easier than
your test can uh your te but your test
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 test 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 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 off 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 well we don't have time
to do that so we're going to write the
code we're not going to write the test
so you do want to make sure that you and
this is where the cicd stuff comes in
that continuing integration 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 um we'll talk like saying
something and nobody's listening which
is the cya part of doing like status and
documentation and tests even if nobody
cares so even though your tests are
there and you're seeing you 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 you're not seeing
your manager is not seeing it or just as
like okay great you did your test uh or
they you know that they never you send a
write a status every day and they never
read it those kinds of things um I
didn't want to talk about get your
thoughts on that is like from that from
your point of view is 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 um
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 cost my company a million dollars
an hour uh I 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
it's turned on you don't want that
um 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 hip violation 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 happen and be able to work it
if there's a problem or if they're
making
change that is one of the biggest not
caveat 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 high
pressure we could be in on a project
that's under staff and now 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
hyperfocused you have to make one change
make that one change but make get the
best way you 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 COA as
our 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 you 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 and 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 got a if you want
to go build a a Porsche from you know
from scratch and 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 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 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 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 screwn
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 uh regardless of
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 picker if you
were to uh 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 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 CIA 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 the in
the ticket that's defined if something
breaks you can refer back to the ticket
and say okay 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 well nobody's ever
going to do that and then you find out
that half of your population does and
that's those are the kinds of things
that you have to watch out for and that
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 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 may be
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 uh and those weird edge
cases you know if you again think things
through
uh 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 a lot of big corporations do the
shift left where they're moving test 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 c
otherwise you're going to be in trouble
yeah I think that's definit that's good
point is that sometimes you don't want
to get the ugly thing out there because
then it's like yeah you 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 um you know just in case that you've
got some limit to your podcast uh
listening time frame today uh as always
show an email info development.com if
you got any questions topics anything
like that that you want to reach out you
can check us out at develop ur.com
there's blog articles there are links to
the 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 uh
that's 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 it's
really important on an audio version is
to make sure that you have like a little
finger thing like next time because
that's so important these are the things
that you get from a video that you don't
get from the audio is all of the like
extra gesturing that goes on then you
realize people that are talking with
their hands does no good on a on a
podcast so
I think that about wraps it up for us
this time on the video side as well so I
can like this wraps us up or something
give a little hand motion there um and
we'll just continue on we've got like
you know we we have these conversations
all the time and uh this one uh has been
a good another one we just sort of like
jumped in it's like hey what are we
running into because like you guys we
are here all the time running into new
every day it feels like we've got a new
problem to solve and you know six
different ways that we need to solve it
so it's h however we can help each other
out we're more than happy to do so uh
can go ahead and subscribe to the
channel and you'll see whatever our
latest stuff is you get it when it drops
we're doing this twice a week Tuesdays
and Thursdays podcast drops the latest
video is going to drop basically the
video version drops at the same time so
you're really not losing anything if you
want to listen to podcast you get it at
basically the same time that you could
get the the video it's just whatever you
know whether you want to watch us or
whether you want to hear us listen to us
while you're going around in your drive
time and you know doing your Uber Eats
or whatever it is you happen to do so we
want to thank you for your
time uh as always leave some comments
out there let us know what you what you
think subscribe and let us know uh what
are some things you'd like to see us to
talk about in the future if you've got
anything in particular that youve has
been bugging you we'll be more than
happy to either cover it maybe here or
you can shoot us that email and we'll uh
we can take that offline and and talk to
you that way way as well we're always
looking for ways to solve problems and
yeah we have a bunch but we're always
looking for more so any uh parting
thoughts from you
Mike yeah the only thing I would like to
add in addition uh if you are watching
the video uh just make sure to check out
the notes section in uh YouTube or go
out to developer.com and check out the
blog for the podcast we do put
additional links in there to other
material and also to some of the
software that we talked about within the
uh conversations that we have uh good
point yeah I always I forgot to say and
you know links in the show notes because
that's almost always going to be there
there's going to be links to us and
where we can other places that we
reference so I think that'll wrap this
one up we're going to go get back to our
normal non-developer lives and you guys
have a great one and we will talk to you
next
time