I’ve been talking about code smells for a while, but code is far from the only thing that can go wrong. What about process smells? There are things in your development process that may not necessarily be wrong in every situation, but are a signal that something could be wrong. Some of these are more definitely stinky than code smells, but not all of them. As always, if you’re happy and productive with the way your process works, stick with it!

Here’s an example of a process smell: Friday prouction deploys (in case that tweet ever gets deleted or something, it’s a picture of a jack o’lantern with the words “Friday deploy to prod” carved into it and the caption “Scariest Pumpkin”). Friday deploys are almost universally a terrible idea, which makes them an especially nasty process smell, but once in a while they are actually a reasonable choice. Usually when they’re the least terrible of a set of bad options, but sometimes bad options are all you have.

If you’re fixing a severe bug that prevents a lot people from using the system at all, then it makes sense to deploy whenever you have a fix, even if that’s a Friday, even if it’s late in the day on a Friday. And if you have the unusual luck to have a dev team with staggered schedules who are all familiar with the code being deployed, then no day is really any riskier than any other (is this actually a thing? I included it because it’s technically possible but I’m not sure it actually happens anywhere).

If you work in a very rigid environment where nobody uses the system over the weekend at all ever, then knock yourself out! If no one touches the system over the weekend, then you’re not going to hurt anything by deploying on a Friday.

Most of the time Friday deploys are just a bad idea. Why?

Because no matter how great your QA department is, even they can’t test every single possible combination of weird commands and bad data and dodgy wifi that your actual users or customers can, which means things may break in wildly bizarre ways when no one is around to fix them. That sucks for your customers and sucks for your support team and sucks for your revenue and sucks for your reputation and sucks for your stress levels when you come back and discover that everything has been on fire all weekend. Oh and it sucks if you get called in to fix it when you thought you were going to have a nice relaxing weekend. Spare yourself and the rest of your team a lot of hassle and don’t deploy on a Friday (or late afternoon any day) if you can avoid it.

This process smell is really interesting if you keep in mind this definition of a code smell, by Martin Fowler:

A code smell is a surface indication that usually corresponds to a deeper problem in the system.

If you’re deploying to production on Fridays, there’s definitely a deeper problem. Who is even letting you do Friday deploys when they’re so widely acknowledged to be a bad idea? Or who is pressuring you to do them when you know they’re a bad idea? And why is that person getting away with it? Who is pressuring them? Why is it more important to say something went out than to be sure that somebody is around to fix it if anything breaks? Or, and this is really scary, is management assuming that developers can be called in any time night or day to fix things?

Unfortunately, there isn’t a neat set of fixes for process smells the way there is for code smells. If I could give you a few quick and easy steps to convincing your company that deploying to production on a Friday is a bad idea, I’d be a millionaire :) What I can tell you is that you need to understand why your team lead / manager / upper management thinks it’s a good idea to deploy anything on a Friday before you can convince them to change. If the problem is that upper management believes it’s lazy to wait until Monday when the deploy could be done on Friday, then explaining that deploying on Fridays hurts team morale by making people worry their weekend plans will be wrecked by a surprise issue isn’t going to convince them anything needs to change. On the other hand, if you remind them how angry your customers were the last time production went down on a weekend and stayed down for hours because that particular release wasn’t possible to quickly roll back and the developer who knew the most about that change was away on a long-awaited hiking trip, and tell them there’s a way to prevent that from happening again that costs zero dollars, you’ve got a much stronger case.