Eh, they had to add in action for it to sell tickets. Kinda lame. But it still had a great story underpinning it.

I'm still surprised how few people figured out that Saito incepted Cobb (with the idea he could get through customs into the US) and sent him to limbo on purpose (when he shot him at the end). I guess the plot really was too complicated -- we have only Nolan to blame for not being more blunt about it.

Most people instead sought a simple explanation for the movie's ending despite it being inconsistent, and then complained that the movie had plotholes or was inconsistent. Doh.

The ending was unambiguous - the top didn't fall, and indeed, couldn't have. The movie was explicit that dying wouldn't wake them up because of the sedatives. Saito shot Cobb. He woke up in limbo imagining that he made it home, thanks to Saito convincing him (an inception) that he could get Cobb through customs.

Saito may have been planning to shoot Cobb into limbo all along, but that isn't completely clear. It's likely though, since Saito insisted on going along with them.

If you go into a movie trying to hate it, you're pretty much guaranteed to hate it. I'd bet your supposed plotholes were explicitly explained in the movie if you had bothered to pay attention instead of spending the whole time grasping at straws.

The hotel loss-of-gravity action scene was a bit unique, but the action was still weak overall. It sort of felt like Nolan wrote the plot, took it to the studio, and they said "ok great whatever, it needs more action to sell". So they went back and added in the bits about dream defense force and threw in some guns and, unfortunately, probably sold more tickets as a result.

I'd be interested to hear what you thought was logically inconsistent about it, while you're at it.

"It's all a dream"? You must have watched a different movie than me. Not only was it not "all a dream", but it was also nothing like the grade school "I-don't-know-how-to-resolve-this-so-lets-make-the-main-character-wake-up-and-it-was-all-a-dream" hack that you're referring to.

OP didn't say to get rid of cookies, he said browsers shouldn't need to opt-out of the cross-site tracking discussed in the summary. A practical implementation would be if all browsers started blocking 3rd party cookies. This has been an option for a while, but as its not the default, it breaks a lot of random non-nefarious websites.

Unfortunately workarounds would be found by advertisers anyway, eg. having the website install the advertiser's cookie for them and traffic the info behind the scenes instead of through your browser.

These are two somewhat fundamental UI approaches. Although you might say the complex multiple-route approach is the natural or evolved method, while the single-way-to-do-anything is a more intentional UI approach.

I haven't use iOS *or* Android, but my experience learning the Xbox 360 UI has been subpar. When there are 5 ways to do everything, you have to learn 5 ways to do everything, and there are little hooks and catches to each of them. Many of the features of the 360 menu have at least 2 routes in the 360 dashboard, a 3rd route in the "home" button menu, plus a 4th route in-game for many actions. It's needlessly redundant and confusing.

That said, it's also very subjective. It's not as simple as "count the routes to a piece of functionality, if there are more than 1, you're doing it wrong". Google is pretty good so I suspect the Android is at a happy medium between Apple-simple and Microsoft-convoluted.

Since it's a settlement it wouldn't be a legal precedent either way. But it still seems like its information the judge and jury could and should take into consideration?

Overloading can certainly muddle code readability, but it still depends on someone doing something wonky or overcomplicated with an operator instead of a named function. Which you could argue, comes down to "bad code is bad".

In Java on the other hand, I find it totally unpredictable and unreadable. Bad Java code uses operators and tends to have major bugs due to object VS primitive issues. The "better" Java code uses functions everywhere for equality, addition, etc. So instead of being able to quickly tell where doSomething is called, you see extremely wordy nested functions for math that in C++ would actually look like math.

I wasn't very happy with operator overloading in C++, but now that I've used Java, I think I want C++ back.

They're not arguing that probable-cause initiated arrests with a judge onsite is wrong. They're arguing that stopping and interrogating every individual on the street without probable cause is wrong, and more specifically, unconstitutional.

Do you think Bush's record was any better? JFK's? Roosevelt's? Obama is up there in experience with most presidents we've had.

Palin is not even in the same ballpark.

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.

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.

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.

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.

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.