I was randomly browsing through the job offerings page on Stack Overflow Careers and noticed THIS monstrosity:

enter image description here

How can Stack Exchange, the company created by Joel Spolsky, not pass his own test?

Is it just me or is there something off about this?

  • 9
    It's definitely a bug, 6-8 weeks is a consistently up-to-date schedule. There's no testers though, straight to prod or bust. – Tim Stone Jun 3 '15 at 6:24
  • 3
    "I don't always test my code... But when I do, it's in production" – Canadian Luke Jun 3 '15 at 6:52
  • 3
    Testing is out/crowdsourced to Meta regulars. One nicael is worth an army of offshore testers. – Deer Hunter Jun 3 '15 at 6:55
  • 5
    That test score is misinterpreted. It's like golf. You want as few points as possible. AFAIK source control will be turned off by the end of this week. – Bart Jun 3 '15 at 8:17
  • 6
    The "Do you fix bugs before writing new code" green checkmark should probably be a yellow checkmark for "sometimes": meta.stackexchange.com/… – CRABOLO Jun 3 '15 at 13:00
up vote 19 down vote accepted

Do you have testers?

Shadow Wizard is right; our testers are you lot! If you read the Joel On Software post about the Joel Test, you'll notice his recommendation (emphasis mine):

If your team doesn't have dedicated testers, at least one for every two or three programmers, you are either shipping buggy products, or you're wasting money...

We could hire a handful of testers, but because Stack Overflow has been all about the community from the beginning, we prefer to work more publicly and roll things out incrementally to real users. There are far more people here on meta and on Stack Overflow who will find and report bugs, or suggest improvements, or give us general feedback, than we could ever afford to hire. And we love the dialogue with the community: you suggest a feature, we build a version of it, roll it out to Meta, ask for feedback, make some changes, and roll it out to the rest of the network. The process is public, we don't have to hypothesize too much about what users might want or think (because we hear from you directly), and we can iterate much faster.

The development of the Stack Exchange engine is very different from most other software development. We're very lucky that our primary audience is programmers, that our community is global, and that the community feels so invested in the development of the product. All of that combined allows us to have "testers" who give us knowledgeable feedback (and often suggestions for solutions) very, very quickly.

I wouldn't want it any other way! :)

Alright, second question...

Do you have an up-to-date schedule?

The answer to this one is "sort of". We have a roadmap for the year, but it is high-level and generally outlines goals / areas of focus rather than being made up of detailed project plans and timelines. We do plan more detailed schedules at the project level (we try to break large projects up into roughly one- to two-week chunks), but we aren't as rigid about it as Joel recommends – I don't think we've ever kept a single timesheet, for example.

The type of scheduling that Joel goes into a lot of detail about is focused mostly on big releases. ("If you wanted to ship in six months, but you have twelve months on the schedule, you are either going to have to delay shipping, or find some features to delete.") For Stack Overflow and Stack Exchange, we continuously release (we have multiple production builds per day), and there's less coordination needed than for, say, a new Careers feature. The Careers team operates a little differently – due to the need to coordinate with marketing, train the sales team on the new feature(s), etc. – but even that is pretty flexible, and we rarely have large enough releases to need to detailed scheduling 6 months in advance. We mostly ship new features, not new versions.

Our preference is to ship things quickly and iterate based on real feedback and data. We love the Joel Test and its recommendations, but I think it's best for product development teams to be aware of best practices but make choices about what processes work best for their specific team, product, and circumstances. We constantly look to improve our processes here, but we aren't going to adopt new strategies just for the sake of checking off an item in a list.

  • To your first point, I think it'd be reasonable for us to check off the "testers" box. – hairboat Jun 3 '15 at 14:48
  • 1
    @abbyhairboat I read have tester as on your payroll. Laura made clear that that is not the case so unchecking is...not right? But you can more easily check with the inventor of that list if I'm choosing a to narrow interpretation. Oh, and to be clear: I'm a happy tester of your software ;) – rene Jun 3 '15 at 15:10
  • 4
    Yeah, the Joel test refers specifically to a QA team / paid testers. But maybe it's time for a refresh :) – Laura Jun 3 '15 at 15:35

Well, Stack Exchange fails on two requirements of the Test:

  • Do you have an up-to-date schedule?
  • Do you have testers?

Dunno about up-to-date schedule, but as for testers I'm pretty sure I know the answer: they don't hire testers because they have... us! :)

That's right, this very site (MSE aka Meta Stack Exchange) is used to test new major features before they are being launched network wide. With dozens and hundreds of eager users, they can save those dollars for better use.

Some recent examples:

  • 13
    Quoting Joel... you're wasting money by having $100/hour programmers do work that can be done by $30/hour testers. When do the paychecks for being testers arrive? :-) – psubsee2003 Jun 3 '15 at 8:44
  • @psubsee2003 haha! Where is it from? – Shadow the Welcoming Wizard Jun 3 '15 at 13:20
  • Couldn't link it before (easily) because I was mobile, but the quote is from item 10 in The Joel Test: 12 Steps to Better Code – psubsee2003 Jun 4 '15 at 0:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .