Most developers have heard of the "
Joel Test". At least, those developer that have spent much time researching development methodologies and keeping their finger on the pulse of tech in the past ten years. Developers are always looking for ways to evaluate places that ask them to do work, and I am no different. The thing is, some of those items don't necessarily apply to the modern development environment, so I've updated it for 2016. I've also weighted them so that it's clear what is a necessity, and what is a nicety.
Must Haves
- Are you an agile shop?
- Do you have a well defined audience for your product?
- Do you have a product owner?
- Do you use version control for all code? Distributed version control?
- Do you utilize Continuous Integration (CI), or even better, Continuous Delivery (CD)?
- Do you keep an up to date issue database?
- Do you do hallway usability testing?
- Do you have the best hardware and software that money can buy?
Nice to Haves
- Are you profitable?
- Are developers encouraged to actively participate in requirements gathering?
- Do developers have quiet working conditions?
- Do you allow developers to work from home?
- Do you have a schedule?
- Are there product testers?
- Do candidates write code in their interview?
- Do you provide training opportunities for your developers?
- Do you encourage writing unit tests for all features?
As I see it, on the "must have" list, you really should be able to answer every single one of those with a yes. If not, you're going to need a really good explanation. If it's more than one, you probably have a serious problem on your hands. On the "nice to haves," slightly over half would probably suffice, but really, you should try to hit them all. If you want to be competitive in the market place, and a good place to work, you'll want to make sure as many of these are true as possible, along with being in the top 25th percentile for compensation. It is a very competitive market for engineers, and anyone that isn't providing proper care and feeding of their development staff will soon find that someone else will.
Of course, these are all open to subjective interpretation, because each developer will have their own ideas, but let me provide you with my take on why each of these are so important.
Must Have #1 - Are you an Agile shop? ("a"gile? Scrum? Kanban?)
Waterfall is dead, long live waterfall. It's been nearly two decades since Agile was coined, and still many shops haven't implemented it, and many developers haven't been trained in it. Even if you don't subscribe to a particular set of practices (a la Scrum), lets hope that you at least know and live by the
agile manifesto.
Must Have #2 - Do you have a well defined audience for your product?
In order to be able to know how to build your product properly, you're going to need to know exactly who you are marketing your product to. If you don't fully understand who you are marketing to, then you need to go back to the ideation stage of your product, and figure that out. If you can't answer that question thoroughly, you can't move on to development.
Must Have #3 - Do you have a product owner? Bonus points for documenting requirements.
Many products have languished in software purgatory over not having a visionary that is leading the development of software. This is because every point of software development is about managing trade offs. If you don't have someone with a firm grasp of where you are going, you'll never know what kind of trade offs that you can make.
Must Have #4 - Do you use version control for all code? Distributed version control?
Software is part of your companies DNA if you're hiring software engineers. First and foremost, you should be making sure that you're keeping full control over that software that is being produced. That's only a side effect however. Primarily, the purpose here is to enable and facilitate efficient and consistent collaboration between software developers. That is its number one duty. Without a solid version control system and process in place, crashing and burning is all but inevitable.
Must Have #5 - Do you utilize Continuous Integration (CI), or even better, Continuous Delivery (CD)?
This is all about the build. You should be able to build immediately on check in. If you can't do a build and check to make sure all your tests pass, at the least, you're not going to have any level of code quality that is being ensured. This is the first step towards a well tested piece of software, without it, it can fairly be assumed that testing is discouraged passively, if not actively.
Must Have #6 - Do you keep an up to date issue database?
If you don't know what your bug trends look like, it's hard to tell if you have a fairly solid piece of software. Further, if you don't have a strong understanding of how many bugs are in your system, you'll have no idea if you should be actually doing deploys. This should guide every step of your development process.
Must Have #7 - Do you do hallway usability testing?
Developers should constantly be bugging the product manager, or at least doing usability tests between themselves. To make sure that what they're building fits in with expectations of others. If not, it's very easy for them to go off the rails and build something that they think is neat, rather than what the product actually needs.
Must Have #8 - Do you have the best hardware and software that money can buy?
This should be a no brainer. If you're going to pay a software engineer six digits per annum, don't skimp on the things that they need to do their job. 5% of salary yearly budget seems like it would be a start, though a stronger offering would be 10%. This is the primary way to show that you really want a developer to stick around. Removing any possible roadblock to them doing their job. Computers and software are the tools of the trade. Don't offer, or accept, anything less than the best.
Nice to Have #1 - Are you profitable?
Many companies aren't. That's fine, but you need to have a really strong reason that you aren't profitable at this time, and have a path to profitability in the near future. Or at least a way to be certain that you can make payroll. If developers aren't confident that they'll receive their paycheck, you can assume their eyes will be wandering.
Nice to Have #2 - Are developers encouraged to actively participate in requirements gathering?
Product managers, business analysts, et al, can theorize all day long. Unless a developer is actively involved in their ideation efforts, and helping to keep ideas firmly grounded in reality, you could end up handing requirements to a developer that will take them months to implement. Even years. If they even are capable of doing so. Developer feedback should be highly encouraged.
Nice to Have #3 - Do developers have quiet working conditions?
Despite many trends that are going in the opposite direction, developers need quiet time. This is how the magic happens. If developers down have quiet time where they can be heads down and write code, they wont be able to get their job done. Over collaboration slows down production just as much as being completely out of sight and out of mind. Slack, and tools that assist in communication, but don't interrupt flow, are perfectly suited for interacting with developers. They don't require instant reaction, but they aren't email, which can be completely overlooked.
Nice to Have #4 - Do you allow developers to work from home?
There is no intrinsic reason why development needs to be done at a shop. Or even from the same continent. That's why offshoring was so popular for a while. That said, there are reasons to get together and make sure that 'the magic is happening'. Office space can certainly be used for that purpose, but it shouldn't be thought of as 'where the magic happens'. The magic happens wherever development happens. For some people, that's harder in a sterile development atmosphere. Flexibility is key.
Nice to Have #5 - Do you have a schedule?
If your software lives on a schedule, is it posted? Why is it scheduled? Remember that agile development is all about working software, customer orientation, and responding to changes. Deadlines and plans are all guesswork and, in many cases, wishful thinking. Sure, you can have some idea of what you want done, and by when, but that doesn't mean that it'll happen. Good software takes time, and if you have your audience right, they're going to be happier waiting for solid software, than complaining about software that isn't working correctly.
Nice to Have #6 - Are there product testers?
Sure, developers can test software, but they're very myopic. They only see the feature that they just implemented, and don't tend to look at the bigger picture. Some developers manage that, but they're a horse of a different stripe. A unicorn, so to speak. Ideally, someone from your target audience would perform user acceptance testing at a minimum.
Nice to Have #7 - Do candidates write code in their interview?
How do you know if a given developer can code? You ensure that by actually having them write you some code. Keep in mind that if you do it during the interview, it's very likely that they're extremely stressed from the interview experience itself, and wont be operating anywhere near 100%. You could alternately offer them a code test on off time, or just have them explain a code project that is all their own that they could walk you through. Either way, you want to see some kind of code from the developer. Would you trust a designer that didn't show you a portfolio? Probably not! Same goes for developer.
Nice to Have #8 - Do you provide training opportunities for your developers?
Developers have serious upkeep requirements. One of the big ones is making sure that they're staying up to date. This means giving them opportunities to learn now things. This can take the form of a 20% rule, like Google. Or it could be conventions. Any number of ways, but developers should always be investing in themselves, and this is how it is done.
Nice to Have #9 - Do you encourage writing unit tests for all features?
Tests aren't really optional anymore. Software moves too fast in the modern era, and you need to be able to test it at every step of the way, and be confident that it works as expected. Without tests, your confidence level diminishes rapidly. You should be writing tests for all new features, but if you aren't, you better have some other very serious testing plans at hand.