Slashdot Mirror

← Back to Stories (view on slashdot.org)

Joel Test Updated

Posted by timothy on from the inspect-the-width-of-the-coal-chute dept.

An anonymous reader writes "In 2000, Joel Spolsky wrote the Joel Test, an excellent and simple way to evaluate a software company. While the test is still used, it's getting outdated, as many companies are moving to web technologies, and new development tools exist. In his blog, Marc Garcia wrote about what could be an update to Joel Test."

3 of 182 comments (clear)

  1. Old system is fine. by Anonymous Coward · · Score: 5, Interesting

    I think the original Joel questions still work fine.
    Who needs a distributed source control system if everyone on my team works in the same office.
    Also, I don't want end customers submitting directly into my bug tracker. I'm OK with them having a web based way to submit problems, but then QA should verify the defect and translate customer speak into something that makes sense. Then the defect can be entered into bug tracker with a good set of steps to reproduce and given a proper severity. To a customer, everything is critical.

  2. A serious question by Scareduck · · Score: 5, Interesting
    Has Joel Spolsky done anything that's worth a damn? I am a long-time user of Fogbugz, and can attest to that product's general lack of attention to detail in its design. It's almost as if it were written by people who hated each other and didn't want to communicate. Several of my co-workers attended a release conference with him present, and the uniform reaction I got back from them was that he had moved on from Fogbugz, wasn't interested in the problems we had found in its implementation, and was fascinated by some other product.

    But getting back to this, Garcia's list appears to be fairly sound. I have some comments on two of his modified questions:

    Do you use a distributed source control system? Why should I care about distributed source code control in a monolithic commercial development environment? I can see its value in a distributed open-source project, but I really don't understand the necessity otherwise.

    Do you fix bugs before implementing new features? All bugs? Some bugs? This tells me nothing about prioritization. Sometimes you need to do both at once. Sometimes it's not worth it to fix a bug if the circumstance is rare enough.

    --

    Dog is my co-pilot.

  3. Simple test for when a company is too big. by EWAdams · · Score: 5, Insightful

    Put a $10 bill, or the local equivalent, in an envelope on the company bulletin board. On the outside, write, "I need change for $10 please" without any indication of who you are. Do this every six months or so. If you ever come back and find that the envelope is empty, your company is too big. You have hired a thief who does not care about his or her fellow employees.

    --
    I piss off bigots.