10 Mistakes Developers Should Avoid

There are many challenges in web development. Typically, a development workflow requires multiple platforms in order to deliver a product. Unfortunately, having more tools means developers spend extra time performing manual work, losing focus on the important tasks. Here are ten common mistakes developers make.

Making Changes Directly on The Server

Come on, admit it. We’ve all done this before. You’ve got an anxious client who needs a small change, so you take a shortcut and make those changes directly on the server. You quickly get them out of your hair and everyone’s happy.

Except those changes don’t get reflected in the repository and are lost in the next deployment. That’s double the work and a client who is unhappy to see the same issue yet again.

Downtime Susceptibility

During deployment, while new files are being uploaded, your site can go offline. If it’s a blog, it’s not a big deal. But what if it’s an eCommerce site? Imagine a customer in the middle of purchasing an item and the site goes down just as they hit the “buy” button. Not good!

Performing Manual Deployments

Manual deployments are time consuming, complex and frequently cause great trouble. A couple of inadvertent keystrokes made by an inexperienced developer and bang! You’ve got yourself the virtual equivalent of a nuclear meltdown. All the time you thought you were saving is instantly gone as you rush to put everything back together again.

Using The Same Environment for Development and Production

Everyone loves simplicity. So why bother with the added complexity of separate environments for development and production? Pushing changes directly to a production server is like playing with fire. Sooner or later, you’re bound to get burned. Now, the excuse for those using a manual workflow is that deploying to two different platforms takes too much time. But that’s just another reason to automate!

Having No Backup Plan

Having a backup plan is like having insurance. If you wait until you need it, it will be too late! If a change that’s deployed to the production server actually breaks the server, you’re in trouble if you have no backup plan. You’ll need to start at the beginning, successively performing new deployments to get everything back to a normal state. That takes a lot of time and resources; significantly more than rolling back to a prior deployment, which those of us with a backup plan can perform.

Not Notifying Team Members

The typical developer is always busy working on new features and making changes to their code. Sometimes they have to wait until the deployment finishes to see if the reflected changes are working as they should.

Having a poor communication channel and not notifying everyone on the team about a finished or failed deployment is a huge mistake. Developers lose their focus while waiting for a notification they'll never get.

Performing Manual Builds

Developers usually code in a way that is easier to read and understand, but this comes at a cost. Left as is, the code is significantly larger and runs slower, which is why it’s minified.

But using separate tools to minify the code takes a lot of time and effort. And relying on that minified code for future developments is just asking for trouble.

In theory, process automation in those cases seems to be a great idea. But in practice, it usually requires multiple tools and a ton of work to make them work together.

Not Monitoring Code or Tracking Errors

Most developers are faced with issues of monitoring and error tracking. But the majority don’t really bother to monitor their code or track errors. The biggest problem is not getting deployment errors and monitoring in a monitoring service, and successful/failed deployments with detailed fault codes.

Some may have a superb monitoring and error tracking platforms, but it gets messy switching constantly between platforms, not to mention the time wasted on these small tasks.

Poorly Communicating When a Deployment Occurs

It’s always a good idea to let your team know when you’re ready to deploy. That way they can be available if additional support is required or the changes don’t perform as expected. Manual notification isn’t ideal because it’s susceptible to error, and using different platforms for communication and notifications unnecessarily complicates matters.

Not Using DeployBot

Perhaps the biggest mistake that developers make is not using DeployBot. It’s the answer to all these problems. Build tools allow you to automate tasks like concatenating and minifying scripts, preprocessing CSS, compiling the code and running tests.

DeployBot has really good integration with top of the class monitoring and error tracking applications. It sends a notification on every deployment using your favorite communication channel.

DeployBot allows team members to make deployments without having direct access to the server and lets you quickly rollback a problematic release. You can deploy to different environments simultaneously or at different times.