
Ask HN: If you were to create a new Joel Test, what would look like? - mrburton
In case you haven&#x27;t seen the Joel Test, here it is:<p>https:&#x2F;&#x2F;www.joelonsoftware.com&#x2F;2000&#x2F;08&#x2F;09&#x2F;the-joel-test-12-steps-to-better-code&#x2F;<p>The Joel Test<p>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?<p>It was initially released in 2000 and since then, it&#x27;s become outdated.<p>If you were tasked with creating a new Joel Test, what would it look like? e.g.,<p>1. Which source control do you use?
2. Which branching model do you use for Git?
3. Do you use an issue tracker?
4. Do you do TDD or some form of Unit Testing?
5. Do you do code reviews?
6. Do you have coding standards?
7. Do you do Continuous Integration?
etc.<p>I want to see what the community thinks should be the new test?
======
muzani
What is wrong with it? It still looks applicable. It's easier to do than ever,
the point isn't to add more tech, but to tick off the same questions.

Lots of companies still don't have source control or testers. People still
need to write code in interviews.

What I would add is that progress tracking should be up to date, with tools
like Trello or Pivotal Tracker, rather than asking how much is there left to
do.

And now, more than any time ever in programming history, we really need non-
distracting working conditions.

------
varikin
I don't have a complete answer right now, but I would consider the following
ideas.

* Can you deploy (not build) with a push of a button

* Can you deploy the same artifact to test, stage, prod, etc with no changes?

* Can all developers easily check metrics and logs for production?

* Can all developers access production?

* Are servers pets or cattle?

* Are developers allowed to choose the tools that best suit themselves?

* Who gets paged?

* What happens the day after page?

* How is server config managed?

* Are schema changes to the database automated?

Obviously, these are not all yes/no questions and should be simplified, but it
is what is on the top of my head. Some if it is based on the idea of a 12
factor app and on using immutable images (docker, amis, etc) and some is based
on devops/sre models of working. For example, who gets paged and what happens
the next day is all about process. Fixing and forgetting the issue is not
acceptable.

~~~
toomanybeersies
> Can all developers access production?

I don't think that's necessarily a good idea, for various data disclosure,
security, and safety reasons. In fact, I'd say that a better question would be
if developers are able to diagnose and solve problems without having to access
prod. For example, a company may have an anonymised copy or partial copy of
prod for developers to work with.

~~~
voska
It is when your CI process will prevent any breaking changes.

------
klenwell
I think the original Joel Test still holds up well and I still use it when I
interview with companies. But these questions might get to culture issues that
ultimately affect code quality and developer well-being:

\- Are developers/employees at the office for less than 45 hours a week?

\- Are employees discouraged from answering company email or signing on after
they leave the office?

\- Do developers have admin control of their machines?

\- Do you trust your developers with internet access (i.e. no corporate
website blockers)?

Any NO here is an organization smell to me that signals poor project
management, too few people expected to do too much work, or basic lack of
professionalism.

------
bjourne
I honestly don't think it is outdated at all. For example, its hard to find
"quiet working conditions" in most jobs. In fact, when it comes to peace and
quiet it seem to have gotten worse in the last decade. If you cherish
solitude, you are "obviously not a team player" and "not a good fit for our
company culture." :/

~~~
ajeet_dhaliwal
Agreed, everywhere I've work it's like trying to take a shower/bath with the
door unlocked and people walking in and out. Just horrible.

------
itamarst
Thing I alluded to in answer to the other question you asked: I'm working on a
Joel Test for companies to demonstrate if they have (or don't) a sane
workweek.

For more technical stuff, googling "joel test updated" will find you a bunch.

------
imron
> 2\. Which branching model do you use for Git?

Bad question because it presupposes use of Git, and using source control other
than Git is not necessarily indicative of a problem.

------
tjalfi
My employer’s answers to these questions are why I am actively looking for
work.

1\. Do you use unit tests?

2\. Do you use static analysis tools?

3\. Do you use dependency injection?

4\. Do you use parameterized SQL or an ORM?

5\. What third party libraries are mandatory?

6\. Rank these three goals in order of importance - time to market, quality,
maintenance costs.

------
dasmoth
I'm another who thinks the original has stood the test of time pretty well
(with the "quiet" looking more precious than ever).

But were I updating, I'd be thinking about something like "do you compare your
developers to assembly-line workers?". Management-speak definitely seems to
have been heading in that direction recently, with terms like "backlog"
particularly grinding my gears.

------
exabrial
* Do they ask algorithm pop quizzes in the interviews?

I don't mind doing a simple problem on a white board to show some basic
competency. When I give interviews, I tell the candidates days before we'll be
solving a very simple problem together. Just a basic fizz-buzz. Anything more
complicated than that they deserve a compiler and Google Search.

------
YZF
I would ask what % of features/fixes/improvements comes from the developers.
That should be large (lets say >25%) in a healthy environment IMO.

Other than that the original looks pretty good. Too bad not too many companies
score a 12/12.

------
thehardsphere
What makes it outdated besides the publication date?

------
lsiebert
"Do you have an open office?" comes to mind.
[http://www.bbc.com/capital/story/20170105-open-offices-
are-d...](http://www.bbc.com/capital/story/20170105-open-offices-are-damaging-
our-memories)

------
tootie
Replace schedule and spec with a groomed and prioritized backlog.

~~~
YZF
The point of the question is that you should have a spec and a schedule. A
groomed prioritized backlog isn't a replacement as it often doesn't have a
real spec and doesn't imply a schedule.

What will your product look like? (in enough relevant detail) When does it get
delivered? These are two critical questions. These things are always subject
to change but a business should know what it's aiming for.

~~~
tootie
The point of agile is that your spec and schedule are nonsense. So-called BDUF
has failed time and again and the reasonable approach is to not bother
planning more than a few weeks at a time and be able to change priorities
quickly.

~~~
YZF
This isn't about big design up front vs. "Agile". In my personal opinion if
anything is a failure it's Agile which has turned into an excuse for pushing
people around, poor management, poor software development. You have to keep
your eye on the ball, know where it's going _and_ be flexible. You can't just
be flexible. You can't build anything of consequence by only planning a few
weeks ahead out of context of some larger plan. If you have no idea where
you're going you're going to mess it up a few weeks at a time.

JMHO and I've done everything under the sun from various flavours of Scrum,
XP, to more traditional project management techniques. This question will help
you find out if you're going into a chaotic and stressful environment or if
things are under some sort of adult supervision...

------
lwhalen
"Do you allow remote work?" Anything other than "Yes!" is an org-smell (at
least for me, YMMV).

------
twobyfour
I think the original test still hits most of the important points. But yes,
there's room to adjust some of them for modern tooling; the web ecosystem; and
the current agile mindset.

1) Replace "source control" with "distributed source control". Or something
about source control where branching and merging is cheap.

2 and 3) Replace "build" with "deploy" for web apps

4) No change

5) I've always been iffy on this one. What sort of bugs? All bugs? What
software is ever bug-free? No new code until you've handled every single edge
case and typo? Not very agile. I think this is another that differs between
web apps and "shrink-wrapped" (even if digitally shrink-wrapped) apps; and
with digital distribution significantly shortening the
build/distribute/feedback cycle, it's less crucial than it used to be even for
the shrink-wrapped apps.

6) I might replace this with something more agile involving
sprints/milestones/target dates; or about adjusting scope to meet schedule

7) The term "spec" tends to get feathers ruffled, especially in agile circles.
I've seen software built very successfully from nothing but a UI design and a
short bulleted list of legal compliance requirements. I think there's room for
something here about knowing what you're building and the whole team (from
design/product to engineering to QA) being on the same page about what that
is.

8) This. 10000x this. This is the item that 95% of software companies these
days fail hard.

9) I've seen people complain that this doesn't take into account the
prevalence of open-source tooling, but I think the point here is that you
should be willing to invest a LOT of money in making your developers' lives
easier and software quality better. Don't skimp on workstation hardware, or
AWS instances, or licenses for whatever tools will improve velocity/software
quality/quality of life. Perhaps it could be reworded somewhat.

10) These days I would split this one into whether developers write automated
tests that are run in CI and whether you have someone other than the
developers do click-through testing, both of which are important (unless
you're writing nothing but SDKs)

11) I would say during either an interview or a take-home exercise, but yeah.
Write code as part of the interview process.

12) Kind of meh on this one. For most web apps you can do A/B testing, partial
rollouts, and feature flags to get much higher quality and nearly as quick
feedback than you would with "hallway" usability testing. For shrink-wrapped
apps, I think it depends on how representative people in your hallway are of
your target user. Yes, you need usability testing, but the "hallway" part is
debatable.

------
kapauldo
Who is joel?

~~~
krallja
[https://en.m.wikipedia.org/wiki/Joel_Spolsky](https://en.m.wikipedia.org/wiki/Joel_Spolsky)

