Way back in 2001, Joel Spolsky wrote The Joel Test. The Joel Test has become the de facto standard for judging a company’s software development prowess. It was like the Software Engineering Institute’s Capability Maturity Model (CMM) only it could be read and understood by people without a PhD in Computer Science from Carnegie Mellon.

Fast forward fifteen years and Stack Overflow is still using the Joel Test as a standard for potential employees to gauge a company’s software development sophistication. The problem is that the smart kids have moved on - the same techniques that were relevant to desktop software engineering in 2001 are not necessarily relevant to the myriad software engineering in 2016.

So I reviewed the Joel Test and wrote the following based on how we do things in 2016.

  • Did you build Henry Ford’s Assembly Line?

  • Do you have automated tests in the form of a Continuous Integration (CI) system such as CircleCI?

  • Do you have automated deployment in the form of a Continuous Deployment (CD) system such as Shippable triggered by the CI system on successful test completion?

  • Do you use a Distributed Version Control System (DVCS) such as Git or Mercurial?

  • Do you have an issue tracking system that uses mnemonics to tie source code changes to bugs or feature requests, like Github?

  • Do you have a system that allows you to visualize the issues temporally, or in terms of status like Zenhub?

  • Do you triage issues before coding them?

  • Do you examine your lightweight process retrospectively in postmortems?

  • Do people feel safe to speak truth to power?

  • Do people have the option to work remotely, in pairs, in groups, or with headphones?

  • Do you have an interdisciplinary approach that identifies and resolves tension between finance, design, engineering, marketing, and sales?

  • Do you have multi-faceted interviews that consider business, math, science, engineering, design, culture, personality, and professionalism?

Commentary

Ford’s insight was that building one car is not a scalable business. Rather, no matter your widget, you need a system for making widgets efficiently with diminishing costs over time. In software, this involves minimizing technical debt, automating efficient business processes, and diminishing inefficient business processes. We accomplish this through lightweight software process.

The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency. * Bill Gates

Most of what I’m asking above, I learned from reading Demarco and Lister’s Peopleware and (Alistair Cockburn’s Crystal Clear. The most imporant part of the book is summarized in [Seven Properties of Highly Successful Software Projects](http://alistair.cockburn.us/7+Properties+of+Highly+Successful+Projects+from+Crystal+Clear).