- Do you fix bugs before writing new code?
- Do programmers have quiet working conditions?
- Do you use the best tools money can buy?
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.
> 9. Do you use the best tools money can buy?
I hope I don't do too much injustice on Joel, as I always loved to read his writings back when his "Joel on Software" blog was active.
However, this item on the list always sounded to me as an attempt to promote their FogBugz tool, not as an objective advice.
Recognizing there are many excellent Free Software tools, specially in the software development area, I'd rephrase it is as:
> 9a. Do you use the best tools available?
or maybe:
> 9b. Do you invest in your tools?
which means, depending on the exact tool, one or more of:
- buying a proprietary tool
- using a Free Software tool, and donating money to the project
- using a Free Software tool, and providing bug fixes and/or new features
- having one or more team members dedicated to improve the tooling and infrastructure
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.
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 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.
But that's not the point, I know :) And I still love it, it's worth the money.
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.
I'm thinking desktops/laptops with lots of RAM and SSD, fast internet, a proper chair, standing desks, a 4k monitor, ...
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.
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.