Forgot your password?
typodupeerror
Businesses Software

Joel Test Updated 182

Posted by timothy
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."
This discussion has been archived. No new comments can be posted.

Joel Test Updated

Comments Filter:
  • He failed the grammar test:

    I think every software company should took the test, and every programmer looking for a job, should make the test to any company he could be interested.

    Do your team work in good conditions...

  • Old system is fine. (Score:5, Interesting)

    by Anonymous Coward on Sunday December 26, 2010 @12:39PM (#34670402)
    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.
    • by Creepy (93888) on Sunday December 26, 2010 @01:12PM (#34670530) Journal

      Who needs a distributed source control system if everyone on my team works in the same office?

      Says the person who's job is about to be exported to India.

      It seems like a fairly logical list, but I've noticed that the list is geared more toward waterfall, and not for, say, Agile - for instance "Do you have a spec?" doesn't really apply because the requirements become the spec. Also Agile often has non-dedicated roles - for instance, I work in Product Validation and in waterfall I do nothing but write test plans and run tests, but in Agile I manage the Lab Manager VMs, write schema, and run unit tests, none of which I would do in my traditional role (it doesn't hurt that I am a programmer originally hired into automation, but that got outsourced, and I've filled a variety of roles since then like US government security testing, which the US doesn't allow to be outsourced).

      • AFIK the "distributed source control system" is not about networking or Internet, but about giving each developer a whole copy of the central repository so they can "pre-commit" their code and this generates some benefits Spolsky talks about when referring to Mercurial.

        BTW, Subversion will not prevent anybody's work being exported to India.

      • by Grishnakh (216268)

        Who needs a distributed source control system if everyone on my team works in the same office?

        Says the person who's job is about to be exported to India.

        Yes, that's a good reason NOT to use a distributed source control system. Anything that makes it harder to outsource work is a good thing.

      • Who needs a distributed source control system if everyone on my team works in the same office?

        Says the person who's job is about to be exported to India.

        1. Maybe your is going to be exported to India. After all, what do you know about the OP's job to make that assertion? Or are you one of those who think offshoring is both a) inevitable and b) a tragedy?

        2. What does distributed source control has to do with remote teams? People have done offshoring with CVS successfully for cry out loud. The distributed part in the "distributed version control" name is not what you think it is. It is not about physical distribution/networking per see.

        It seems like a fairly logical list, but I've noticed that the list is geared more toward waterfall, and not for, say, Agile

        Que?

        for instance "Do you have a spec?" doesn't really apply because the requirements become the spec.

        In other words yo

    • by Bigjeff5 (1143585) on Sunday December 26, 2010 @01:20PM (#34670556)

      His "updates" just sound like re-statements of the original questions for a particular situation (i.e. less applicable to all modern software companies than the original).

      Joel Spolsky assumed you would be intelligent enough to adapt the list to your specific situation.

      For example, what good is "source control" if it doesn't effectively control the source code? There is no need to specifically mention distributed source control; if your source control is doing its job then you have good source control. If it isn't doing its job because you've got developers all over the country, then you need a distributed source control. It's built in to the question.

      Customers directly reporting to a bug database, as others have mentioned, can be disasterous. However, Joel's flagship software is bug tracking software, and from what I've heard it's very, very good. His bug tracking uses a combination of silent reports from the software, direct customer input, and support service input. Specifically stating bug tracking must be entered directly by the customer is stupid and inflexible, and does not apply to all situations. The point of the software test is to apply to all situations.

      It goes on, most of them are similar, but this one is egregious:

      Do you have automated build or deployment procedures?

      What the hell does he think "Can you make a build in one step?" means?! That's automated build and/or deployment!

      Also:

      Do you fix bugs before implementing new features?

      Uh... frankly, that sounds worse than "Do you fix bugs before writing new code?"

      Do you have a roadmap, and you don't make important changes to the short term priorities?

      A) That's not the programmers job nor responsibility, and B) "Do you have an up-to-date schedule?" Hello?

      Seriously, what does this guy think all these words mean? Just because they were written 10 years ago doesn't mean the meanings of the words changed. Apply them to your situation, they fit just fine.

      Last but not least:

      Do your team work in good conditions (quiet environment, flexible schedule, freedom to choose development software, fair paycheck...)

      That's a dream of every office worker in America, and if you refuse to work at companies that don't have an office culture like that, well, you won't be working much unless you are seriously hot shit.

      • by gadzook33 (740455)
        I completely agree. It almost seems ironic, a developer missing the generalization, abstraction, and elegance. This is like someone modifying "All the world's a stage, And all the men and women merely players" to explicitly include YouTube.
      • by Grishnakh (216268)

        Do your team work in good conditions (quiet environment, flexible schedule, freedom to choose development software, fair paycheck...)

        That's a dream of every office worker in America, and if you refuse to work at companies that don't have an office culture like that, well, you won't be working much unless you are seriously hot shit.

        Is it really that bad? I mean, the last three are debatable, but the first one seems to be pretty necessary to me. Hell, I quit my last job mainly because of the lack of a quiet

    • by vlm (69642)

      Also, I don't want end customers submitting directly into my bug tracker.

      You mean, you don't want then submitting directly into your queue. OK who cares. Why force Q/A to manually retype or cut-n-paste each customer request before dropping the ticket in your queue? Its not as if cut-n-paste magically improves upon pasting. Trust me, Q/A doesn't necessarily make any more sense than customer speak, but being distant from a bug does mean small details will be lost, some of which may be important.

      I would never, ever let a customer set the actual ticket severity. They are free t

    • and translate customer speak into something that makes sense

      Spoken as a true programmer--well done, sir!

    • by GWBasic (900357)
      I really like Mercurial, and I'm starting to switch to git because github has a really nice way to merge in changes. That being said, I'm still not 100% sure that distributed source code control is the *perfect* solution. I really like Perforce and Microsoft's Team Foundation Server; and I'm not going to be snobbish or require that all team members host local copies of all of the history if there's a more appropriate tool for the team's dynamic.
    • by shish (588640)

      Who needs a distributed source control system if everyone on my team works in the same office.

      Your code is still distributed among multiple people; and even for a single person, you could have several unrelated features being worked on in parallel.

      Plus, even if you personally prefer the centralised approach, DVCSes tend to be better at that too (eg - looking at a commit log with SVN was always a chore as you need to wait for the server. Git not only lets you look at it easily, but make use of it, for instance being able to automatically do a binary search across a range of commits to see which patc

    • Who needs a distributed source control system if everyone on my team works in the same office.

      You need distributed source control even if it's just you because:

      1) You can work more easily between several different systems.

      2) You get more advanced branching and alternate release features.

      3) Lower weight cost to frequent checkins (not every checkin has to go to the server).

      4) When you DO end up needing to work with a second person, distributed version control systems are much better at getting a second perso

  • by rsilvergun (571051) on Sunday December 26, 2010 @12:42PM (#34670408)
    Joel Test [wikipedia.org] for my scientific endeavors.
  • by Mr Thinly Sliced (73041) on Sunday December 26, 2010 @12:45PM (#34670422) Homepage Journal
    As far as I can tell the changes made by Marc Garcia seem to reflect what someone working with open source tools would expect from a workplace. Don't get me wrong, there's the right place for the right tool - but in a lot of corps where you might work, there isn't the:

    • freedom to choose development software
    • distributed source control system

    *Shrug* - just comes off as a wish list of how this developer thinks software companies should work. IMHO part of the attraction of the original Joel list was that it was more or less applicable regardless of product audience / build tools etc. The core principles *really were important*.

  • A serious question (Score:5, Interesting)

    by Scareduck (177470) on Sunday December 26, 2010 @12:46PM (#34670426) Homepage Journal
    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.

    • Re: (Score:3, Interesting)

      by chengiz (998879)

      The "bugs" one made me think this was written by someone who had no idea how a sustainable development model works. Then I read Marc Garcia is a student. How does this shit pass thru Slashdot's editors?

      • by rsborg (111459)

        Commenting to undo moderation (the new mod system should allow you to undo and lose the point).

        This list is pretty awful. Most of it is specific and Joel's original list is quite indicative in and of itself.

    • Re: (Score:2, Informative)

      by Anonymous Coward

      Why should I care about distributed source code control in a monolithic commercial development environment?

      Aaahhh.. haven't you learned by now that being able to divide concepts recursively is generally a Good Thing (tm)?
      Even a monolithic company consists of different workgroups, and the developers in those groups may want to work remotely on some stuff, e.g., when they are on a trip. If it would cost them too much pain to merge in their changes when they're back home, do you think these developers would be thrilled to do said work when they're away?

    • by rudy_wayne (414635) on Sunday December 26, 2010 @04:52PM (#34671670)

      Has Joel Spolsky done anything that's worth a damn?

      Not really, but he seems to be an expert bullshitter who throws around the fact that he once worked at Microsoft every chance he gets. As for what he's done, let's see:

      City Desk - some sort of program for creating and managing websites. Little or no mention of it on his website anymore and the City Desk forum is long gone from the website.

      Fogbugz - The Forgbugz forum is also gone from his website. Here's a blurb from Joel this past September: "Thanks to the hard work of the Fog Creek team, including ten great summer interns, we have just released amazing new upgrades to FogBugz " Thank god for free labor.

      Co-Pilot - a remote access program that was written entirely by summer interns. Really. Thank god for free labor.

      Stack Overflow - Not an actual application but simply a website where people can ask questions.. This doesn't stop Joel from proclaiming "I’m the CEO of Stack Overflow".

      From what I can see on his website, his main business now is ads for programmer jobs.

    • by Doctor O (549663)

      Could you elaborate on the problems with FogBugz (or "the FuckBox" as my new coworkers call it)? My new employer has a FogBugz installation that is half-assedly used for product development, but we want to manage support via FB too (using the mail feature) and merge in existing tickets from our Bugzilla (which doesn't handle "standard" tickets at all) so that we end up using FugBogz only for everything. We're only 30 people living off a specialized software, so load won't be an issue. I'm intrigued by the t

  • Total failure (Score:4, Insightful)

    by gnasher719 (869701) on Sunday December 26, 2010 @12:47PM (#34670436)
    This is of course not "Joel" updating his list of requirements for good development, but some joker trying to take advantage of Joel's reputation.

    Example: Allow users direct access to a bug database? It's hard enough to train testers to give you good bug reports. You won't get anything usable from an end user without some severe filtering.
    • Re:Total failure (Score:5, Insightful)

      by Frosty Piss (770223) * on Sunday December 26, 2010 @12:57PM (#34670472)

      You won't get anything usable from an end user without some severe filtering.

      Indeed. This attitude is one of the biggest failures in Open Source software development, and why companies like Microsoft flourish. Microsoft software has many issues, but listening to the End User is not one of MS's problems. On the other hand, pipe up to just about any Open Source project about End User issues, and "STFU and submit a patch" is about the nicest thing you'll hear. Even as responsive as Apache and Mozilla are, End Users still feel this wrath. It a fact, most companies that want their products to flourish and make money are responsive to the people that actually use them. The GIMP Team? Not so much.

      • > but listening to the End User is not one of MS's problems

        After reading countless posts regarding inaction and apathy on long-term known bugs in the Visual Studio suite, I too can confirm that listening to the end user is definitely not something that MS consider their problem.

        > On the other hand, pipe up to just about any Open Source project about End User issues, and "STFU and submit a patch" is about the nicest thing you'll hear

        What complete nonsense. There are plenty of projects out there that ar

      • by dbIII (701233)
        Complaints to GIMP? Let's make up one for 1995:
        Q: Why are you not like photoshop?
        A: It's a different program with different aims. Besides, photoshop doesn't even have UNDO so is aimed at professionals that save a lot or never make mistakes.
        Fast forward to now, many complaints are about it not being photoshop or missing features needed for specialised industrial printing on very expensive bits of gear. After fifteen years if it was me I would say "just go out and buy photoshop and leave us alone", but the
    • Re:Total failure (Score:5, Interesting)

      by Kjella (173770) on Sunday December 26, 2010 @01:42PM (#34670658) Homepage

      Example: Allow users direct access to a bug database? It's hard enough to train testers to give you good bug reports. You won't get anything usable from an end user without some severe filtering.

      The question is whether you are better off leaving your users to work out their bug corresponence via mailing lists or email and only let a blessed few enter bug reports, or is it better to have the full case history going all the way back to what the customer actually reported along with any logs or screenshots. Or if you just drop it only the floor saying "LALALALA our software is perfect, all problems are PEBCAK problems."

      Personally I'm a big fan of wine appdb's "*** This bug has been confirmed by popular vote. ***". If enough people are experiencing a problem, you have a problem whether you get anything useful from the logs or not. Don't forget that crappy bug reports and crappy logging often go hand in hand, when the application just goes boom without giving any useful information about why the developer is just as much at fault for making it impossible to debug.

    • by vlm (69642)

      his list of requirements for good development

      You won't get anything usable from an end user without some severe filtering.

      The two quotes are more closely related than you'd think, in that both are limited to extremely narrow experiences and assume the rest of the world MUST be the same as the past limited experiences.

      If all I have is a hammer, suspiciously, everything, including bolts and screws, looks like a nail.

  • Do you use a bug database where users can report bugs directly?

    No. No. No. You'll end up with a database full of laundry list bugs and PEBAC resolutions.

    Do your team work in good conditions (quiet environment, flexible schedule, freedom to choose development software, fair paycheck...)

    Brilliant, ask about working hours and how much money you'll be paid. You won't come across as lazy and greedy, honest.

    • No. No. No. You'll end up with a database full of laundry list bugs...

      God forbid you would want that! A list of issues that the people that ACTUALLY USE YOUR PRODUCT have with it? Heavens no...

      • by alvinrod (889928) on Sunday December 26, 2010 @01:17PM (#34670550)
        There's a difference between getting customer feedback, which is good, and allowing that feedback to go directly into the bug database, an exercise in insanity. How many of those bug reports are going to be accurate and descriptive enough so that whomever gets stuck reading it will actually be able to identify what needs to be fixed, especially if there's not a crash report, or other error messaged included?

        Unless your users are professional developers/programmers, the signal to noise ratio is going to be horrid.
        • I have seen this all the time with open source software with public bug databases:
          * User files bug with vague description and no steps to reproduce.
          * Project manager lumps a bunch of vague bugs together as "duplicates".
          * Programmer fixes bugs that sound similar to the vague descriptions and marks as fixed.
          Then all holy hell breaks loose on the forums as people bitch about you closing their bugs when the problem still exists, and post on slashdot about "bugs" that have been open for 5 years but no one will f

      • by Bigjeff5 (1143585)

        You've never waded through a laundry list of bugs before, have you?

    • by mjwalshe (1680392)
      >Brilliant, ask about working hours and how much money you'll be paid. You won't come across as lazy and greedy, honest.

      err that's normally one of the the things the job spec has up front and if it didn't that would be a warning in its self that the company is a poor employer.
  • by glwtta (532858) on Sunday December 26, 2010 @01:09PM (#34670518) Homepage
    So, why exactly does everyone need a distributed source control system? Just because anything distributed is automatically cooler?

    Also, yeah, having the users report bugs directly in the bug database is just stupid.
    • by Bigjeff5 (1143585)

      Because Garcia said so!

      Seriously, most of his "updates" are just re-statements of the old questions in a less flexible manner, so that they apply to fewer software companies or coding environments. The old questions already include his if you assume such things as bug databases and source control need to be effective in order to meet the requirement. A bug database that doesn't contain the information you need to fix bugs is useless, and would count against the company. Source control that doesn't effect

    • by shish (588640)

      Just because anything distributed is automatically cooler?

      It's not a causal link, but the correlation is pretty much 1:1 -- when I first moved from svn to git, what blew me away was that the command line tools were simply better in basically every way ("git subcommand --help" gives you a scrollable searchable man page rather than wall of text on stdout; coloured output makes it much easier to read; having a local copy of the history makes everything a million times faster, etc) -- it was a few months in before I did anything actually distributed with it...

      Plus, t

  • Do you use source control?

    - useless if your source control doesn't know about unified diffs and if developers don't know how to make 1 commit - 1 changeset
    - also if it's dog slow, throw that piece of crap in the trash

    AND I MEAN IT

    Can you make a build in one step?

    - very important, but overrated for things that don't 'build'
    - make this a 'deploy package' in one step

    Do you make daily builds?
    Do you have a bug database?

    - important. Corolary: all bug databases suck, some less, some more, use bugzilla and you'll b

    • by Jay L (74152) *

      My take on it

      Dammit, now we have to fix the headline:

      s/Joel Test Updated/Joel Test Updated Again (see comments)/

    • Re:My take on it: (Score:4, Interesting)

      by Bigjeff5 (1143585) on Sunday December 26, 2010 @02:09PM (#34670800)

      I imagine Joel thought you would be smart enough to apply the guidelines to your own situation. You've done that to a degree, but you're making the list needlessly inflexible.

      - Do you use source control?

      If your source control does not actually control the source effectively, it isn't source control. It's just a thing you put your source code into to make your life a living hell.

      -Can you make a build in one step?/Do you make daily builds?

      This one you have a small point on, but the obvious purpose here is to automate the process of publishing the latest version of the software to the team in order to avoid mistakes in the build/deployment process. Server side scripting, for example, isn't compiled or "built", but all the pieces do need to be in place and everyone needs access to the most current version. "Building" in this case would mean deploying the new code to the internal test server so all the developers know what the most current version of the web site is and can actually use it to verify that everything is working. This prevents you from making changes that are so large they are difficult to trace (if you have source control and nightly builds, you know exactly who screwed up and when). There should be an automated process to ensure all of the needed components are, in fact, there. It's just as critical for things that don't build as it is for things that do, it just looks different so you may not realize it.

      "make this a 'deploy package' in one step" I hope you mean deploy to the test server in one step, and not publishing it out to the world. If not you totally missed the point of nightly builds (it's to catch major bugs before the code needing debugging becomes too large).

      I could accept Garcia's "Do you have automated build or deployment procedures?" as a replacement for "Can you make a build in one step". The point is automation to avoid procedural mistakes, not compiling/deployment itself.

      -Do you fix bugs before writing new code?

      "Use unit testing here" - There is no need to be so specific. Unit testing is an effective modern tool, but it will not catch all bugs, particularly systemic bugs. The point is that you need to fix the major, money sucking bugs before you add new features.

      -Do you have a spec?

      "overrated" ??? The specification is the thing that describes what you are trying to do! How the hell can you write anything but hodgepodge software, especially with more than one developer, if you don't have overall design goals written down somewhere where they can be referenced? You can change the specification if your goals or needs change, but you should always have one! I suspect this is an especially serious flaw for open source projects that don't have strong leadership, given the distributed nature of open source.

      -Do programmers have a quiet working conditions?

      "ditch the phones" ?? What if your programmer works from home, how are you supposed to effectively communicate? Email isn't good enough for all situations, IM is better but still doesn't quite cut it, and frankly it encourages people to interrupt you more often. Quiet working conditions are what you need, not a simple lack of phones. I think if you were to expand this you should add "free from distractions" to the end of that. These days, it can be very quiet in your office yet still be extremely distracting with emails and IM notifications popping up all over the place.

      • by Grishnakh (216268)

        "ditch the phones" ?? What if your programmer works from home, how are you supposed to effectively communicate? Email isn't good enough for all situations, IM is better but still doesn't quite cut it, and frankly it encourages people to interrupt you more often. Quiet working conditions are what you need, not a simple lack of phones. I think if you were to expand this you should add "free from distractions" to the end of that. These days, it can be very quiet in your office yet still be extremely distractin

  • by emurphy42 (631808) on Sunday December 26, 2010 @01:24PM (#34670578) Homepage

    The guy's apparently from Belgium, so English is quite possibly his fourth language, so I won't bother ripping on his grammar. His content is another matter...

    Original: Do you use source control?
    New: Do you use a distributed source control system?
    My current Big Work Project has a whopping four coders, so I can't speak to when distributed source control is a big deal and when it's overkill.

    Original: Can you make a build in one step? Do you make daily builds?
    New: Do you have automated build or deployment procedures?
    Clearly inferior. An error-prone 20-step process that you run once a month is still automated, just not automated enough and not used enough.

    Original: Do you have a bug database?
    New: Do you use a bug database where users can report bugs directly?
    The BWP is still small enough to get by on Excel lists, with changes manually merged back into the master copy by the project manager, or just e-mail for quick-turnaround items. Excel is noticeably clunkier than an automated system, but you may want to start there to get a feel for what the automated system should do (e.g. separate status fields for "the coder did some testing and thinks it's fixed" vs. "the tester did some more thorough testing, confirmed that there were no misunderstandings, and couldn't find any more edge/corner cases").

    Original: Do you have testers? Do you do hallway usability testing?
    New: Do you have a testing protocol, and specific resources for testing?
    I hate calling people "resources". Also, your protocol should stick to the right things (e.g. "when you find a problem, report X and Y and Z"); an example of a wrong thing is "test this specific way of using the system", because real users will go off the rails.

    Original: Do you fix bugs before writing new code?
    New: Do you fix bugs before implementing new features?
    More or less equivalent.

    Original: Do you have an up-to-date schedule? Do you have a spec?
    New: Do you have a roadmap, and you don't make important changes to the short term priorities?
    These have become fuzzy for no good reason that I can discern.

    Original: Do programmers have quiet working conditions? Do you use the best tools money can buy?
    New: Do your team work in good conditions (quiet environment, flexible schedule, freedom to choose development software, fair paycheck...)
    More or less equivalent. "Fair paycheck" is so blindingly obvious that it shouldn't need to be pointed out. "Flexible schedule" is a genuinely good addition; I've personally gained some peace of mind by saving some tasks for evenings/weekends when I knew I wouldn't be interrupted by other work stuff (family stuff is another matter, but easier to control), and consequently taking it easier during normal business hours.

    Original: Do new candidates write code during their interview?
    This has been omitted completely for no good reason that I can discern. Maybe he's lucky and hasn't had to clean up after a bad coder yet.

    • In my experience DVCS isn't "overkill" for anything ; if anything, it's less effort for the single developer than say, Subversion would be because you don't have to set up a repository separately ; you just do a

      git init

      (or your chosen DVCS)

      And off you go. Some of them (Bazaar) will let you set things up so they work more like a central VCS. While the GUI tools are possibly not as mature as something like TortoiseSVN, I find using the CLI and spawning GUI dialogs for logs and merges to be slicker than using

  • That's it. No tools, methodology, procedures, or what have you will make up for the lack of good programmers. And good programmers will do well no matter what the tools, procedures, methodologies, etc are (barring Kafka-esque hindrances).

    So here's my revised list:
    1) Is the company full of good programmers?

    Of course, acquiring and maintaining good programmers doesn't just happen. New hire interviews need to be technically based, the staff needs adequate compensation, and management should not get in the way

    • by am 2k (217885)

      That's it. No tools, methodology, procedures, or what have you will make up for the lack of good programmers. And good programmers will do well no matter what the tools, procedures, methodologies, etc are (barring Kafka-esque hindrances).

      I disagree. You can stuff the top ten programmers of the world into a company, but without a proper team around them they'll just get nothing done that's worth it. For example, see Duke Nukem Forever. That didn't fail because of bad programmers. Other example: Microsoft Bob. That didn't fail because the programmers were crap, it failed because the product designer (user experience designer, workflow designer, product management, whatever you like to call it) was a complete failure.

      Good software projects nee

  • This is evaluation of what precisely? All of those things are surely good to have, some are really a 'must have' especially if there is more than one developer. But in reality none of that answers the question: "is the software company a kind of company I would want to work at?"

    There is nothing there about what kinds of projects the company is doing, what kind of working conditions are set, what kinds of flexibilities are allowed, there is nothing there about desire/ability of the company to require excell

    • This is a test of general dysfunction.
      It doesn't tell you anything about teams that pass. But it tells a lot about teams that fail.
      Everything on the list is a simple and easy thing a development team can do to improve productivity.
      So, if a team is not doing these things, why not? What do they have against productivity?

      This test will stop being useful when most development teams master the basics. But that time has not yet come.

    • by Gorobei (127755)

      This is good advice.

      My eyes glaze over when a candidate starts asking about what versions of what products she will be using. No one cares. If we made the wrong choice, I expect someone to get some consensus and fix it.

      I always tell a candidate about management structure: it's 1 boss per 20 workers, so there won't be a lot of hand-holding or meetings, initiative is required, etc. That's the easiest way to avoid a bad match.

      Also, always walk the candidate through the group's workspace. 2 minutes there sa

      • by mjwalshe (1680392)
        seriously 1->20 have you or your company not heard of span of control - army's don't use 1 NCO to 20 squadies for very good reasons.
        • by Gorobei (127755)

          When we decide to hire high-school graduates and give them guns, I expect we'll reconsider.

          Until then, we'll hire self-directed, highly-educated professionals. They tend to be a better fit for writing complex software.

  • Do you use a distributed source control system?

    The companies that need this are limited. And in some ways it's a bad sign. Makes it easier to ship your job to India.

    Do you use a bug database where users can report bugs directly?

    Assuming you do some sort of post processing to control flooding attacks, and do quality control, etc, this is ok.

    Do you have a testing protocol, and specific resources for testing?

    Are there seriously software companies with more than 5 coders with no qa? You have to know what you're getting into with a group too small to have discovered the need for qa.

    Do you fix bugs before implementing new features?

    This isn't always the right thing to do. It's sometimes a good practice because you can tackle bugs

  • by EWAdams (953502) on Sunday December 26, 2010 @01:38PM (#34670634) Homepage
    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.
  • by MobyDisk (75490) on Sunday December 26, 2010 @01:38PM (#34670638) Homepage

    as many companies are moving to web technologies, and new development tools exist.

    Web technologies change nothing in his test. And his test does not mention any specific tools, just general classes of tools. "Do you use source control?" and the catch-all "Do you use the best tools money can buy?" are asking if you use the general types of tools that distinguishes good shops from bad shops. You could add "Do you use a mock-objects framework?" but now it isn't universal, because that doesn't always apply and could be subject to debate.. Then it just becomes someone's checklist of "Have you used every tool that I use and endorse?" The Joel Test is universally applicable, covering the kinds of things all shops should do.

    Most of the updates in his blog are a pedantic rewording of the existing ones.

  • by localman (111171) on Sunday December 26, 2010 @01:45PM (#34670676) Homepage

    So I call myself a software developer, but I've never worked on any group project that required builds at all. I've done java and c++ projects of my own, but any time there was more than just me, it was a web development environment where things were broken up to the script level and it was very rare that one person's work would break another's. Launching individually tested scripts was fast and asynchronous. It seems to me that is a superior model for web development. I know that the place I used to work switched over to java for a lot of stuff, and now they have build headaches and compatibility issues between the communication layers. I'm not sure what the advantage is there for web development. Isn't the whole idea of builds a pointless carryover from desktop software?

  • Daily builds? (Score:2, Interesting)

    by ukyoCE (106879)

    Daily builds have never made much sense to me. If someone breaks a build, the fix is easy - revert their commit and tell them they screwed up. If you have expensive (processing-wise) unit tests that you want to check with continuous integration, I can see value in that at least.

    Other than that, Joel's list is quite solid. Those are the first things to fix at a company, and the things to jump ship over if the leadership refuses to address them.

    • by vlm (69642)

      Daily builds have never made much sense to me. ... If you have expensive (processing-wise) unit tests

      Some places use expensive (angry-customer-wise and lost-sales-wise) "unit tests". Life is never easy in operations or the call center, but at least they know if it breaks at 2:36pm it almost certainly has to be an operations problem as opposed to a failed deployment.

      Also important for rolling out new features simultaneously with marketing/sales. Or having a formal way to cease new rollouts before the big fundraising round demonstration (of course stopping regular deployment merely means you'll be demoing

      • by ukyoCE (106879)

        I don't think Joel was referring to deploying/launching daily builds, just building in a test environment. I guess this goes against the spirit of the Joel Test, but I assumed it went without saying that any build going to production would go through building, unit tests, and QA. I'm pretty sure Joel was talking mainly about compilation to check for syntax errors.

        I would expect the same build/unit test/QA process for a build used to demo, and that the demo would go to a UAT or other stable environemnt (in

    • by kybred (795293)

      Daily builds have never made much sense to me. If someone breaks a build, the fix is easy - revert their commit and tell them they screwed up.

      If you aren't doing daily builds, how do you know when the build is broken? The idea is to catch it soon after the problem occurs, so it's easier to fix.

      • by ukyoCE (106879)

        I figured out from another post that daily builds is in reference to large compiled projects. Somehow every project I've worked on has either been interpreted (eg. php: 'svn up' and visit any page, if configs are broken you find out immediately) or compiled projects small enough to rebuild every time you make a change to verify the change works.

        It's actually really hard for me to imagine coding on a project so large I can't test my code as I work. Waiting even a day to get a build created and see the resu

        • by Kjella (173770)

          I don't think that's the point, I can apply patches and build a new kernel in relatively short time if everything else is compiled already. I think it's more that there's regular testing that everybody's work merges properly and passes unit testing. It's more than a little frustrating if it's the big merge day and after every developer has checked into the master branch then everything fails.

  • I have misgivings about the "daily build" mania. Like "extreme programming", it maps well to the class of problem which consists of a large number of loosely coupled features. Most web-based systems fall into that category. It's not a good model for, say, a compiler, a file system, a database, a solid geometric modeling system, or simulation system, or a real-time control system, where there are rigorous overall constraints and "features" don't dominate the problem.

    (Most of the stuff Joel's company do

    • by Gorobei (127755)

      Interesting.

      The system I'm currently working on has most of the above (compiler, custom file system/database, simulation system, real-time constraints, and also compute farms, global 24/7, hundreds of developers, etc.)

      We run "build-and-test on check-in." No code base forks, no long-lived private branches. "Daily build" would be horribly inefficient for our specific workflow, even 5 minute builds are a bit annoying.

      The environment you are operating in determines a lot about the tools/practices you get: we

  • The first two questions in particular are certainly not applicable in many environments.

  • This guy has no relevance in today's era of programming (and had questionable relevance even before today). He hasn't done anything special and I don't know why people continually feel the need to post about this elitist asshole who has only had marginal success in the business with software built for pointy haired bosses that no programmer actually likes.
  • A question that cuts past all the red tape, and gets right to the heart of the matter...

    "What do you think, sirs?"

  • <mini-rant> The summary tells us

    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.

    Great! That's really cool, I've been waiting for an updated list -- from Marc Garcia no less!

    What, who the f--- is Marc Garcia? Well... he's done well at getting his web site pageranked (probably in part due to this "anonymous" submission). Beyond that he seems to be one of the countless dime-a-dozen bloggers who have opinions nobody cares above. Hey, no insult intended - I have a blog nobody cares about too -- but then you don't see me trying to get it featured o

As far as we know, our computer has never had an undetected error. -- Weisert

Working...