I recently stumbled on The Joel Test: 12 Steps to Better Code while perusing a job ad:
- Do you use source control?
- Can you make a build in one step?
- Do you make daily builds?
- Do you have a bug database?
- Do you fix bugs before writing new code?
- Do you have an up-to-date schedule?
- Do you have a spec?
- Do programmers have quiet working conditions?
- Do you use the best tools money can buy?
- Do you have testers?
- Do new candidates write code during their interview?
- Do you do hallway usability testing?
Joel Spolsky has well written reasoning for each of the 12 steps. What struck me was how much I agree with him. Having worked in startups (not one of steps implemented and coding was difficult) to larger companies (about half the steps implemented, and coding was slow) I can definitely see the benefit of the 12 steps. The only comment I can really make in that places that required documentation and specs I didn't write as much code as would have like to.
I remember once asking my manager (Dirk Stanley, absolutely the best one I've had in my career) if I couldn't spend more time coding (i.e. not documenting, updating specs, and the most time consuming all, dealing with other teams in other time zones trying to hash out interfaces and functionality to make sure everything would work) . His basic answer was "If you can get one line of code in per day your doing great." Of course he was exaggerating and the point being is that things could be much worse compared to the other teams on-site and it also made me realize that he was doing quite a bit of work to keep us coding. We ended up having a lot of success and it was because of the other steps we did to support the coding. But the non-coding tasks were initially an effort until it became second nature.
The other thing I liked about The Joel Test is that is really old school and perhaps some of the craziness with Agile and eXtreme Programming (dual programmers, clients breathing down your neck with constant feature changes, not documenting what you've done) has run its course and the pendulum is swinging back to normality. Joel states in the beginning:
The neat thing about The Joel Test is that it’s easy to get a quick yes or no to each question. You don’t have to figure out lines-of-code-per-day or average-bugs-per-inflection-point. Give your team 1 point for each “yes” answer. The bummer about The Joel Test is that you really shouldn’t use it to make sure that your nuclear power plant software is safe.
I recently read a good article in the IEEE Computer May 2017 magazine that discussed the measurement of software quality (What Happened to Software Metrics? ). A bit of apples and oranges comparing to the two but I was struck that these software frameworks (particularly CMM) might have a had more success if used in programming environments that focused on the simple steps that reduce errors as listed in Joel's list.