Listen or read below.
Business Advantages with Custom Software Podcast – Episode 003
Carlee – Hi, everybody. This is Carlee, and you’re listening to the Business Advantages With Custom Software podcast, the show that helps businesses achieve more with software. I’m here with the President of Tornado Technologies, Mark Roshon, and the General Manager, Tom Loya. Today’s topic is what if my programmer wins the lotto? Mark, wow, what an interesting topic and question. Have you actually had a programmer win the lottery?
Mark – Well, no, not Carlee, not the proverbial win the lotto, but certainly we’ve had lots of cases where the programmer was no longer available for a variety of reasons. The company went out of business. Unfortunately, we’ve had multiple times where the programmer actually passed away unexpectedly, or maybe the relationship sour. That can bring up all kinds of issues. Or in one case, change careers. I mean, we had a client, they had a programmer on a Friday, and then on Monday morning, boom, the programmer says, “I’m out of this. I’m not programming anymore. I’m actually changing careers, and I don’t want anything to do with this anymore.” It’s been many different situations like this. Now, Tornado, we’ve been around since 1996, so we have been able to give our clients some stability. Tom, you’ve been with Tornado for over 20 years now. I know you’ve had to personally take on some projects where the programmer was no longer available. How challenging is that situation?
Tom – It certainly can be a challenge. Really, what it comes down to is how well is that company prepared for this situation. There’s plenty of actions that can be done by a company to make sure that they’re prepared to take on a new developer, or what do you do if your developer wants to leave and make sure that there’s not a short term crisis on, What do I do with my software if this programmer leaves? What do I do? There’s plenty of things that can be done to make sure that transition is easier.
Mark – Well, could you share some of those points with us?
Tom – Certainly. One of the biggest things that can be done, I could think of four right now that are just easy things to make sure are done. One is to make sure that the source code is available. If that programmer were to leave, win the lottery, and they are no longer there at that moment, you should have access to the latest source code that you have. You want to make sure that that source code repository is under your control. It’s not even very expensive to make sure that you have your own source code repository and a little bit of investment in your own repository could be logging in and having a GitHub service, for example. Having that little bit of ownership of that repository can save significant issues if that developer is no longer available. What if they have been making changes to your software for a year and they weren’t checking stuff in and nobody has access to it? You have a real problem. But if you have access and you have control of that source code repository and you are monitoring it to make sure that they are actually using it, then if they win the lottery, they don’t want to be a programmer anymore, you have everything to at least build your software.
Tom – Second thing I could think of, and this is a big one and it’s an easy one, is to make sure that passwords are documented. I know it’s scary to record your password somewhere that other people can access it, but if you store your passwords in a secure location, it’s probably okay as long as only those people who need to know those passwords can access it. We’ve had times where a developer is the only person who knows these passwords. And if that developer leaves and they’re the only one who knows that password, you have a problem. Make sure that you know the password. It’s even better if you generate the passwords and they have to use it instead of them coming up with their own. It’s okay if they come up with their own as well, but as long as other people know this password. The third one is make sure that programmers is not using their own personal email. This could be the sign up for, maybe signing up for the source code repository, or maybe signing up for some service that you need to use. Maybe your software ends up logging into a timekeeping system and it’s pulling timekeeping data.
Tom – Maybe your software needs to log into a timekeeping system and it’s pulling timekeeping data. Well, if the programmer used their own email and then all of a sudden they leave, then all of a sudden they have control of using that. They have control of using that service. They could change the password, they could do whatever they want to that service, and it could actually cause you problem. If the relationship soured, they could say, Well, I own that service. I own that access, so you’re going to have to pay me for the password, and you want to prevent that from happening. Whether that’s right or wrong, you don’t want to go through the legal issues of trying to get that programmer to give over their data, give over their passwords, to turn over that service. It’s just easier if you use your own email and your own password. A great example of an email would be Support email. We use support@tornadosoft.com. That way, any of our software developers here aren’t the sole owners. We have control of that email. If we have to do a password reset, it’s no big deal. We do a password reset and several people have access to being able to change that.
Tom – Really the last one I could think of, it’s what I’ve been hitting on the whole time is redundancy. Any time that more than one person can do something with your software, the better. And anytime maybe your software repository, there’s backups of it. Redundancy is always better. Having other programmers that have never used the software and say, Hey, can you run our software? Can you build our software with what we have? Is a good thing. That way, if you said, Hey, Tom, can you build the software? And I try to build it and I can get it to work, then you know and you have lots of comfort that if your programmer ends up leaving, that there’s enough information to continue on with the support of your own software. This list is certainly not an exhaustive list that your business can do to mitigate any issues. But if you follow these basic ideas, it’ll go a long way of preventing any short term crisis that could turn into some long term problems just by following some of my suggestions here.
Carlee – Thanks, Tom. Mark, any final thoughts you would like to share?
Mark – Yes, Carlee. I just remember that there’s many programmers that unfortunately very much dislike taking over someone else’s code to the point that they will actually tell you that you’re better off just rebuilding the application. And that’s just not true. In fact, that’s a whole topic on itself. You know, Carlee, let’s make that our next topic. And just if you want to make sure that you are prepared for an unexpected change in programming staff, give us a call. We’ll be happy to review your current set up and let you know. You can reach me directly at 440-567-1430. Okay, back to you, Carlee.
Carlee – Thanks, Mark. Well, thank you for listening to Business Advantages With Custom Software podcast with your hosts, Mark Roshon and Tom Loya. We hope you enjoyed our conversation around the question, What if My Programmer Wins the Lotto? If you’re keen to learning more about Custom Software, join us next time when we’ll be talking about transferring a project to a different programmer. As always, you can head over to tornadosoft.com to learn more. That’s all for this episode. See you next time.