5 Not So Innocuous Code Changes
Posted by Charlie Recksieck
Unforced Errors In Software Deployment
And if you're working with a developer, your instinct of "How long do they need to change a simple typo?" can be wrong-headed. If you want your programmers or web designers to just change a word in a live app or website, you're asking them to break protocol for version control, rollbacks, and backups.
Sure, it might work out 9 times out of 10 to just do the faster, improvised approach. But on that 10th time, things are going to get ugly.
Here's our Top 5 examples of what seemingly easy changes can really come back and bite you in the ass.
Changing Text For A Typo
Altering production files on a live website sure seems easy. But only if you have absolutely no "source control" where latest files are checked in and out. (If you have no source control, get out of the business.) If you're paying a contractor developer you might think that you should only get charged 10 minutes tops on an hourly rate.
The Likely Problem: The developer changes it on the live site in one place. But not in the source code repository. So, the next time there is new code in a week or a month, they work in with the "latest" source code, test, compile and deploy ... your previous change of that typo has reverted. A complete waste of that earlier time and you're now double-fixing that stupid little change, and spending time reconciling which chunks of code you want from one version and which chunks you want from another.
New Software Works Great, Push It To Users
It's been heavily tested in the IT department. Worked well for the programmer, the QA specialist, the IT supervisor. Time to send it out to everybody in the company?
The Likely Problem: The IT department has a different platform as the rest of the users throughout the company. They're on Windows 11 where the rank-and-file folks are Windows 10. Developers have .NET framework 4.8 vs. everybody else's 4.7. When you push out the new latest and greatest software, it doesn't run at all. Everybody in the company thinks the IT department is incompetent and lose faith in the software and the company. Oops.
Swapping Out An Image
You have a better photo to use where you didn't like the previous one. Sounds easy enough, right?
The Likely Problem: What if the photo is a different size? Where it really gets ugly as that when the developer and you look at the revised page with new photo on a desktop or laptop browser, it looks just fine. You didn't test it on a phone and you never saw how it completely disturbed the responsiveness of a mobile site.
Deploy Any Time Of Day, No Problem
You've thoroughly tested the new software. You've done everything right. Go ahead and schedule the rollout for 10am. Why does that matter?
The Likely Problem: Yes, the software works. But deployment actually takes 5 minutes to copy all of the files. With no heads-up, employees or customers have no idea why the software is broken. Even more likely, with an app being redeployed, it kicks off logged-in users. With mid-day rollouts, your people have been spontaneously kicked off the app for no reason. Instead, deploy after hours.
GUIs/Forms That Popup In Previous Spot They Were Closed
It's great that you have your windows pop up right where you last used them. Especially in the era now of ultra-wide screens or dual monitors, people love managing their software windows where they like them.
The Likely Problem: Your user had his/her laptop hooked up to a dual monitor and had the form on the far right monitor. The code successfully remembered where that was. But when he/she came back to the program, they were using the laptop screen away from the dual monitors. That form thinks it's popping up on the far right, but that's off screen for the laptop monitor so it's never seen. Worse yet, that window has the focus, so you can't type, escape, click or close it in any way. You are stuck. If you do code like this, you need to write in the ability to have a special key like F3 or something move that missing window to position 0,0 at the upper left of the display area.