3 Bad Software Engineering Practices I’ve Seen

Senior Brogrammer
4 min readJun 13, 2022

So far I’ve had an excellent experience in the software field compared to some of the horror stories. However, no matter how good things are you’re going to come across some bad practices/poor choices made. Choices aren’t intentional and were made under different circumstances, but the practice is still bad. I’ll dive into 3 of them that really stood out to me throughout my short career.

Software | Credit: Geralt Altmann on Pixabay

1. Copy, Paste and Modify Code

First time seeing this I was shocked, but totally understandable how this occurs. At school everyone was taught not to copy and paste code, instead change the code to work with both scenarios instead of copying and modifying the one piece that changes. However, in actual practice sometimes the case isn’t obvious or other things like due dates end up popping up. Sometimes when rushing a project a developer might do this unintentionally (or intentionally in certain cases) to finish up code instead of properly refactoring the function for reuse. Try to rush a due date and you’ll make a ton of mistakes like this.

A second reason you’ll find this is in old code that was written by non-developers. In several companies engineers in different fields will wear different hats to write code. A simple script running on hourly in a EC2 instance might get out of hand, and needs to be passed off to developers. If you don’t think this happens, wait until you work at small to medium size firms and it’ll live everywhere. So not everyone might not know best practices and copy, past and modify code might exist depending on what is being worked on.

2. Friday Deployments

Deployments are the scariest thing to do no matter how good the CICD process is. Several things can easily go wrong that would bring any beautiful system into flames. So why in anyone’s right mind would you take such a difficult process and attempt to perform it on a Friday right before the weekend starts?

Sure if a quick error pops up that doesn’t require a lot of time to fix and can be redeployed, but let’s be realistic failed deployments come in all shapes. Wait until one of those issues is a ticking time bomb that explodes at 2am because you forgot to increase read/write capacity units on a AWS service. Several concerns of…

--

--