×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Joel Test Updated

timothy posted more than 3 years ago | from the inspect-the-width-of-the-coal-chute dept.

Businesses 182

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."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

182 comments

first test post (0)

Anonymous Coward | more than 3 years ago | (#34670354)

first test post

BUT, consider: (0)

Anonymous Coward | more than 3 years ago | (#34670368)

1. No known species of reindeer can fly. BUT there are 300,000 species of living organisms yet to be classified, and while most of these are insects and germs, this does not COMPLETELY rule out flying reindeer which only Santa has ever seen.

2. There are 2 billion children (persons under 18) in the world. BUT since Santa doesn't (appear) to handle the Muslim, Hindu, Nigger, Jewish and Buddhist children, that reduces the workload to 15% of the total - 378 million according to the Population Reference Bureau. At an average (census rate of 3.5 children per household, that's 91.8 million homes. One presumes there's at least one good child in each.

3. Santa has 31 hours of Christmas to work with, thanks to the different time zones and the rotation of the earth, and assuming he travels east to west (which seems logical). This works out to 822.6 visits per second. This is to say that for each Christian household with good children, Santa has 1/1000th of a second to park, hop out of his sleigh, jump down the chimneys, fill the stockings, distribute the remaining presents under the tree, eat whatever snacks have been left, get back up the chimney, get back into the sleigh and move on to the next house. Assuming that each of these 91.8 million stops are evenly distributed around the earth (which, of course we know to be false but for the purpose of our calculations we will accept), we are now talking about .78 miles per household, a total trip of 75.5 million miles, not counting stops to do what most of us must do at least once every 31 hours, plus feeding and etc. This means that Santa's sleigh is moving at 650 miles per second, 3000 times the speed of sound. For purposes of comparison, the fastest man-made vehicle on earth, the Ulysses space probe, moves at a poky 27.4 miles per second - a conventional reindeer can run, tops, 15 miles per hour.

4. The payload on the sleigh adds another interesting element. Assuming that each child gets nothing more than a medium-sized Lego set (2 pounds), the sleigh is carrying 321,300 tons, not counting Santa, who is invariably described as overweight. On land, conventional reindeer can pull no more than 300 pounds. Even granting that "flying reindeer" (refer to point #1) could pull TEN TIMES the normal load, we cannot do the job with eight, or even nine. We need 214,200 reindeer. This increases the payload - not even counting the weight of the sleigh - 353,430 tons. Again, for comparison - this is four times the weight of Queen Elizabeth.

5. 353,000 tons traveling at 650 miles per second creates enormous air resistance - this will heat the reindeer up in the same fashion as spacecrafts re-entering the earth's atmosphere. The lead pair of reindeer will absorb 14.3 QUINTILLION joules of energy per SECOND, EACH! In short, they will burst into flames almost instantaneously, exposing the reindeer behind them, and create a deafening sonic boom in their wake. The entire reindeer team will be vaporized within 4.26 thousandths of a second. Santa, meanwhile, will be subjected to centrifugal* forces 17,500.06 times greater than gravity. A 250 pound Santa (which seems ludicrously slim) would be pinned to the back of his sleigh by 4,315,015 pounds of force.

In conclusion - If Santa ever DID deliver presents on Christmas Eve, he's dead by now. And he'd be a faggot.

======================
*Please note that centrifugal is a made-up non existent word. The real word should be centripetal. Centrifugal is a made up force that physics people HATE! So please, everyone use the world centripetal, not centrifugal. Thanks!

Update. (0)

Anonymous Coward | more than 3 years ago | (#34670372)

First UPDATED test post! Now, get off my lawn!

Re:first test post (1)

Anonymous Coward | more than 3 years ago | (#34670376)

Whoa, dude, be careful. Your little "test post" made it to production. A better deployment system could have prevented this, you know.

Who is this guy? (1, Insightful)

Anonymous Coward | more than 3 years ago | (#34670370)

Seriously, who the fuck is this "Joel" person, and why does anyone give a shit what it thinks?

Re:Who is this guy? (0)

Anonymous Coward | more than 3 years ago | (#34670380)

He was some Boo-Hah in the 90's. Long before you were born...

Re:Who is this guy? (3, Informative)

IamTheRealMike (537420) | more than 3 years ago | (#34670404)

Joel Spolski is a guy who runs a software company, and he used to be a program manager on Excel. However that's not why people give a shit about what he thinks. People read (past tense) his articles because they were pretty good, and explained stuff lots of people in the software business need to know but often don't. For instance if somebody doesn't understand Unicode, I often point them to his article explaining it .... because he did a pretty good job.

The real question is, who is Marc Garcia and why does the article submitter think we should care? In fairness, he says the "updated list" is just his personal opinion rather than something generally applicable, which is good because pretty much every software company I know would fail at least one or two of the points on there, including Google.

Re:Who is this guy? (1)

FooAtWFU (699187) | more than 3 years ago | (#34670424)

I don't see why distributed source control is so necessary for a team. I mean, git is neat and all that, but I'm thinking it's a lot more "nice to have" than "need to have".

Re:Who is this guy? (1)

jmerlin (1010641) | more than 3 years ago | (#34670446)

If something is nicer to have than most of the other SCMs, and still free, why wouldn't you get it?

Re:Who is this guy? (4, Insightful)

rokkaku (127052) | more than 3 years ago | (#34670502)

Do you sell your car every year to buy a new one? There's a cost to converting, so you have to make an engineering decision about making the conversion. The automated tools don't always work with old and complex repositories.

Re:Who is this guy? (3, Insightful)

arth1 (260657) | more than 3 years ago | (#34670636)

If it means redoing all of your established routines and teach people the new routines, rewriting all your automation, and obsoleting existing ticket or work log systems (or otherwise run two repositories in parallel, with the problems of authorativity that entails), "nicer" doesn't necessarily cut it. There has to be a gain that measurably outweighs the inconveniences.

Re:Who is this guy? (1)

vlm (69642) | more than 3 years ago | (#34670762)

There has to be a gain that measurably outweighs the inconveniences.

Not necessarily a gain, but a DCVS like git inherently "backs up everything that is needed or ever happened" to all the devs.

1) Ultimate multiple site backup capacity for disaster recovery

2) If engineered properly, bringing up another host in the cluster / bringing up a disaster recovery site is beyond trivial.

3) (the bad news) Security FreakOut!

If the big boss says this shall be a small component of the disaster recovery plan, well, then an abstract weekly metric result doesn't much matter, does it?

The other problem is the update article is inherently self contradictory. "Do you use a distributed source control system" vs "freedom to choose development software". So... free to choose, as long as someone with limited experience thinks you're making the only correct choice for all possible situations?

Re:Who is this guy? (1)

TheRaven64 (641858) | more than 3 years ago | (#34670564)

If anything, I'd count using git as a negative thing for a software company. In my experience, git encourages people to have their own private tree and put off pushing stuff as long as possible. In a software company, you want stuff in the central repository (where it is properly backed up!) ready for testing as soon as possible. You might want different people working on different branches, but you definitely don't want those branches anywhere other than in your central system.

Re:Who is this guy? (1)

arth1 (260657) | more than 3 years ago | (#34670728)

Gits have plusses and minuses. And in many cases, the good things about git are necessitated by the bad things.
Like the better merge facilities, which are much more needed, and still don't nearly make up for when you have to merge 10 branches from 20 developers instead of the simplicity of merging a team branch with a trunk.
Or the local copy, which is necessitated by not being guaranteed having access to an authoritative master.

Git is nice. But it's not a panacea that works for every situation.

Re:Who is this guy? (2)

maraist (68387) | more than 3 years ago | (#34670876)

There's something to be said for 'bad' use of DVCS in a private company. But here are the good usage patterns IHMO
1) checkin after every logically complete operation (for What The Fun Just Happened moments)
2) checkin every night (so if I'm sick tomorrow people can get to my work)
3) my-code-doesn't work, collaborate with someone down the hall or geographically remotely
4) I want to experiment with an alternate code path (but don't want to deal with the politics - remeber coders have egos)
4a) I want to experiment with an alternate code path, but don't want any risk to the trunk
4b) This code is too specialized, we need a much simplified version for this use-case (but need to maintain the original code path)
5) Let's say we suck at graphics, so we outsource to a 3rd party company. How the hell does this happen with central version control. F-no do we give them direct access. And if they email us a zip file of the final product, how do we keep in sync from there-on-out? Their or our changes will get over-written or go into non-versioned-hell. With DVCS, we can provide read-only access (possibly via emailed repository-clones). DVCS allows trivial re-integration. Security is maintained, reconciliation is trivial. History and auditing is somewhat maintained (you can obviously fake it). And most importantly we can switch a new NEW 3rd party contractor at any time, possibly even AT THE SAME TIME.
6) rebase (not DVCS specific). If I've got 10 branches (in svn or any place else), do I know for sure that after a while, the history has gotten too complex? In git at least, we can say, ok, these feature-branches should all be thrown away - lets 'rebase' to produce a pristine trunk and quite literally throw away all the branches by flattening them.
7) central 'owner'/'maintainer' of a given project. Make sure someone knows everything that's going on with the project by having them integrate or 'bless' an integration. With central repositories, this requires they do the merging. with DVCS, you do the merging as a 'candidate' and they either accept it as their own or not (e.g. fast-forward merging of your repository with theirs).
7a) as with linux, for larger projects development-teams, you can have lieutenants that perform step 7 for sub-sections of the larger project. For which each lieutenant will 'trust' each other's official repository and auto-fast-forward-merge. The singular project-manager can then choose for political reasons (because we are political in nature) to disagree with lieutenants decisions - as they are they primary responsible party (at least in closed-sourced commercial solutions). This works because lieutenants can continue with their private fork until they can form a mutiny - so ego's are maintained.

Look, it's needed for buzzword-compliance. (0)

Anonymous Coward | more than 3 years ago | (#34670576)

It's important for any buzzword-compliant software development organization today to use a distributed version control system, even if it doesn't actually benefit them in any way.

See, if you're not using a DVCS, then maybe you're still using relational databases, too. That'll make a lot of managers and executives really suspicious these days.

Re:Who is this guy? (1)

LinuxGeek (6139) | more than 3 years ago | (#34670986)

I don't see why distributed source control is so necessary for a team. I mean, git is neat and all that, but I'm thinking it's a lot more "nice to have" than "need to have".

Source control is important, regardless of the team size. One project I worked on years ago was some custom contracted software for a specialized industrial client. I was helping the lead programmer with initial deployment and bug fixes. Every couple of weeks the client would call me about a particular bug and let me know that it was back again. I'd go back to the code dump and they were right, a bug I had previously squashed was back again. This happened several times and I informed the lead programmer who told me that he didn't know how that bug was creeping back into the code.

I finally went to his system and found several different source code directories, all with different versions of the source tree and none that were in sync with my code base. A SCM tool would have allowed us to track code changes and enforce accountability. After the same bug popped up 5 times, the client was not very happy. SCM tools help to cut down redundant work and allow centralized quality control.

Re:Who is this guy? (-1, Troll)

Frosty Piss (770223) | more than 3 years ago | (#34670506)

The real question is, who is Marc Garcia...

HOW DARE Marc Garcia question the SAGE WISDOM of Joel Spolski! HOW FUCKING DARE! God forbid we should take the ideas that a smart guy penned 20 years ago and rethink them in today's world! Gosh, that's sacrilege!

Re:Who is this guy? (1)

MacGyver2210 (1053110) | more than 3 years ago | (#34670838)

Agreed! I don't know who this guy is, or why I should care, and the original list seems quite broad so it should encompass all new technologies without much updating.

Re:Who is this guy? (-1)

Anonymous Coward | more than 3 years ago | (#34670628)

Joel? He's a former Microsoft manager. And a faggot. He got fired (managers never get fired at Microsoft) and started up a company to do a bug tracking website. In VBScript. He thinks VBScript is the best language ever. Did I mention he licked to suck dicks? Also, he has a blog where he writes stuff that is often wrong. Not just a wrong opinion (cf VBScript and sucking dicks) but technically wrong.

Grammar test fail (1)

PatPending (953482) | more than 3 years ago | (#34670388)

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...

Re:Grammar test fail (0)

drinkypoo (153816) | more than 3 years ago | (#34670410)

The "sentence" is total fail. The sentence fragment is "correct" in countries like England where English escapes them, and they don't understand that a team is a singular entity even if it is made up of multiple lesser entities. (Although a committee is said to get dumber as it gets larger, and indeed it seems possible for one to be dumber than a fairly average individual.) With apologies to whoever I'm ripping off, or paying homage to, depending on where you stand.

Re:Grammar test fail (2)

radio4fan (304271) | more than 3 years ago | (#34670870)

Do your team work in good conditions...

The sentence fragment is "correct" in countries like England where English escapes them, and they don't understand that a team is a singular entity

In over 30 years of living in England, I never saw or heard this solecism committed by an English person.

It is a mistake — not a local variation — and is never correct.

Re:Grammar test fail (0)

Anonymous Coward | more than 3 years ago | (#34670454)

He's not a native speaker. It's not an excuse, just an explanation.
In any case, I've seen much worse.

Front Page? (0)

Anonymous Coward | more than 3 years ago | (#34670396)

A few hundred words by some guy who can't even take the time to half-bake his own ideas, instead poorly rephrasing someone else's to tack on a few now-stylish buzzwords, is now worth the Front Page?

You can do better, timothy.

Old system is fine. (5, Interesting)

Anonymous Coward | more than 3 years ago | (#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.

Re:Old system is fine. (3, Interesting)

Creepy (93888) | more than 3 years ago | (#34670530)

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).

Re:Old system is fine. (4, Insightful)

Bigjeff5 (1143585) | more than 3 years ago | (#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.

Re:Old system is fine. (1)

vlm (69642) | more than 3 years ago | (#34670790)

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 to enter their opinion in a separate "customer severity" field, which you might even pay attention to, or perhaps not. I would also never let the customer see the actual severity; "customer's reported severity" field, sure, but never your actual internal prioritization. Don't pretty much all post 1980 ticketing systems work that way?

Re:Old system is fine. (0)

Anonymous Coward | more than 3 years ago | (#34671008)

While I like his approach, he consistently leaves out on HUGE thing, which severely limits its usefulness. Joels' approach is a one-way street; it's all about him. That's completely wrong. You also need to impress the person being interviewed that they do indeed want to work there. That's glaringly missing from his agenda.

I've been consulting for over 20 years now, and have gone through lots and lots of interviews over the years. I've developed a number of "red flags" which have proven to be quite accurate, and if a company hits too many of them, I'll dismiss them regardless of what they offer. It's far better for me to have a client who will be delighted with my work, than one which you can't make happy inspite of the best that you can do. So you need to learn how to fire the interviewer. I have no problem with cutting an interview short if I'm not impressed, though that's rare.

The point is, if you're after top talent, you're going to need to distinguish yourselves from every other run-of-the-mill gig out there. Too many interviewers fail to understand this. If it's a plain old boring job, well sure. But then you shouldn't be looking for top talent (and it seems everyone wants top talent).

So what is it that makes your company so special? Why the heck should I want to spend my valuable time there? If you ignore answering this question during the interview, you as an interviewer have failed.

Re:Old system is fine. (1)

PatPending (953482) | more than 3 years ago | (#34671072)

and translate customer speak into something that makes sense

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

Re:Old system is fine. (1)

GWBasic (900357) | more than 3 years ago | (#34671086)

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.

Re:Old system is fine. (0)

Anonymous Coward | more than 3 years ago | (#34671212)

I think the original Joel questions still work fine.

The sad thing is that there are still a lot of companies that still don't pass it (either out of ignorance or simply don't care about the good things it can bring to a company).

Personally I cannot fathom a software company/internal group not passing #1 (source control), but I'm sure there are many organizations out there where this is the case. One-step builds (#2) are another thing that seem obvious.

Nothing valuable with this addendum. (1)

Anonymous Coward | more than 3 years ago | (#34670420)

If you actually read through the Joel Test writeup and explanations you will easily see that TFA has absolutely nothing positive.

This is someone with no experience actually running a software team trying on new buzzwords.

Is how open source devs would like corps to be run (3, Insightful)

Mr Thinly Sliced (73041) | more than 3 years ago | (#34670422)

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 (5, Interesting)

Scareduck (177470) | more than 3 years ago | (#34670426)

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:A serious question (3, Interesting)

chengiz (998879) | more than 3 years ago | (#34670562)

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?

Re:A serious question (1)

rsborg (111459) | more than 3 years ago | (#34670866)

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:A serious question (1)

Anonymous Coward | more than 3 years ago | (#34670618)

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.

Distributed version control systems are very useful in monolithic development environments. I find that being able to experiment locally and check in my changes frequently to be a huge productivity boon, and the merging capabilities in a DVCS tend to clobber any that I've seen with TFS/Subversion/Clearcase/CVS. Gone are the days of "please don't check that in right now because I'm working on a critical change" or "crap, this merge is so horrible that it'll be easier to just reapply the changes manually" or "I can't update this file because someone has it locked."

It took me a little while to fully wrap my brain around the value, but after doing so, I haven't looked back. I even use one for all of my personal work.

Re:A serious question (2)

Surt (22457) | more than 3 years ago | (#34670690)

So I haven't used any of TFS/Subversion/Clearcase/CVS in the last 10 years. Do they really not offer a branch structure that would allow you to do all of that without the need for distributed functionality? Sourcesafe and perforce both do.

Re:A serious question (0)

Anonymous Coward | more than 3 years ago | (#34670766)

You can create branches easily enough, but non-trivial merges, spanning dozens of files and/or directories, can turn into a serious exercise.

Re:A serious question (0)

Anonymous Coward | more than 3 years ago | (#34670930)

Depends. Does going at it at such a roundabout way that you need half an hour and a checklist in order to create a branch count as "offers a branch structure"?

Re:A serious question (2, Informative)

Anonymous Coward | more than 3 years ago | (#34670688)

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?

Re:A serious question (0)

FredMenace (835698) | more than 3 years ago | (#34671390)

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.

Let's let Joel (the original Joel) explain why in his own words: http://www.joelonsoftware.com/items/2010/03/17.html [joelonsoftware.com]

Did Joel think this was important? You be the judge:

In that podcast, I said, “To me, the fact that they make branching and merging easier just means that your coworkers are more likely to branch and merge, and you’re more likely to be confused.”

Well, you know, that podcast is not prepared carefully in advance; it’s just a couple of people shooting the breeze. So what usually happens is that we say things that are, to use the technical term, wrong. Usually they are wrong either in details or in spirit, or in details and in spirit, but this time, I was just plain wrong. Like strawberry pizza. Or jalapeño bagels. WRONG....

...And here is the most important point, indeed, the most important thing that we’ve learned about developer productivity in a decade. It’s so important that it merits a place as the very last opinion piece that I write, so if you only remember one thing, remember this:...

...This is too important to miss out on. This is possibly the biggest advance in software development technology in the ten years I’ve been writing articles here.

Or, to put it another way, I’d go back to C++ before I gave up on Mercurial.

If you are using Subversion, stop it. Just stop. Subversion = Leeches. Mercurial and Git = Antibiotics. We have better technology now.

Re:A serious question (0)

Anonymous Coward | more than 3 years ago | (#34671462)

having worked in comercial OS development starting in the 80's. Also worked in commerical compiler, networking, graphics, embedded, e-commerce re-engineering development, integration and release infrastructure, tools and process. I find this common thread

* if the codebase is monolithic, the team is medicore at best in terms of efficency and responsiveness to change. team rarely if ever hits schedule, almost all tools and process are a repsonse to the monolithic codebase. generally the reason the codebase remains monolithic is due to rampant bad practices in both architecture and implementation.... in most cases engineering is an anchor around the business teams neck. Unfortunately this is very common in Silicon Valley. We have architects of technology in software, rare will you find an architect of product. Architect of product must have both breadth and depth. The ability to architect the product to that is can be developed, built, tested, deployed and sustained, upgraded is rare indeed. Yet the most common practice still employed in the valley is to behave in a monolithic fashion. Most engineers will talk about how their solution is layered and modular... but it is still monolithic and tightly coupled. The ability to compete and respond to both business and technology change is to architect in a Layered, Moduar... and Loosely Coupled / Highly Cohesive approach. Funny enough, because the norm is to architect in a monolithic fashion.... most of the engineering tools are geared towards that behavior e.g (CVS, Subversion, Peforce)

* one has to ask themselves, what are the characteristics in achieving orgnaztional speed in a development environment and how does the transcend to the individual contributor (the word monolithic will never show up in a positive characteristic of achieving speed). what are some characteristics to achieving speed: Rhythm, Clarity, Focus. just taking those words and looking at the product architecture, the implementation, and the tools and processes that make up the product life cycle... now many facilitate in achieving rhythm, clarity and focus? and how many impact rhythm, clarity, and focus?

* if a person does not understand the value of DVCS, I would suggest they spend some time really thinking about the developers-short cycle (their bread-and-butter) and what it takes to share code prior to integration, and what impact it has on context-switching". Generally monolithic environments can support a developer doing a private build, test and deploy (whether to embedded or web), resulting in overly complicated integration processes that require constant hand-holding and context switching among the development team. Developers IMO are most productive when they can control their own destiny. if the product has been architected and infrastructure deployed where the individual developer is always tethered to the Borg (IT helpdesk, Release Eng for branches/builds and co-workers to get the most mundane tasks accomplished)... its just a mediocre environment... at best

Checklist for knowledge workers generally? (0)

Anonymous Coward | more than 3 years ago | (#34670432)

I would like to see a similar list for knowledge workers generally, starting with having a quiet, interruption free environment.

Total failure (3, Insightful)

gnasher719 (869701) | more than 3 years ago | (#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 (4, Insightful)

Frosty Piss (770223) | more than 3 years ago | (#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.

Re:Total failure (-1)

Anonymous Coward | more than 3 years ago | (#34670962)

I completely agree. But about Mozilla being very responsive, well... take Thunderbird, for instance - it's useless in its current incarnation but if you see the responses you get, well, it would be hilarious if it wasn't so bad. It has a big problem because it "guesses" your account-settings and basically automates the setup of your mailaccount. If it works, fine. But if it doesn't, you're SOL. One response to the problems was 6 screenshots with all kinds of fields circled in red, and if you entered the right incantations at the right setting of the moon, you might get lucky. An alternative was to introduce a race condition, where you actually raced the computer and if you clicked abort before the computer found the settings in the internet-database, you won and you might be able to manually change the settings to their correct version. Hurray. Yes, you get a response. But a response with some quality would be much appreciated.

The solution most users in the thread used was to ditch Thunderbird and re-install Microsoft Outlook or something else that, while not as powerful, actually enabled you to read mail.

Chrome managed to get itself removed from my testingsuite for intranet sites after it managed to kill the ability to use the Windows NT logon. It just didn't work, for weeks. And this wasn't in the beta, this was the release version that suddenly got patched into oblivion. Just when I was telling one of my clients that "Chrome is a very good browser". It made me look like a fool, and it also made me ditch Chrome for anything even remotely related to my business. Having the cloth pulled out from underneath me because of a stealth-patch I can't see coming and can't stop, is not something I'm going to build my reputation on.

And another one: there is a paid version of Pentaho, and a community edition. A colleague of mine was using the latest version of their ETL-tool a few months ago and had to go back to the community edition because the paid for version was completely useless - lots and lots of bugs. Jay for community editions :)

And if you compare that to Microsoft... I had a question 6 months ago about Microsoft Visual Studio, licensing and stuff. It was in the middle of the summer vacation and I mailed it in after working hours. I didn't get an email back, but I got a real live phonecall within the hour, with someone who actually knew exactly what was what. Now *that* is customer service. And I bought the license I needed the day after.

Re:Total failure (4, Interesting)

Kjella (173770) | more than 3 years ago | (#34670658)

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.

Re:Total failure (1)

vlm (69642) | more than 3 years ago | (#34670828)

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.

two big ones missed out (1)

oliverthered (187439) | more than 3 years ago | (#34670456)

Do you pair employees regularly (at least from time to time) to allow for cross training so the more experienced staff etc.. (whatever the experience) can learn with the less experienced ones.

Do you have an adaptive development strategy, beyond well just do it.

Re:two big ones missed out (2)

oliverthered (187439) | more than 3 years ago | (#34670486)

really most principals can be applied to any kind of work and the employee doesn't really matter (a developer should pair with a sales person, if that's the kind of experience you want to swap for instance)

Code repository = Auditable whatever, and filing.
Bug / Feature tracker = CRM or whatever.
Usability testing = Product evaluation and feedback.
etc....

Best tools money can buy, should really be most appropriate tools etc...

Users reporting bugs directly (1)

Rik Sweeney (471717) | more than 3 years ago | (#34670478)

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.

Re:Users reporting bugs directly (1)

Frosty Piss (770223) | more than 3 years ago | (#34670492)

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...

Re:Users reporting bugs directly (3, Informative)

alvinrod (889928) | more than 3 years ago | (#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.

Re:Users reporting bugs directly (1)

Bigjeff5 (1143585) | more than 3 years ago | (#34670574)

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

Re:Users reporting bugs directly (0)

Frosty Piss (770223) | more than 3 years ago | (#34670960)

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

Your project has that many code problems? Maybe you need a new team.

Re:Users reporting bugs directly (1)

nOw2 (1531357) | more than 3 years ago | (#34670852)

It doesn't work with the general public who enter anything and everything, appropriate or not. It doesn't work with corporates who prefer face to face meetings and everything discussed and tracked and accounted for. It doesn't work with small business who won't use it or if they do expect everything entered for free.

I don't have much experience of open source. Perhaps it works there.

Nobody takes this seriously... (0)

Anonymous Coward | more than 3 years ago | (#34670484)

The "Joel test" is nothing more than a big advertisement for his various "services."

He thinks Microsoft gets a 12/12 (lmao!) and organizations that don't give programmers "the best tools money can buy" are already losers LOL!!!

I guess it's the end of the fiscal year and he needs more business so he's getting his friends to refer to his obsolete and irrelevant standards.

Seriously good software isn't written by microsoft or by people who get 12/12 on that silly quiz.

M

Re:Nobody takes this seriously... (2)

PatPending (953482) | more than 3 years ago | (#34670580)

What working at Microsoft used to be:

If you were an alien and you came here in 1991 and you wanted to learn how to develop software, you would learn ten times as much at Microsoft as anywhere else, I think, because I watched these companies kind of flail making mistakes. There were things--really basic things, that companies did not know. Microsoft knew that loading a segment register on the 386 was a very time-consuming operation, and therefore on the 386 architecture you can't use far pointers unless you absolutely have to because it's extremely slow. Borland did not know that. Result: Microsoft Access loaded in 2 or 3 seconds; Borland Paradox for Windows took 90 seconds to get running. Because of something that Microsoft knew that Borland did not know. And that's one of a million examples.

Now Microsoft has forgotten all these things, and they've hired a lot of morons that don't know these things anymore. I think that now Microsoft is kind of a big tar pit where you can barely move forward because there's so much bureaucracy. But I learned a lot.

Source: http://www.foundersatwork.com/joel-spolksy.html [foundersatwork.com]

Re:Nobody takes this seriously... (3, Insightful)

Surt (22457) | more than 3 years ago | (#34670716)

The idea that borland didn't know about the performance of loading a segment register is ridiculous. It's in the intel manual. Everybody I knew who cared about the performance of software had that manual handy. Then eventually the compiler just took care of it for you and we all stopped caring.

Re:Nobody takes this seriously... (2)

vlm (69642) | more than 3 years ago | (#34670868)

The "nobody takes this seriously part" requires relating the 1991 date of the quote with MS buying Fox Technologies in 1992, along with their product Visual FoxPro, which I am told was renamed to "Access" and released in 1992.

Re:Nobody takes this seriously... (3, Insightful)

alvinrod (889928) | more than 3 years ago | (#34670588)

This test probably isn't applicable to some open source projects, but there's probably a modified version of the test that could indicate whether an open source project is likely to succeed. Many of the questions on the test should be common sense by now, but would you want to work for a company that didn't use source control? Even if you were working alone you should be using some kind of CMS. Some times the best tools money can buy don't actually cost a thing because they're FOSS. Initial and support costs aside, how is using the best tools available bad advice?

If you think Microsoft products are bad, imagine how much worse they would be if Microsoft wasn't answering yes to a lot of those questions. Also understand that the article was written in 2000, when the computer world landscape was vastly different than it is today. Google and Apple where nowhere near as relevant, Linux wasn't a viable option for grandma, and it appeared as though Microsoft would continue to dominate the industry just as it had in the 90's. If you wanted to name drop a company that everyone would know and recognize as a leader in the software industry, you would have used Microsoft as well.

Oh yet another Guru type (0)

Anonymous Coward | more than 3 years ago | (#34670490)

Yeah, seen enough of them from the old Dot-com boom.

Seriously, there are enough good software professionals around who do good work without claiming to be a Guru. And IMO none of these Gurus are worth a damn iota of good work.

Wait, what? (2)

glwtta (532858) | more than 3 years ago | (#34670518)

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.

Re:Wait, what? (1)

Bigjeff5 (1143585) | more than 3 years ago | (#34670616)

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 effectively control the source code would be the same. No need to force distributed source control on one guy in an office just because "it's 2010 and we do web shit now".

And why fix bugs before implementing new features? How is that better, or really any different than fixing bugs before writing new code? Joel talks about prioritizing bug fixes elsewhere, if you need help understanding that. The idea is not that every bug is fixed before a new line of code is written, it's that you are constantly fixing bugs, and you don't put major bug fixes on the back burner to add new features. Which is what writing new code is about, is it not? I still don't understand why he changed that.

Plus some of his ideas (like his take on the bug database) are just stupid.

Re:Wait, what? (0)

bk2204 (310841) | more than 3 years ago | (#34671266)

Everyone does not necessarily need a distributed source control system. (Although I use one and am happy with it.) But if you're ever sending your programmers out of the office somewhere and expect them to do work, distributed source control is essential, since they may not have access to the Internet wherever they're going.

My take on it: (1)

JamesP (688957) | more than 3 years ago | (#34670542)

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 be fine

Do you fix bugs before writing new code?

-use unit testing here

Do you have an up-to-date schedule?
Do you have a spec?

- overrated

Do programmers have a quiet working conditions?

- ditch the phones

Do you use the best tools money can buy?

- the best tools are free. Use only tested and true tools, and ONLY if they cost $1000,00

Do you have testers?

- this is really important

Do new candidates write code during their interview?

- important as well

Do you do hallway usability testing?

Re:My take on it: (1)

Jay L (74152) | more than 3 years ago | (#34670586)

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: (3, Interesting)

Bigjeff5 (1143585) | more than 3 years ago | (#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.

Point-by-point analysis (3, Insightful)

emurphy42 (631808) | more than 3 years ago | (#34670578)

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.

A good software company needs good programmers. (2)

etymxris (121288) | more than 3 years ago | (#34670592)

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 of programmers trying to do their job. However, employees don't need to be treated like prima donnas. They just need management that commands respect and respects them likewise.

Re:A good software company needs good programmers. (2)

am 2k (217885) | more than 3 years ago | (#34670784)

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 need a lot of factors to work perfectly together. You can't just isolate a single cog (the programmer) and assume that the whole mechanism will just fall into place.

Re:A good software company needs good programmers. (1)

etymxris (121288) | more than 3 years ago | (#34671002)

You assume by "programmers" I only mean "implementers". "Programming" as I'm using it subsumes all stages of the SDLC. If you need to have separate roles for each of those things you described, then your company probably isn't doing well. A good programmer can tell a customer that what he wants doesn't make any sense, and that there's a perfectly good alternative that will do everything the customer actually wants while being very easy to implement. If you have five people between the customer and those who understand the technical limitations, then nipping issues like this early is going to be difficult.

The same goes for management. You need management that's adept both leadership-wise AND technically. Otherwise the coders won't have any respect for him. A software manager that thinks the low level details are beneath him is a manager that's going to fail. Sure, it's impossible for everyone to know everything. But the manager needs to have the ability to understand technical issues that arise, even if they are very low level.

I don't know the specific histories of Microsoft Bob or Duke Nukem Forever. My impression is that Bob was a product that never should have existed. Anyone with common sense should have realized that, not just a programmer. My understand of DNF is that they kept changing the underlying engine. Perhaps they wanted it to be too perfect for its release, due to the limited life of most video games. I'm more familiar with iterative products that build upon previous releases and don't have the market issues inherent to game programming.

But I do want to mention Diakatana. Romero wanted the game design to be completely independent of the implementation details. That didn't work very well for him.

Re:A good software company needs good programmers. (1)

am 2k (217885) | more than 3 years ago | (#34671092)

You assume by "programmers" I only mean "implementers".

No, I assume "the ones writing the sourcecode".

If you're only working on projects where the only required specialization is programming, then I envy you, because that is very rare. Even in very small projects, you need others.

For example, I've yet to meet any programmer who is able to do any significant artwork for the software (just look at Minecraft), and I've yet to meet any graphics artist who is able to do any significant software development. Those two things seem to be mutually exclusive.

Additionally, your perfect programmer might just be horrible at user workflow design, market research or manual writing (I bet most are, actually). Fire him, just because you only want to have multitalented people on the team? Or maybe you need some other specialists after all?

Re:A good software company needs good programmers. (1)

etymxris (121288) | more than 3 years ago | (#34671222)

Well admittedly we must come from very different areas of programming. I've programmed business software for the past ten years and everything I've never really needed artwork for anything. For user interface design, developers just need access to the customers. Putting people between the customers and programmers makes things worse, not better.

I don't believe in developing and marketing products. The idea of developing a product first and then trying to sell it doesn't make much sense to me. The only stuff I code is stuff that has an immediate need to exist.

I'll grant that manual writers and QA can be valuable even when they don't code. I'll also grant that artists can be valuable and necessary, depending on the project. I disagree on workflow designers or user interface designers. Just keep the customers in the loop and between the customers and developers the best solution will develop.

Evaluation of what exactly? (1)

roman_mir (125474) | more than 3 years ago | (#34670598)

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 excellence or initiative, there is nothing there that helps you to understand if your work will be rewarded based on your contribution, etc.

Sure, there is probably correlation between a company that works on multiple projects and that can in principle allow the developers to work from home (for example) and things like 'distributed source control'. But that is maybe a correlations, not a causation.

Where are the questions about management structure? The types of projects that you'll be engaged in? The kind of initiative the company is expecting (or not expecting), the kind of documentation that will be expected, the kind of maintenance you'd be expected to do, the kind of work hours you'll be putting in, something to measure the expected stress levels due to scheduling/resource mis-allocations, etc? You need to understand those if you want to be able to make informed decisions on the compensation and work conditions you'll have.

The source control, etc., it's all good, but it's all irrelevant! That's because YOU can change it once you are on a project, I had to change those things many times, from source control implementation, to documentation structures, even management structure. The real question for me is always: what do you really expect me to deliver and given the levels of stress associated with it what will you be paying per hour? (contracts only of-course).

Re:Evaluation of what exactly? (1)

Software Geek (1097883) | more than 3 years ago | (#34671174)

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.

Re:Evaluation of what exactly? (1)

Gorobei (127755) | more than 3 years ago | (#34671446)

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 saves an hour of explaining how your group works.

Past scores cannot be relied upon in the future (0)

Anonymous Coward | more than 3 years ago | (#34670608)

My boss brought this test up when he first started and we scored maybe 3. Looking at it now we only score 1 - go figure!

nonsense list for the most part (1)

Surt (22457) | more than 3 years ago | (#34670610)

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 while you're fresh on a topic, but it can likewise be a focus distraction. As with another item below, this seems to be a demand to dump agile.

Do you have automated build or deployment procedures?

Well, I won't argue with this one. Removing meaningless grunt work is generally a good idea where possible.

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

So you're ruling out working anywhere doing agile? Agile works great, and makes changes to short term priorities all the time.

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

Our environment is loud loud loud and generally that is considered one of our best features. We supply ear phones if you need quiet time for concentration. We will let you pick your editor, etc, and the pay is fine, those seem like reasonable requests.

Simple test for when a company is too big. (5, Insightful)

EWAdams (953502) | more than 3 years ago | (#34670634)

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.

Re:Simple test for when a company is too big. (1)

crunchygranola (1954152) | more than 3 years ago | (#34670904)

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.

How about the contractor (or landlord) supplied janitorial/maintenance crews?

The Joel Test does not need updating (3, Insightful)

MobyDisk (75490) | more than 3 years ago | (#34670638)

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.

Builds (2)

localman (111171) | more than 3 years ago | (#34670676)

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? (1, Interesting)

ukyoCE (106879) | more than 3 years ago | (#34670700)

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.

Re:Daily builds? (1)

vlm (69642) | more than 3 years ago | (#34670916)

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 what happens when all the memory leaks out and swap space fills, or transaction logs or whatever local equivalent)

Re:Daily builds? (1)

ukyoCE (106879) | more than 3 years ago | (#34671062)

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 the "doesn't change every day" sense, not the bug-free sense). There's no reason to stop coding and commits to demo a stable build of your product.

But...that was a lot of assumptions, like multiple testing environments, that probably don't exist at companies failing the Joel Test.

Re:Daily builds? (0)

Anonymous Coward | more than 3 years ago | (#34671306)

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.

How can you know if the build is broken if you don't try it regularly?

I'm in IT at a fairly large software company. The local product group has daily builds (and even multiple builds in a day, all automated). There's another product group in another city where they're lucky to get a build of the software once a month: so a developer checks in code and waits three (or more) weeks to see if the changes helped in functionality or speed or hinders it. Once a new build is released they then have to go back and check all the changes they've made over a period of weeks to see if they were correct.

Contrast with the guys in my office who, after checking in code at 3 PM (after making sure it at least compiles on their workstation), get a build available at 6 AM the next day for when they get into the office.

AFAIK, there's local a build kicked off every time someone does check-in by an automated process, so you can actually get a new binary with your changes about 1.5 hours after you make your code changes (it's a large tree). And we're talking about multiple platforms as well (Mac, Unix, Windows). If there's a breakage in the build an e-mail goes out informing people of it and that check-in can be reverted in less than two hours of it hosing things.

Which of the two situations is more conducive to making sure your code works?

Not another presumptuous list (1)

gremlinuk (454089) | more than 3 years ago | (#34670726)

Paraphrasing both Joel S and Marc G : Do you do everything my way, just 'cos I ( ... think I know better than a guy that ... ) runs a two-bit software company in New York?

Of course I sodding don't: my company writes for it's conditions and requirements, and not yours.

If I choose to use SVN or GIT or even PVCS, what's it got to do with you?

If the personal dynamics in the team are slightly competitive rather than perfectly "A: let's do it your, way. B: No your way. A: no, insist - your way. ... ad nauseam", does that preclude producing decent software? (I'm C, "C: will you just get it done already!")

Software development isn't about one process or another, it's about meeting the sodding customer's requirements, so they can get on with THEIR business, and most of the time they couldn't give a flying duck what methodology you use, as long as the software does what it says on the tin, doesn't cost too much, and isn't a pain in the ass to use every other day!

architecture? (1)

pgag45 (1541755) | more than 3 years ago | (#34670788)

How is there no mention of software architecture or design considerations? imo, this is one of the biggest problems plaguing software development.

Incrementalism (1)

Animats (122034) | more than 3 years ago | (#34671096)

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 does isn't that advanced. Their products are a project management program, a front end to an existing version control system, and a "remote administration tool" which sounds like Back Orifice. [cultdeadcow.com].)

Real programmers use remote debugging (0)

Anonymous Coward | more than 3 years ago | (#34671434)

13) Can you remote debug?

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...