
The Joel Test for 2017 - signa11
https://myers.io/2017/04/04/the-joel-test-for-2017/
======
allwein
>Do you use source control?

>Do new candidates write code during their interview?

The author suggests removing these two rules because they're ubiquitous, that
everyone does them.

I hate to inform the author, but he's sadly mistaken. There are plenty of
companies still out there that aren't doing these things, especially with
interviews. Also, I think the ubiquity of them is a reason to _include_ them,
because it helps draw attention to those companies that _are_ deficient in
some way.

~~~
kmonsen
Yes! If you interview for a company and they don't use source control that is
a giant red flag.

~~~
edroche
I generally think the same these days, but it made me recall 10-15 years ago
when I was consulting and considered a company having no source control a
place where I could provide immediate value. Now it just scares me right out
the door.

~~~
kmonsen
The value is also depending on them understanding why it is useful. And if
they do, would they not use it already?

~~~
robotresearcher
They are in a mess, they hire you as a consultant, you explain VCS, they get
it, everybody wins.

They didn't have to understand in advance. They just had to be smart enough to
know they needed help.

------
tptacek
Replacing one-step builds with CI isn't a good change. As someone who's having
the pleasure of getting test environments up and working stably for several
different large startups let me just say: having a one-step process for doing
this helps _immensely_. Forget CI: if you can't get your project up and
running, you can't confidently make any changes in it to begin with. I think
that Spolsky rule is more relevant now than it was when he wrote it.

Further: I don't think Spolsky missed CI so much as that he predicted it. So,
maybe, if you wanted to 2017-ize the Joel Test, you could say you should have
_hourly_ instead of _daily_ builds, or something like that.

Spolsky was, I think, pretty far off the mark about hiring. I'm fine with
keeping a bullet in the list about carefully-designed hiring processes,
though; striking that, because "everyone does this right", would be lunacy.
Virtually nobody hires right.

The Hallway Usability Testing thing always seemed to strike me as Spolsky
promoting an idea he'd been talking about with CityDesk, putting it on par
with "having a bug tracker" and "using source control". Losing the rule
altogether would be fine with me. Suggesting that every team have dedicated
UI/UX people is silly: many good teams don't, and even the teams that I work
with that do don't engage those people on every (or even most) UI/UX changes.

~~~
mahyarm
Hallway usability testing I interpret as dogfooding if possible. Some
companies have the entire company dogfood the entire app every day, and it
creates a lot of 'hallway usability testing' on its own.

------
bdrool
He proposes removing the rule about "quiet working conditions" and even says
"There is no right or wrong answer for which is correct." On the contrary,
there is a lot of scientific evidence that quiet enhances concentration and
productivity.

~~~
jrs95
It's more than just quiet. Having a totally open work space creates a lot of
visual distractions as well. People walking around you all the time is far
more distracting than the noise in my experience.

~~~
wst_
I believe you are speaking for yourself, now. On the contrary, I find open
space much better. I like to see people around me. Talk to them. Exchange
ideas. And if I want to keep to myself, I just put on the headphones. That
also contradicts the "silence" argument. I'd gone mad in a silent environment.
I need a music. It's all really individual and one definite​ answer does not
exist.

------
cestith
Let me start with an assumption that is often accepted to be true about
developers. Many of us are thought to have ADHD or be on the autistic
spectrum.

People with high functioning autism, especially those that fit what has been
known as the Asperger's subset, are very prone to oversensitivity to external
stimulation. In people with this oversensitivity, sounds seem louder, lights
seem brighter, and everything is more distracting and more nerve-wracking than
for the average person.

I think ADHD and distraction is mostly self-explanatory. In addition, it can
take even longer after a distraction to get back into the deep concentration
needed for complex tasks. However, these folks often if not distracted can
stay in that deep concentration zone a very long time.

So when research shows (and it does) that a quiet workplace is more conducive
to work that needs long periods of concentration and we're as a community
pretty certain that we have a large portion of our group who are more easily
distracted and has higher costs for being distracted, how is there any
argument against giving a low-distraction workspace?

~~~
jrs95
square footage in trendy downtown office spaces is expensive ;)

~~~
cestith
That's certainly a factor __in contention __with a less open workspace. It 's
not actually an argument against it, but something that should be balanced
against it as best is possible.

------
default-kramer
> However, a company that doesn’t get at least 10 is effectively guaranteed to
> be a terrible place to work.

Seems a bit harsh. None of the companies I've worked for has scored 11 or 12,
but the only thing that stands out in my mind as "terrible" was at one company
where we had to integrate with SAP. And that company could have easily scored
a 12 and still been terrible simply because that SAP interface was remarkably
bad. In fact, the only ones that I would consider dealbreakers (source control
and quiet working conditions) are no longer on the list.

~~~
theandrewbailey
I agree. Just because a place scores 12/12 doesn't stop the managers from
making the job a living hell in other ways. On the flip side: my current job
doesn't even score a 10, but it's far from 'terrible', and no one would dare
leave because of deficiencies from these questions.

------
gumby
> Yes! If you interview for a company and they don't use source control that
> is a giant red flag. reply

Hallelujah!

At Cygnus in 1991 an employee named Rich Pixley tried to convince us to adopt
source control (CVS was the state of the art at the time). John Gilmore and I
were staunchly opposed, and I think Michael Tiemann was neutral. I don't
remember what the employees thought. In any case John and I finally acquiesced
in ill humor and only under the conditions of a number of absurd and
nonsensical requirements (e.g. "must integrated transparently with emacs").
IIRC Rich simply ignored our bullshit and set things up and John and I
realized we had been idiots.

Eventually we had to write the client/server CVS implementation because of a
source control horror story. And I think as a result the FSF ended up adopting
source control too.

I don't think I would work with anyone who doesn't use it any more, at least
for software. On the CAD side (Cadence, Solidworks etc) the situation is still
dire.

~~~
Gracana
Ohh, someone who knows my pain! I deal with SolidWorks EPDM on a daily basis,
and I am continually amazed by how terrible it is. I long for proper source
control with branching and merging and sensible handling of local files and
all the lovely things that have been figured out in the software world.

~~~
gumby
Not to mention SolidWorks keeps the absolute pathname of objects in its
proprietary files (EPDM patches them up at check-out time) so it's
unreasonable to try to keep them in a conventional source control system.
Grrr.

------
Velox
I'm the original author for this post, and there are a few things I've
realised since writing it (despite the fact that it was only 2 days ago).

The first is as allwein says below: Just because I made an assumption that
source control is ubiquitous, it doesn't mean that it actually is, and it
probably shouldn't be removed from the list.

The second is with regards to quiet working conditions. I've seen here, and on
Reddit, that most people seem to vehemently disagree with me. I didn't imagine
that there would be this level of disagreement. The popular opinion is that
everyone should have quiet working conditions. My statement was that working
conditions are tied to open office vs closed office, and it was a personal
preference. So, my question to HN is: Am I wrong in thinking that this is a
personal preference and that it benefits everyone to have private offices?

~~~
delphinius81
I think it should be revised to, "Do the office conditions satisfy YOUR
needs?"

Some people like having lots of noise/people around them (all the noise blends
together at some point) or they just put headphones on anyway so they don't
care. Others want their own office, or could do a shared office. It's such a
personal choice these days.

------
Newtopian
> Can you make a build in one step?
    
    
      vs
    

> Are all builds handled automatically by a Continuous Integration server?

Are two very different indicators. And both are, least in my mind, equally
important. One measure the holistic approach to source code including
everything necessary to produce a functional system. Checkout, build, use.

The other is a measure of how much care is given to the overall process of
software engineering. How much automation the tests receive, how much
attention is given to deployment etc.

Software construction must be tied intimately with the software code itself
for thousands of good reasons. Too many times have I seen a team jump onto the
CI bandwagon; abandoning all notions of build scripts to let this new shiny
thing perform it's magical incantations to build and package the system. A
checkout alone is no longer sufficient to gain a fully functional system one
can test locally, the CI becomes in an integral part of the software code but
without the process the rest of the code receives (reviews, versioning, source
control etc).

With the multiplication of commercial tools flaunting how easy it is to
automate all this that one does not even need a programmer anymore, I fear
software construction will become harder and harder to do without the help of
these external systems.

So yes, do team have a single operation to build (that is construct) a
workable system is still very much relevant.

And yes, do team use continuous integration to automate their test and
delivery process is also important.

------
thatfrenchguy
> know many people who like the idea of open offices. They promote more
> effective and direct communication between members of a team, often leading
> to faster and better solutions to problems

There is no world in which this is true, it's just interiorised worse
conditions of working at this point.

------
kmonsen
I don't understand the reasoning for throwing out the noisy work environment
question. It can be optional for sure, but so is every other question. Use
your judgement, but keep it in the list for most people.

------
PaulHoule
The "best tools money can buy" is too objective.

What you're really trying to get at is that you'll get a decent computer, not
a hand-me-down laptop from a salesman who couldn't sell anything.

~~~
larrik
Joel was a Microsoft guy, so I'm pretty sure he was looking for Visual Studio
and MSDN licenses, as well as the latest Windows instead of 95/95 (or 3.1!).

~~~
slededit
These days it isn't as big a deal, but back then until about 2010 the more
expensive machine really made a huge difference. In a time where most people
were still running pentium 4s, we had quad core machines to develop on.
Compiling was 4x faster than the average computer sold.

These days a 3 year old computer really doesn't make that much difference.

~~~
chadgeidel
And yet I just left a job with a 4 year old "desktop class" computer with a
"spinning rust" HDD and 8GB of RAM. Something that 4 years ago would have been
deployed in a call center. Did I mention I didn't have local admin as a .NET
web developer? This was a company that prided itself on its "progressiveness".

~~~
PaulHoule
Programmers don't leave companies, they leave computers!

~~~
chadgeidel
You jest, but IMHO the state of a developer workstation (computer, desk,
chair, room) speaks volumes about the organization.

------
wishinghand
I'd love to see one tailored a little more to web development.

Also I never understood asking this question:

> Do new candidates write code during their interview?

If you're there for an interview, you're about to find out first hand.

~~~
akhilcacharya
I mean, it's possible that this question could be asked during an HR or
nontechnical screen.

~~~
wishinghand
I didn't think of that, but whenever I asked Joel test questions of HR, they
usually couldn't answer them other than if they use source control and if they
have testers on staff.

------
wink
I wonder if the Joel test is still the gold standard for most people.

Especially "Do new candidates write code during their interview?" seems to run
contrary to the much decried whiteboarding (not taking sides right now, also
it's not about paper vs whiteboard etc)

I still think the questions are a useful data point, just never agreed with
the "10 and less is a failure", because it's just too broad and some of the
points the teams I worked fulfilled 100% in spirit, but never to the letter of
the test - but then you're in wishy washy gray area again. (One of my main
gripes is that if you compare Excel (iirc that was his team) probably has "a
single build" with dozens? of developers - so I'd rephrase it as "all your
projects have a releasable HEAD/master branch" but I had people disagree on
that premise.

~~~
mamon
"write code during interview" was always about real coding, using computer. No
paper, no whiteboard, the best way to do it is to give the candidate access to
some real code, like a company's internal project, and real task, like a nasty
bug to solve, or a small new feature to implement.

~~~
delphinius81
I had an on-site coding interview at a place where they asked me to implement
a small iOS project on my own computer doing things however I normally would.
Had access to documentation, SO, could search google for whatever. They gave
me a couple hours to do as much as I could - there was another dev around that
could answer questions I had. Afterwards, I walked them through what I had
done, answered their questions, responded to feedback, etc. This was code
interviewing done right in my mind.

Whiteboards are for design, computers are for code.

~~~
wink
Good point, I had totally forgotten we had that at a past company. Give the
candidate a computer, a simple task, someone to ask and check results after
2h.

------
JCzynski
Another recent update, with a lot of common features:
[https://austinstartups.com/an-updated-joel-test-
for-2017-315...](https://austinstartups.com/an-updated-joel-test-
for-2017-31560b109bcb)

His list (with its diff):

    
    
        -1. Do you use source control?
        +1. Is your source control effective for the disconnected programmer?
         2. Can you make a build in one step?
        -3. Do you make daily builds?
        +3. Do you build, test, and deploy (somewhere) on every commit?
         4. Do you have a bug database?
         5. Do you fix bugs before writing new code?
        -6. Do you have an up-to-date schedule?
        +6. Does your source have a stable trunk from which releases can be cut at any time?
        -7. Do you have a spec?
        +7. Can all of a product's features be verified in one step?
        -8. Do programmers have quiet working conditions?
        +8. Do programmers have access to a door that can be closed for uninterrupted work?
        -9. Do you use the best tools money can buy?
        +9. Do programmers have the freedom to choose the best tools for the job?
        -10. Do you have testers?
        +10. Is testing the team's responsibility?
         11. Do new candidates write code during their interview?
         12. Do you do hallway usability testing?

------
GlennS
I think this list is a bit too focused on big, dedicated software companies.

If you're spending a month or two making a throwaway bit on analysis, for
example, maybe it doesn't need hallway usability testing and plugging into a
CI system (although I'd argue for a makefile, which maybe does the same job).

Similarly, if you're not collaborating on a thing, maybe you don't need a
schedule. You can do the job with an ordered list of tasks and a future date
when you'll revisit that list to see if you need to ditch some things to stay
within the budget.

And if your company only has a couple of developers to support the business,
then you're probably not going to hire dedicated testers or UX specialists
(how much longer before that gets replaced with some other buzzword anyway?).

And actually, all these things can be changed. If you go to a company that
doesn't do something that you think is important, then make your case. If
you're in a position where your case won't be listened to, that's a much worse
indicator.

I wouldn't work without version control though. If I have to be responsible
for some text then it's going in Git, be it code, configuration or notes.

On a different tack, I think the idea that a spec isn't useful any more
because of agile is definitely a wrong one.

Your spec doesn't have to be absolutely rigorous, set in stone, or meet some
standard. Writing down in detail what you intend to do and how it will meet
your aims is really useful for non-trivial tasks.

------
JCzynski
I agree that the quiet working environment is still important, and the
research that suggested the open office was better has largely been
superseded. (Google, who started the trend, has moved away from it.) But this
generally provides a much-needed update, and I'm going to put this on my "ask
in the phone screen" list.

------
vikascoder
Nah.

