Ver. 1.3.3.7
The Joel Test is a great way to check if your potential employer or current employer has a good handle on their software team. The Original Joel Test is great, but it is aimed at complied languages in a non-web-application environment. This is a basic rephrasing of the test to suit web app development with minor updates for developing in 2015. The test is actually part of [posting a job on Stack Overflow][http://careers.stackoverflow.com/jobs/post], and rightfully so. The language just needed some updates for it to work for my company.
The test is simple. If your company meets the requirement, you get a point. If you don't meet the requirement, you don't get a point. There are 12 questions, so there are a possible of 12 points available. Simple enough, right?
As the original test says 12 out of 12 is perfect, 11 is okay, 10 or less is failing. The reason the test is so strict is because these are 12 HUGE IMPORTANT annoyances for developers. If these are not in place, working there will quickly become an annoyance or the team will have major issues functioning. Most of the tools required to meet these guidelines are free, so every company should be getting 11's or 12's. Unfortunately, this just isn't the case. I've worked somewhere that scored a 2 out of 12; it was not fun.
Let's get to the list! And don't forget to check out the original article, as Joel has additional articles touching on all of these subjects.
Firstly, do you use source control? If you answer "no", you get a negative 1 point. Why aren't you using source control in twenty-fucking-fifteen?
What you should be using is distributed source control - that is, [git][https://git-scm.com/] or [mercurial][https://www.mercurial-scm.org/]. You can get accounts at [GitHub][https://github.com/] for free, and private/commercial accounts aren't really that much. In the end, every single developer has a backup of the entire repository! It mitigates loss of code. Merging is a breeze, so experimentation is cheap. It is local, so it is lightning fast. It keeps your team working together - independently!
What happens when your new dev changes the database? Does everyone need to open some other tool before they can pull the latest changes? This is a huge time-killer, and it is so 90's.
Git, for one, has event hooks so that you can script various events. You can (and should) set up a script so that pulling is the only action your team needs to take to get the latest code on their workstation. Dependencies need updated, databases need updated, and all this can be done without taxing your dev's patience. Pull, merge, done. That's how it should go.
Are all your devs running fancy Windows 10, and your designers running hipster-ass Mac OSX? Yes? Are your servers Macs or Windows? No? See a problem?
Look, your web application is going to behave a little different on other systems. That's okay, but we need production launch to go smooth. That means we need to know if the environment is going to have any effect on the app. You need to have some test servers available, and they need to be exactly like your production ones (or as close as fiscally possible). Furthermore, every change needs to be tested on the testing server before it is made live. None of this "oh, we can just change it on the live server" crap.
Digital Ocean has cheap and easy ways to make copies of an entire server, so you KNOW it is the same! VPS is the way to go, kids.
You know that GitHub thing I mentioned earlier? It comes with an issue tracker. You can use this to not only keep track of your project's tasks, but bugs as well! You can even reference specific versions of code, files, and more! It also serves as a wiki/discussion of all issues. If ever you need to figure out why someone dropped the ball on a bug that was supposed to be fixed already, this will help you hunt down the sorry bastard!
All your bugs go in the bug tracker! Not in an email, not in a code comment, the bug tracker.
This is still a good practice, like it was when the original Joel Test was written.
All bugs must be fixed before marching onward to write more code. Even better, is to adopt regular testing and [TDD][https://en.wikipedia.org/wiki/Test-driven_development]. Unit tests may seem like a waste, but they help weed out a lot of small issues before they become troublesome.
First, every project needs a schedule. Secondly, you need to stay realistic about that schedule.
Don't allow scope creep, and if you get behind communicate that. Not having a schedule or, allowing it to become inaccurate is really demoralizing and discrediting.
Part of eliminating feature creep is writing a spec. Everyone from [marketing weasels][http://dilbert.com/strip/1995-07-04], to [PHBs][http://dilbert.com/strip/2015-12-15], to engineers need to have a reference of what is to be delivered. Be specific, and read this entire [article series][http://www.joelonsoftware.com/articles/fog0000000036.html]. Trust me, it is entertaining, informative, and just a plain good read!
The original Joel Test goes in depth with this, and it is worth taking in every word. Don't allow [disruptions][https://www.youtube.com/watch?v=4c0lk-LtLI0] in the workplace. Open-plan workspaces might be "hip" and "fly" with the coolio start-ups down the block, but they have disadvantages that real adults notice rather quickly. The coffee-bar atmosphere turns your workplace into... well... a coffee-bar.
Either make sure your team is clear on policies regarding disruption or put up a fucking wall (literally). I have ADD as it is; I don't need my team starting up a conversation about the new Star Wars movie or asking stupid questions that could be Googled in 30 seconds.
Personally, we don't. We use a lot of free software, [Linux Mint][http://www.linuxmint.com/] as our OS, and mid-range hardware.
We also know that sometimes you need to spend money. We pay for private GitHub accounts, online tools, fiber-optic Internet, and everyone has at least two monitors. We keep the office stocked with beer, tea, coffee, water, snacks, and sometimes lunch. We have a 6-foot-wide whiteboard, and all the graph paper you could ever want. We have spare USB sticks, phone chargers, and batteries.
If your employees might have to come out of "the zone" or leave the office for some reason, ask yourself if you can avoid that. An $89 monitor is a small price to pay for productivity. Free beer and coffee is pricey. A half hour trip to Starbucks during crunch week is pricier. Having all your basic needs in the next room... priceless.
Remember when I said debugging and testing regularly is good? Wouldn't it be nice if you could have interns or junior staff do this instead of seasoned devs? Well now you can!
Introducing testers! Simply hire some less experienced (read: expensive) individuals to be responsible for testing and finding bugs. Not only is it economical, but your testers will probably look a little closer at the code then your senior devs.
I know that when I write code, it is perfect in every way and can never fail. Unfortunately, having Abby play with it for five minutes often breaks it beyond recognition. Magic? Confirmation bias? Narcissism? Who knows?
If you are a PHB you're probably looking for a way to shift blame if a new hire goes wrong, and we've got a cool new idea on how you can do that! Have your candidates write some (small) code during the interview. Better yet, have one of your best devs do the evaluation! Instead of asking questions that can be Googled in 5 seconds, have an actual developer review actual code as it is written!
I like to also take time to casually converse with them about their coding preferences. A knowledgeable dev will not only be able to talk about coding, but will have deep-seated opinions about all things software related. Maybe they love .NET and you think it is Microsoft-poisoned dog crap, but they can tell you why they love it and you'll learn a lot about them in the process.
Not to strictly say you must pull a random person out of the hallway, but do you bring a non-dev in to look at your interfaces? Do you bring a non-manager in? Can you get 5 or so differing people to check out your interface? This is cheap, it takes little time, and it is super effective! Like ghost type vs normal type effective!