5 ms·

Ask HN: If you were to create a new Joel Test, what would look like?

• itamarst 9y ago
  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.
• muzani 9y ago
  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.
• tootie 9y ago
  Replace schedule and spec with a groomed and prioritized backlog.
  • YZF 9y ago
    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 9y ago
      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 9y ago
        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...
• YZF 9y ago
  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.
• varikin 9y ago
  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.
  • deleted 9y ago
    [deleted]
  • thehardsphere 9y ago
    I think these are good questions, but I don't think they could replace the questions in the Joel Test because they're very specific to host-your-own-SaaS-product development. The Joel Test questions are applicable to pretty much any kind of software development someone could do.
  • olalonde 9y ago
    > * Can all developers access production? That doesn't seem like a good idea...
  • toomanybeersies 9y ago
    > 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.
    • 9y ago
• exabrial 9y ago
  * 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.
• imron 9y ago
  > 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.
• klenwell 9y ago
  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.
• thehardsphere 9y ago
  What makes it outdated besides the publication date?
• tjalfi 9y ago
  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.
• pg_is_a_butt 9y ago
  uh, there were different branching models then too... it was dumb to talk about them. not having a branching model is way worse than having an odd one. you're all idiots.
• kapauldo 9y ago
  Who is joel?
  • krallja 9y ago
    https://en.m.wikipedia.org/wiki/Joel_Spolsky https://en.m.wikipedia.org/wiki/Joel_Spolsky
• dasmoth 9y ago
  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.
• bjourne 9y ago
  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 9y ago
    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.
• lwhalen 9y ago
  "Do you allow remote work?" Anything other than "Yes!" is an org-smell (at least for me, YMMV).
• lsiebert 9y ago
  "Do you have an open office?" comes to mind. http://www.bbc.com/capital/story/20170105-open-offices-are-damaging-our-memories http://www.bbc.com/capital/story/20170105-open-offices-are-d...
• twobyfour 9y ago
  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.