Joel Test Updated

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

Comments

Who is this guy?

[Anonymous Coward]

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

Re:Who is this guy?

[IamTheRealMike]

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?

[FooAtWFU]

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?

[jmerlin]

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?

[rokkaku]

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?

[TheRaven64]

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?

[arth1]

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?

[arth1]

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?

[vlm]

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?

[MacGyver2210]

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?

[maraist]

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.

Re:Who is this guy?

[LinuxGeek]

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?

[abhi_beckert]

Because what we have works pretty damn well, and we can trust it. Only once a week someone runs into a problem that'd be solved easier with a newer SCM, and it'd only save him/her 30 minutes.

So we can quantisize it at ~30 minutes per week of lost productivity

Switching to a new SCM will require many many hours of research by whoever is tasked with organising the switch, and it will require a couple of hours at least for everyone else, in learning the new gotcha's (lets not forget, some of the guys who are using SCM where I work are graphic designers or even just the person answering the phone. Some of them barely know CSS, and their command line knowledge extends about as far as running the shell scripts we've created for them).

And every piece of software I've ever encontered has bugs. Bugs are mostly a non-issue when you're familiar with the software, you've seen it all before and have memorised the workaround (or at least someone else in the office has memorised it). With new software, these bugs have a habit of appearing when something else is going wrong, turning a small problem into a big problem requiring hours of googling.

These switches have to happen from time to time, but they've got to be avoided where possible. And at least in the office I work for, swiching from svn to hg or git does not make sense. Not because svn is better, just because the switch itself is not worth the end result. We'll switch one day, but not until there are significant benefits, and probably not until there's something better than hg/git around.

Re:Who is this guy?

[jmerlin]

I think you and others misread my comment. I didn't say "if there's something better, why wouldn't you switch?" The comment I replied to seemed to be discussing the choice of an SCM in regards to a necessity for a team, as if the team doesn't exist yet and/or just formed. The only relevant reasons not to use something like git or mercurial is if everyone on the team is so much more comfortable with another SCM that they feel the day or two it'd take to learn a DSCM would be a significant impact. It's free, it's not difficult to learn, so I don't see any reasons not to use it if you're at a point where you're making a decision: "what SCM should we use?"

Re:Who is this guy?

[Meski]

Off the top of my head: Cost of moving existing system? Cost of retraining?

Re:Who is this guy?

[Cyberax]

Only automation support is a sticking point.

Otherwise, if you can't manage a switch to a different VCS then you have some problems (either with developers or with organization). Which nicely proves Joel's point.

Of course, there can be exceptions, like working with large amounts of unmergeable content (CAD drawings, images, etc.) where DVCSes do not work well.

Re:Who is this guy?

[Mongoose Disciple]

Otherwise, if you can't manage a switch to a different VCS then you have some problems (either with developers or with organization).

What you can or can't manage is one thing, and what is or isn't worth your time is another thing entirely.

Re:Who is this guy?

[Compaqt]

Are the graphical tools for git up to the level of SVN? Like TortoiseSvn or others?

Re:Who is this guy?

[Nemi]

DVCS allows trivial re-integration

I have read about DVCS's, and I understand how merges are much easier. However, you say that providing them read-only access will make merges "trivial". Is this true in all cases? What if their work takes several months. And in that time, what if they extensively change an existing class that has been deleted in the main code base? How is the merge trivial in this case?

Re:Who is this guy?

[Rysc]

Interestingly enough this was covered by Mr. Joel himself in relatively recent times.

tl;dr: DVCS' are fundamentally better and anyone can benefit from this, even in-house corporate teams working on a single central source base.

Re:Who is this guy?

[Rysc]

Better merging and branching can't fix problems that can't be fixed. Rather than ask "Doesn't this break it?" you should be asking "Does this break it any worse than it breaks when we do this while using a centralized VCS?" The answer is no. In fact, it's slightly less of a nightmare.

Re:Who is this guy?

[turbidostato]

"There's something to be said for 'bad' use of DVCS in a private company. But here are the good usage patterns IHMO"

Maybe. But all you provided are good usage patterns for *any* source code manager, distributed or not. And even then you are pushing for some bad practices as if they were good. In example:

"I want to experiment with an alternate code path (but don't want to deal with the politics - remeber coders have egos"

You'll have to manage it at the "ego" level, not the tool. You are either allowed to "wander" your ideas, and then you do it within the central repository (for the manager to know what are you doing and for other members of the team to know why it failed when needed -if it was worth it, it eventually would have been merged to main line), or you are not allowed, in which case you don't do it.

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

You give them access to a ACLed branch or you give then a different repo and you use the "vendor branch" pattern to merge it back to your trunk.

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

Read the user manual for, say, Subversion. You probably will be surprised.

"central 'owner'/'maintainer' of a given project."

That's why you want a promotion manager (usually near to or the same person than the project's technical lead). You want the authorized/knowledgeable one to be the one "building" your master/production builds and that's easier with a central repo than with distributed ones.

"as with linux, for larger projects development-teams, you can have lieutenants that perform step 7 for sub-sections of the larger project."

And you do it just the same with a central than with a distributed source code management system.

What I see once and again is that distributed SCM make sense for community-based open source projects and they have raised a feeling for best practices on developers but still, central SCM tools are better suited for "usual" corporate development.

Re:Who is this guy?

[maraist]

If the point is to outsource a subsection of the code, then the implication is that they 'own' a sub-tree of your code. The point is merging separately mirrored CVCS's is hard, merging decoupled VCS's is possible, and DVCS's make the latter trivial.

But that even remotely owned code-sections can be tweaked and via email/phone collaboration, merged on an ongoing basis.

And no, giving them restricted access is not always an option - VPN, firewall rules, login polluting namespaces, central LDAP/kerberos or what-have-you security risks, etc.

Re:Who is this guy?

[maraist]

"You'll have to manage it at the "ego" level, not the tool."
You're only addressing a justification for the actual problem which is experimental code paths.

"You give them access to a ACLed branch or you give then a different repo and you use the "vendor branch" pattern to merge it back to your trunk."
Are you serious? You want to grant firewall, VPN, internal login-names to an outside firm? You want to maintain customer support of their development environment?

In this case, the point is that they go and do their own thing - you require that they use SOME DVCS. Then they zip up a snapshot and send it to you. Deviations from the shipped product can then be co-maintained if need-be. This isn't possible with a CVCS, since you'd have irreconcileable forks.

"Read the user manual for, say, Subversion. You probably will be surprised."
Almost the entire DVCS world is a reaction to subversion/CVS deficiencies.

svn branch merging can be made to work, but leaves a tremendous ammount of meta-data (every branch range-delta). It can be a nightmare to keep track of if you do any degree of branching beyond feature-branches. Then your branch tree gets enormous over time, so you'd like to blow away the namespaces. But then you have this bolted-on feel to the history of the now phantom branches. And it doesn't take much to bork your data (and not notice it for several versions). Add in a handful of code-reformatting and it's a nearly impossible mess to recover from.

Note this isn't a CVCS v.s. DVCS issue, it's a subversion issue. But that was the line-item at hand.

"And you do it just the same with a central than with a distributed source code management system."

Well, not really. The use case of linux is that there are several co-maintained forks. Is this just an open-source problem? Hardly. Try forking your own company's product. Why would you do such a horrible thing, you might ask? Well, if your 'core' is leveraged in say a custom cookie-cutter shop, then the core can get overly bloated and require slimming or specialization. Or maybe you just want to start from scratch, but fully intend to maintain the original code base for years to come (possibly with new major features that you'd like to share between the old and new fork). At a minimum, to maintain reconciliation, the CVCS server needs to be common between the two forks - not plausible in open-source forks. Many VCS plugins do support the subversion sub-path concept. Some, by default do not (trac commit plugins, etc). And just in general, it's nice to have a dedicated VCS per project - thus forking a project gives it an unfortunate status. And once you decide the fork gets it's own CVCS, you're stuck with diff -C5 / patch. Welcome back to RCS.

Re:Who is this guy?

[turbidostato]

""You'll have to manage it at the "ego" level, not the tool."
You're only addressing a justification for the actual problem which is experimental code paths."

Don't think so. You are either aproved to dive into an experimental code path, in which case you can do it on a branch on a centralized SCM or you are not, in which case you shouldn't hide the fact you are working on it by means of a distributed SCM.

""You give them access to a ACLed branch or you give then a different repo and you use the "vendor branch" pattern to merge it back to your trunk."
Are you serious? You want to grant firewall, VPN, internal login-names to an outside firm? You want to maintain customer support of their development environment?"

Did you miss the *or*? If you have problems opening your internal SCM to a partner of you, you use the vendor branch approach (which conceptually, by the way, is exactly what you do when using a distributed SCM).

"In this case, the point is that they go and do their own thing - you require that they use SOME DVCS."

No you don't. *You* need an SCM and the other party needs an SCM. Since you are explicitly firewalling from their process and you are only interested on their results, you don't need to pick up into their developing process but just gain access to the development results (their final/milestone versions).

"svn branch merging can be made to work"

Now you are moving from centralized SCM versus distributed SCM to some tool (subversion) versus some other (git). That's not what we were talking about.

""And you do it just the same with a central than with a distributed source code management system."

Well, not really. The use case of linux is that there are several co-maintained forks."

And now, by ill-quoting you are missrepresenting me. Please notice that in my last paragraph I stated that "What I see once and again is that distributed SCM make sense for community-based open source" so you are saying "not really" to what I already agreed with you.

"Try forking your own company's product. Why would you do such a horrible thing, you might ask?"

I do it day in-day out (while I in fact do ask myself why should I do such a horrible thing. I nod to your arguments and then some more).

"At a minimum, to maintain reconciliation, the CVCS server needs to be common between the two forks"

Not needed while usually benefitial: the "vendor branch" pattern again.

"And just in general, it's nice to have a dedicated VCS per project"

Not. It's just the first idea somebody comes with. And given that most people hasn't the slightest idea about how to properly manage source code (both at the level of programmer and technical project lead) that's what you usually get. And I already stated that one of the biggest benefit that distributed SCMs like git bring to the table is that they have rised concern about the benefits of proper source code management (or even just *some* source code management, whatever).

"once you decide the fork gets it's own CVCS, you're stuck with diff -C5 / patch. "

No, you aren't. Again, have a look at the Cederqvist and its "vendor branch" pattern.

Re:Who is this guy?

[maraist]

"You are either aproved to dive into an experimental code path, in which case you can do it on a branch on a centralized SCM or you are not"

I'm not sure what world you live in. Yes, you technically can just make a branch to apply the experimental results. And the 'hiding' aspect may or may not be of value (not this is NO different than keeping your work in a view - except that you can't collaborate without patch/diff; svn switch + branch can work but by trigger the same buracracy). Companies that stifle innovation and ingenuity (read as nearly 100% of them - differing only in degree) will generally lose output. Tools the encourage ego-hiding innovation promote bottom-line productivity.

All else being equal, this is a good thing. Not sure you're hesitation.. Again it HAPPENs.. It's just a matter of being poorly supported by the tools.

But forget even that aspect. Try reproducing a bug. This often requires producing artificial code-conditions, and is sometimes best by putting '#if 1' or equilvant code.. This is meant as temporary stuff.. I'm never intending to check it in.. But now.. guess what.. I want to collaborate. Yes, I can svn switch + svn cp and collaborate, but it feels wrong.. So most people AREN'T going to do it. Plus it's extra work. But if we're in a DVCS, it's a no brainer. make some local branch, then someone else pulls locally from it.. we blow the branch away.. Yes, technically it's the same thing. But it feels more correct. and thus statistically it'll be more likely to happen and thus not hamper productivity. If for no other reason than a continuous integration solution isn't going to pick up the branch checkin, compile, detect errors and shame-email the whole group.

" If you have problems opening your internal SCM to a partner of you, you use the vendor branch approach (which conceptually, by the way, is exactly what you do when using a distributed SCM)."

Conceptually, perhaps, but not practically. I have suffered vendor integration with idiot management who request changes to the PHP code from the vendor, and idiot sys-admin applies the changes; since he doesn't know of any source-control locations, he doesn't back-port or back-communicate. Then the management verbally communicates to the vendor of the change, and now 4 out of 6 parties have no idea that something just happened. Unless the vendor can 'see' the VCS branch, then the low-level programmers on both sides can't trivially reconcile. But it is not good for their people to see any details of our larger product and visa versa. Likewise with not allowing them VPN'd access into a local source control machine.

The code 'drop' concept is exactly the problem I have dealt with unsuccessfully with svn. It only works when it's a black box, not a morphic piece of code of which there is shared ownership. It is precisely the pattern that DVCS excels at - so while you CAN shoe-horn it only other systems, you necessarily lose functionality / and code-defensiveness (e.g. it just works). So if you have the option (which you do), why wouldn't you leverage it. The vendor branch doesn't need to be the same solution as your central tool.. By throwing it in /vendor you've already admitted that. Thus it's going to require a special process thrown on top of it anyway. Why not use the right tool for the job.

"Not. It's just the first idea somebody comes with" [on project per VCS]

Empirically I'd dissagree. Most shops I've worked in use a monolithic svn. It's more work to export multiple svn repositories. Things like eclipse require setup per VCS. So I don't think people go out of their way to segment projects. The main reason I've encouraged it is that the 3rd party tools I've worked with that take advantage of checkin triggers don't work properly for multi project environments. Some tools that'll trigger on every checkin will go through a lot of work, just to find that nothing has changed. 'git-svn' for example takes about an hour to scour my sub-project, since it builds meta-data on every checkin, whether it's in the filtered path or not.

Re:first test post

[Anonymous Coward]

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

Grammar test fail

[PatPending]

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

[Bigjeff5]

The "sentence" is total fail.

I find the irony of that statement absolutely hilarious.

Re:Grammar test fail

[radio4fan]

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

[zach_the_lizard]

You could add a question mark at the end, and it would be something a Brit would say: Do your team work in good conditions? They seem to consider collections to be plural, while we Americans consider them to be singular.

Re:Grammar test fail

[Anonymous Coward]

As a Brit I can tell you we say "Does your team..." No one I know would say "Do your team"

Re:Grammar test fail

[RocketRabbit]

Don't get snooty. Do you go down the pub or to hospital?

Local variations may offend you and the language authorities, but they are a law of language change and development. Battling them is about as useful as tilting at a windmill.

Old system is fine.

[Anonymous Coward]

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.

[Creepy]

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.

[Bigjeff5]

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.

[vlm]

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.

[PatPending]

and translate customer speak into something that makes sense

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

Re:Old system is fine.

[GWBasic]

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.

[gadzook33]

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.

Re:Old system is fine.

[DiegoBravo]

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.

Re:Old system is fine.

[shish]

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 patch introduced a bug)

Re:Old system is fine.

[Grishnakh]

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.

Re:Old system is fine.

[Grishnakh]

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 environment (the other reason was because I was told that I was expected to learn about everything going on by overhearing it, as we never had meetings to disseminate information). I just couldn't concentrate in a bullpen environment with constant talking and distractions all around me, and my productivity was terrible. Most of my previous jobs were not like that: I had a real cubicle in them. No, it wasn't a walled office, but it was good enough that I could concentrate pretty well, which I simply couldn't do in a bullpen.

Are companies moving away from high-wall cubicles? Or was that stupid company I last worked at just a fluke?

Re:Old system is fine.

[Grishnakh]

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

There's a Dilbert comic about this. Every company wants top talent, but they want to pay "competitive" wages, which means the market average. Why companies think they're going to get top talent for average pay, I don't know, but what they get in reality is lots of people claiming to be top talent, but who aren't, or maybe people who really are top talent, but work like slackers.

Re:Old system is fine.

[luis_a_espinal]

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 you still have a spec... in agile. And specs have always been about requirements, as in requirements specifications. To be honest, I don't understand your differentiation between specs and requirements, and neither the supposed applicability of the list to waterfall vs agile. I'm my own personal experience (having done strict waterfall, iterative and agile), the list seems to apply rather well in a general sense to each type of development cycle.

Also Agile often has non-dedicated roles

That's YOUR definition. There are agile teams with defined roles and ownerships. There is nothing in agility that calls for a removal of 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).

That's YOUR experience. Nothing wrong with that, but it should be obvious that you cannot define the general "agile" experience using your anecdotal experiences. Also, and no offense, the more that your job and skills can be commoditized, the more that they will be offshore. Specially in the commercial sector, the best way not to get offshored is to become a highly specialized expert on a particular field or niche.

Re:Old system is fine.

[plover]

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.

He didn't say ALL bug tracking database entries MUST be created and entered exclusively by the customers. He only said that customers must be able to enter bugs into a database; presumably this means without having to convince a phone operator that their script shouldn't end before they record the bug. Think of it as a separate queue of input to your bug database. A human in your QA area would still have to triage them, and assign them to existing defects to get them into the bug tracking system that all of the developers and QA use. The QA person would still to come up with a way to replicate the bug and document that using your company's template for such things. Or the QA person would contact the original customer to follow up and learn how to replicate the bug.

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

No, but the point is that a roadmap should be someone's responsibility. If there is no roadmap at all, you're dealing with a rinky-dink outfit that has no plans for the future, and may not have the foresight required to survive.

And not changing short-term priorities helps keep the developers away from the day-to-day discussions of new or changed features. This lets them effectively focus on their assigned tasks without interruptions.

Re:Old system is fine.

[cyclomedia]

Spec/Requirements, it's all the same. The Boss/MD does not give a shit about Joels system. Testers? don't need testers just need the coders to not write bugs. Specs? There's no plan! anything that costs time and money (like documentation) that's out the door.

We have "tasks". e.g. Add a button on form X that does Y when Z. 500 of these "agile" cycles later and the software is big, slow, and buggy as fuck and you need to load 25 projects simultaneously because of all the freaky dependencies. Because there never was a plan. I'm fairly certain a lot of software is written this way. And no. We can't refactor it because that would take 6 months alone and no one bothered to write down each requirement/spec as they went along and we're not allowed technical documentation because the boss says that if he can't understand it it's to be deleted. And the boss is paying our salary and doesnt want to wast 6 months of cash when he wants to be able to stroll up tomorrow and say "I want a new button on form X that does A when B but only if C is D and the user is wearing blue socks".

They pay me plenty at least. And yes, it was like that when I got here.

I always prefered this

[rsilvergun]

Joel Test for my scientific endeavors.

Re:I always prefered this

[Sage Gaspar]

The Mike Test was clearly superior.

Re:I always prefered this

[Rysc]

That's blasphemy and you know it.

Nothing valuable with this addendum.

[Anonymous Coward]

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

[Mr Thinly Sliced]

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

[Scareduck]

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

[chengiz]

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

[Anonymous Coward]

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

[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?

Re:A serious question

[Surt]

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

[rsborg]

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

[rudy_wayne]

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.

Re:A serious question

[Anonymous Coward]

Thank god for free labor.

Fog Creek Internships

Not really... Probably a deal in NYC, but he has actually railed against unpaid internships in his articles.

Re:A serious question

[arnhem]

Of the same level of seriousness, everyone could also ask a similar question "why is Bruce Schneiner called a "security expert"", much like Joel Spolsky a "software expert". Answers: - By the fluency of the two guys in making his "words" heard, sometimes even if those words are borrowed - By the help of the two guys' friends in the publishing world - By the stupidity of the crowd who are always willing to use some "experts' name" in order to make their words heard. They would repetitively say: "Joel says this, Bruce says that"

Re:A serious question

[RocketRabbit]

He's not just an expert bullshitter but a total fucking moron as well. Reading his checklist makes me puke in my mouth a little bit.

I was an unfortunate user of FogzBugs at a shop I used to work at. They were all ex-Intel folks who had a woody for Windows, and it fit them to a T, because FogzBugs was too much work, and it was half finished.

Wo fucking gives a shit about daily builds. That's just retarded unless your program is very simple, changes little, or the programmers' changes are not likely to interact.

Re:A serious question

[Rysc]

Why is the parent scored 0? Modded down for quoting relevant facts?

Re:A serious question

[Bill, Shooter of Bul]

Bruce Schneier is a security expert because he has written what are widely regarded as the best books for cryptography and written several quality encryption and hash algorithms. One of his newest hash algorithms "Skein" has been selected as a finalist for the NIST SHA-3 competition.

That's impressive and current. Joel? Not so much.

Re:A serious question

[Doctor O]

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 time tracking features and the resulting projected release schedules, but I'm still testing stuff out and would like to know the pitfalls to see whether we can/want to accomodate them.

Total failure

[gnasher719]

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

[Frosty Piss]

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

[Kjella]

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

[vlm]

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.

Re:Total failure

[Frosty Piss]

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.

Nonsense.

It *trys* to guess your accound setting, and if it can't (and even if it thinks it has), it gives you the option of doing in manually. Yes, I'd like that option first, but really no big deal.

There are a lot of *other* things that make me start to think about Outlook...

Re:Total failure

[OverflowingBitBucket]

> 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 are run by people who care about the quality of their project and are keen to hear about problems with it, and plenty of commercial organisations that won't respond with much apart from "sorry that you've run into a problem, by the way, don't expect a fix". Suggesting that non-responsiveness is the primary domain of open source projects ahead of commercial ones is disingenuous; if anything, I've found the opposite to be true.

Re:Total failure

[dbIII]

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 they are more polite that that.
On the other side of things I was the newbie that asked "Where is UNDO in photoshop - it's easy to find in AutoCAD or even gimp but I can't find it anywhere" and was flamed by hundreds that assured me that "true professionals" (which I never pretended to be) never need UNDO.

two big ones missed out

[oliverthered]

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

[oliverthered]

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

Re:two big ones missed out

[PatPending]

Hookers and cocaine?

Re:two big ones missed out

[oliverthered]

crack whores save time.

Users reporting bugs directly

[Rik Sweeney]

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

[Frosty Piss]

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

[alvinrod]

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

[Bigjeff5]

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

Re:Users reporting bugs directly

[nOw2]

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.

Re:Users reporting bugs directly

[mjwalshe]

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

Re:Users reporting bugs directly

[Mongoose Disciple]

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.

This might be a regional thing. I've interviewed hundreds of places across my career and I don't think I've ever had a hard number on salary until they made me an offer.

Re:Users reporting bugs directly

[HornWumpus]

What if you are the new team?

I quit a job because they hired back a team lead that I had taken over for.

Re:Users reporting bugs directly

[mjwalshe]

Well you would normally expect an indicative range at least otherwise how do they get the right level of people applying for the job.

Not much point in going through one or more interviews when what your offering is below what they will accept - otherwise its a waste of both sides time.

Re:Users reporting bugs directly

[Mongoose Disciple]

I'm not trying to defend it, I'm just saying that, in practice, in the regions where I've worked if you insisted on knowing a salary range before the interview process, you would probably be unemployed. It isn't considered standard there.

Re:Users reporting bugs directly

[mjwalshe]

well so the good people will go else where then :-) or alternatively use contacts inside the wire to get the pay scales - may be that's why all the good tech jobs are in the states with more liberal employment laws.

Knowing the employers pay range does give you a slight advantage in negotiating

Which I did see happen in BT the guy used his contacts to get the Personnel Contract pay scales and negotiated to quite near the max for that grade.

Wait, what?

[glwtta]

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?

[Bigjeff5]

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?

[shish]

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, the git client tools can bridge to an SVN server (or many other types of VCS), so you can start using all this loveliness whenever you're ready, no need to make it a company-wide change

Re:Wait, what?

[Mongoose Disciple]

Hmmm. But is what you're saying really an endorsement of distributed source control, or is it more a statement of how much SVN specifically seemed to hate its users? :)

Re:BUT, consider:

[PatPending]

Thanks for proving Santa does not exist. However by doing so you have also proved Trolls exist.

My take on it:

[JamesP]

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:

[Jay L]

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:

[Bigjeff5]

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.

Re:My take on it:

[Grishnakh]

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

I really hate distractions, but I've never had problems with IMs distracting me from my work. How do I do it? Simple: I don't use IM software! Even at my last job, where we were supposed to, I simply didn't. No one even noticed.

Re:My take on it:

[JamesP]

OK, that was supposed to be "only if they cost LESS than $1000'

Point-by-point analysis

[emurphy42]

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.

Re:Point-by-point analysis

[Dr_Barnowl]

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 a GUI alone.

And of course, there are lots of lovely plug-ins that let you get your feet wet using a DVCS to interact with a traditional CVCS like SVN ; I find this makes having to use them just about tolerable now.

Re:Nobody takes this seriously...

[PatPending]

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

Re:Nobody takes this seriously...

[alvinrod]

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.

A good software company needs good programmers.

[etymxris]

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.

[am 2k]

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.

[etymxris]

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.

[am 2k]

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.

[etymxris]

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?

[roman_mir]

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?

[Software Geek]

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?

[Gorobei]

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.

Re:Evaluation of what exactly?

[mjwalshe]

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.

Re:Evaluation of what exactly?

[Gorobei]

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.

nonsense list for the most part

[Surt]

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.

[EWAdams]

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.

[crunchygranola]

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?

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

[dbIII]

If the people with keys to every part of the building are ripping you off then you have real problems.

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

[RocketRabbit]

If your programmers can't clean up after themselves you either have children or prima donnas. Your office manager person should not be too proud to bust out the vacuum cleaner once a week either.

The Joel Test does not need updating

[MobyDisk]

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

[localman]

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?

Re:Builds

[VortexCortex]

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?

::sigh:: I do all of my coding (including web development) in a DVCS repo. A "build" is just a branch/commit that is deemed fit for production. With source control its easy to see what changes cause errors such as "compatibility issues between layers", and even roll back those changes.

IMO, SCM (esp. DVCS) is not "a pointless carryover from desktop software". It's very useful; Give it a try. If only to keep your own JavaScript or (X)HTML/CSS changes in order, "multiple branches" is powerful concept.

Daily builds?

[ukyoCE]

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?

[vlm]

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?

[ukyoCE]

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?

[kybred]

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.

Re:Daily builds?

[ukyoCE]

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

You'd find out the next time a coder updates from the repository and builds, which (ideally) shouldn't take more than a day or two anyway.

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

Ahhhh, now I get it. With a build time that long I can definitely see the necessity for daily builds. I've never worked on a single compiled project anywhere near that size. Now I feel bad for whining that my last java project took 2 minutes to build ;)

Joel must have been talking about large compiled projects too, based on some of his other posts. I guess that item on the test deserves a mention that it only applies to large compiled software.

Re:Daily builds?

[ukyoCE]

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 results of my work sounds frustrating! I can definitely see why daily builds would be a necessity on a project that takes 30 minutes+ to build.

Re:Daily builds?

[Kjella]

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.

Re:Daily builds?

[jjohnson]

Joel's daily build mantra comes from Microsoft, where almost all products (including Windows and Office) require it. The Windows daily build farm is apparently quite impressive--which it has to be to completely build the whole OS every night. Yes, it's for large, complex projects that would previously be built weekly or monthly, creating incredibly long detection/correction cycles.

Additionally, they had a punishment for breaking the build: If it was your code, you became the babysitter every night until someone else broke it. That provided a strong incentive to test your code thoroughly before checking it in.

Re:Nobody takes this seriously...

[Surt]

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.

Not another presumptuous list

[gremlinuk]

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?

[pgag45]

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

Re:Nobody takes this seriously...

[vlm]

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.

Incrementalism

[Animats]

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

Re:Incrementalism

[Gorobei]

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 deploy code to production about 500 times/day, core code a little less frequently.

Don't Think Much of His Additions

[SwashbucklingCowboy]

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

Distributed source control is better for anyONE

[SuperKendall]

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 person integrated into the build process.

I've used ClearCase, CVS, RCS and Subversion. Distributed version control (git for me though there's nothing wrong with Mercurial) just works better, for how programmers work.

And it makes for horrible public interactions.

[pavon]

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 fix. In reality the "bug" has morphed into an ever changing thing that means something different to each person involved and which is thus impossible to ever truly "fix".

Bugzilla in particular is horrible to use as an outward facing webapp (I don't even like using it internally).

Bad Test

[Cyko_01]

my name is Joel and I failed it.

Enough spolsky

[kuzb]

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.

My Joel Test is one question...

[derfy]

A question that cuts past all the red tape, and gets right to the heart of the matter...

"What do you think, sirs?"

Re:BUT, consider:

[FatdogHaiku]

Thanks for proving Santa does not exist. However by doing so you have also proved Trolls exist.

Dammit Man, don't you see it? Santa is not an ELF, He's a TROLL!!!
It's so insidious, it makes perfect sense.
Oh, he's also still a perv too...
He see's us when we're sleeping!
He knows when we're awake.
We have to sit on his lap and ask for gifts!!!
Dear God, When Will People Wake Up?

Wait, what?

[thePowerOfGrayskull]

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 on slashdot. What's worse is that he's doing so by using a well-known name -- and it seems to be working His most recent article has 45 comments, while most of the previous articles have 0.

Well, if nothing else I guess he knows how to get visitors to his web site - in spite of nobody having ever heard of the guy before today. Funny part is that he'll probably *get* a following out of the deal -- all for writing one post that references the opinions of a relatively well-known 90s-era software developer while providing no actual thoughts of value. .

Okay, to be fair - yes it's possible that he did not submit this himself; and that some random person stumbled across his article and posted it here. After all, enough people upmodded it indicate there must be some interest -- though that could be on the basis of the misleading summary... no matter the issues in the original posting, at least it didn't lie by implication.

</mini-rant>

Re:Do you do hallway usability testing?

[emurphy42]

From TFA (the original, not the haphazard rewrite):

A hallway usability test is where you grab the next person that passes by in the hallway and force them to try to use the code you just wrote. If you do this to five people, you will learn 95% of what there is to learn about usability problems in your code.

Re:Nobody takes this seriously...

[Rysc]

Having seen visual foxpro in action I can assure you that they did not just "rename it and release it as access," unless you count castration as a usual part of the renaming process.