A lot of companies get the basic source control, builds, bug tracking and writing code during interviews parts right, but tend to skimp on these aspects of the Joel test:
This one is the most important one for me, and the absolutely hardest to find. I believe we (as programmers) let ourselves get overwheled with extreme programming, daily standups, burndown charts and other mostly meaningless stuff. We forgot the basics; peace and quiet. Everything else is just extra.
I always took this as a criticism of companies where you've got developers who earn multiple thousands per month pecking away at old PC's and squinting at 15" CRT screens. Waiting for 5-10 mins for the OS to startup and > 5 mins to build a project.
Frequently the objectively best tool is Free or open source software (which doesn't mean it's priced at $0, although often it will be). But many times it's not, and that's when companies can become extremely penny wise and pound foolish.
Hiring someone to exclusively babysit a Jenkins instance is incredibly expensive. Paying for Travis CI/Codeship/Gitlab CI is really cheap in comparison. Having developers fill out purchasing orders and waiting for software or hardware is very expensive.
I like to call it the "IntelliJ test", can I requisition IntelliJ ($499) and have it the same day (week? month?) or is the company going to flinch, hem and haw at the absolutely inconsequential price of the software in comparison to the expensive developer time they're paying for.
It's not always cut and dry. I was the "Jenkins babysitter" for a lot of years.
At scale I don't think most off-the-shelf CI/CD tools hold up. You will need dedicated people to take care of them.
Of course, if all you have is 100x plain software projects which don't depend on one another and there's no sort of other interaction between them, by all means, go for SaaS CI/CD.
If there's any kind of orchestration needed... it doesn't hurt to hire a professional to do it than force 40+ developers do it piecemeal between their other tasks, which will often have a higher priority due to management demands.
To rephrase your statement, I think you should get the best tools that are realistically affordable for your process. On top of that you should also get the best supporting cast for your process since often tools on their own don't cut it.
I have only ever been able to use IntelliJ at home (where I buy my own copy) on my own projects. Everywhere else it's Netbeans (meh) or Eclipse (blech).
I remember I was once told to integrate an ancient DSP library into a new development project (despite more modern alternatives being available that would have met the actual requirements just fine). This library looked like it was originally written on VMS (little hints of VAX-ness here and there), later ported to Solaris, and finally ported to Linux. It was a mix of C, C++, and Fortran, and it required the Intel C and Fortran compilers in order to build (no, gcc/gfort wouldn't work) along with some of the icc runtime libraries in order to actually run.
My employer at the time absolutely refused to purchase the Intel Compiler. But expected me to get the job done. I can't remember exactly what I did to make it work, but I do remember it was a giant kludge. That entire project was an underfunded/understaffed/mismanaged nightmare.
I'm a bit here and there on this. Had an old perpetual IntelliJ license and it still worked perfectly. When they switched their model to yearly subscriptions.. why upgrade? I've been using 2016.x and now 2017.x and I still don't notice any difference. Maybe it starts up a little faster? My work laptop runs weeks. It surely doesn't index faster...
But that's not the point, I know :) And I still love it, it's worth the money.
I always took "the best money can buy" to be an idiom for "the best available". I don't think he was advocating for paid tools literally whenever possible.
Joel's criteria are intended to be efficient and diagnostic of common problems. I think his choice here is based on seeing teams use ineffective tools because effective tools are "too expensive". Whereas being made to use expensive tools and being forbidden from using more effective free/cheap tools is more rare.
One thing that Joel's list isn't, it isn't how-to-develop-software, or how to manage software projects, etcetera. There are many books about that. Joel's list is about recognizing ineffective leadership that will waste your time, which is finite, and limit your career and your earning power. And it is a checklist that you should be able to move through during a single on-site interview, not something that requires a four hour conversation and requires you to do an in-depth analysis of their decisions.
Indeed, during the last three years there were 4 article. However, 2 of them were less insightful and more marketing pitches.
Anyway, I still have his blog in my RSS reader, so I won't miss if he writes a new article. Even his more marketing-like articles are quite entertaining, yet accurate, so are worth reading even if its just for observing and learning from his writing style.
- Do you fix bugs before writing new code?
- Do programmers have quiet working conditions?
- Do you use the best tools money can buy?