Accepting a job that failed The Joel Test

A user recently asked:

I’m about to accept a job offer for a company that has failed The Joel Test with flying colors.

Now, my question is how do I improve the conditions there. I am positive that within a few months I will be able to make a difference.

But where do I start? And how?

Don’t view yourself as the “new sheriff in town” who’s here to clean it all up in one year. The habits they have settled into have been a long time forming.

Watch and listen, and ask questions about the most severe and recurring pain points. Find out what bad habits have actually caused loss of work, late nights, quality problems, or lost customers. Try to quantify the cost of these bad habits.

Then at some point talk to your boss in a one-on-one meeting and make a proposal for how you could mitigate one specific risk that seems to be their biggest problem. It could be almost anything on the Joel Test, but I’d guess it’s most likely to be one of:

• No source code control means the code is a mess, with lots of “commented out” sections. Can’t track which code changes were made for a given bug. It’s hard to do major features in parallel with ongoing maintenance. No way to roll back changes. No way to track which developer did what changes.

• No build process means some code changes exist only on the live server. Developers are constantly pushing and pulling code to and from the live server. No one has a development environment that’s in sync with the live code, so it’s hard to reproduce bugs.

• No bug database means some tasks “fall through the cracks” from time to time. Customers report bugs that fall into a black hole. Managers don’t know what’s being worked on. Employees have no record of their work when it comes time for annual reviews.

When presenting the solutions, don’t try to justify them with abstract concepts like “best practices” or “it’s the industry standard way” or anything so intangible. If those were enough to motivate this company, they would have done it by now.

Instead, focus on what is their deciding factor. I’d guess it’s probably related to how much time and money it costs the business to use best practices, versus how much it can save them. But you should find out if this is really their reason. It’ll take some setup work to establish these tools and practices, but you can explain the recurring benefits for quality, productivity, and predictability of the development work. All those can contribute to the business’ bottom line.

In one year, you’ll be doing extremely well if you can make just one change to help them. It’ll take a lot of patience to overcome a development culture that has been building for so long. Keep in mind that the rest of the team isn’t there by coincidence — they may actually be compatible with that level of disorganization.

I’m posting to my blog the questions I’ve answered on StackOverflow, which earned the “Good Answer” badge. This was my answer to “Accepting a job that failed The Joel Test“