Ah, just another insight into the wonderful word of management theory. I wonder if the esteemed people who concern themselves with the knowledge of what it takes to run a successful company will ever just admit to themselves that perhaps this about as useful as trying to understand a winning strategy of casino slots?

I don't know - I listened to Jane's TED talk and in spite of totally liking the idea, I just don't think her argument is very sound. Take her calculation of 21 billions hours a week - she came upon that number by simply extrapolating it from some historical account, where people in a society (I think it was some ancient Greek region) were asked to play games in order to keep their minds of the fact that they don't have food. Multiply the amount of hours spent by ancient starving Greek with today's population size - bam! 21 billion hours per week!

Is this like an American August 2nd, or a rest-of-the-world 8 February?

And no, I did not RTFA. Worried that the FBI would be tracking everybody who is even interested in this news.

Well, if an idiot ignores his oil light and ends up stranded on the highway, that is generally his problem. If an idiot allows a bot to run on his server, that becomes everybody's problem.

I don't know. Reading the article, all I'm thinking is: how many ways can Jimmy find to fuck up his code now? At least with Groovy and Scala, these language features were pretty much limited to programmers who knew what they were doing. With Java, it's a bit like giving everybody in the world a glock and expecting everything to get better.

That seems like question begging. The popularity of a technology defines its success, not the other way around.

Anyone who expects predictability and tractability from what is fundamentally an uncertain project is going to be unhappy. But that is the sort of unhappiness that you can't really do much about.

Maybe its art then?

But seriously, who cares? How does the word we use to describe the thing change the concept of it?

You fail to understand your own logic. If there was no money coming into the system, there would be no money to pay the players with.

Economics 101.

Maybe that statement is generally true (although I do wonder why you consider academia to be the adjudicators of what is important), but we are not talking about an essential food resource here. We can feed the world without killing whales.

This hugely contradicts my experience. Although it may be possible to write specs that are so good, so coherent and incorporate so many edge case that any code realizing it *must* be bug-free, I have never seen it happen for any modestly complicated software project.

Software development is a continuous process (like gardening). If you are worried about bugs, then you must be pro-active about it. Tools like Sonar can give you valuable information about which parts of the code base are under-tested, overly complicated and require careful attention. Also, testing is a multi-level discipline - you can't get away with *only* unit testing, or *only* integration testing. If you want your code to be bug free, you need to invest a lot of time and effort in automating your different test strategies.

There is no guaranteed, affordable process for having bug-free code. You *will* end up with bugs, without requiring this to be attributable to someone's incompetence. You need to actively manage this.

Go on, early adopters, pay to prove me wrong.

If your counter argument is "nanny nanny boo boo", then aren't you rather confirming OP's point that this is a game of ideological mud slinging?

They've actually got on top of much of the core stuff in the past few years. Which is why it's astonishing that they went so nuts with "Window" 8.

Remember when Gates BSOD'd Win98 at a presentation? And laughed, because he know that people would still queue up to buy it.