Friday, June 11, 2010

Another report from the Bureau of Meaningless Statistics

"80% of all statistics are meaningless. 73% of all statistics are made up." -- Anonymous

The F2P area really abounds in meaningless statistics. This months choice example comes from the president and cheif flogger for Live Gamer via The Edge online:

""We're seeing average revenue per paying user top $28 per month across the 145 titles that Live Gamer powers around the world."

Sounds impressive doesn't it? But what exactly does "average revenue per paying user" mean? The answer is, by itself, absolutely nothing. A game with 10 million users where only one spent anything, and he spent $100, would have an "average revenue per paying user" of $100!!

Is that a game to invest in?

I often quote Mark Twain at moments like these:
"There are 3 kinds of lies. Lies, damn lies, and statistics."

The iWeasel

Well, Apple continues to insert more and more weasel wording into their iPhone developer's agreement. Their latest loop hole to allow them to selectively enforce their rules was added at WWDC to section 3.3.2, the prohibition against interpreted code:

"Notwithstanding the foregoing, with Apple’s prior written consent, an Application may use embedded interpreted code in a limited way if such use is solely for providing minor features or functionality that are consistent with the intended and advertised purpose of the Application."

IMHO this latest change was specifically to allow Unity based games, without which they would lose most of their best game content.

The agreement is passing from insulting to outright laughable as Apple squirms and twists to do what they want to without violating their own rules and creating potential legal issues for themselves.

I think the time has come for Apple to issue a "plain language" agreement. I offer the below as my suggestion:

Apple iPhone Developer Agreement Mark 2:

Section 1.1: Restrictions

No application or development tool is allowed that, in our opinion, in anyway competes with our economic interests. These interests include but are not limited to direct sales, ad revenue and total control over any hardware or software running on or attached to our product.

See? I just saved Apple hours of legal fees ;)

Thursday, June 10, 2010

Apple trying to force Google out of the iPhone ad business

Here's an interesting development in the on going saga of Apple's overly restrictive developer policies...

To my mind Apple is flirting dangerously with "restraint of trade" with all these new, very targeted developer restrictions. And Google has the bucks to give Apple a real good fight in court. Especially if, as I suspect is coming, the government gets involved on a federal level.

Edit: My suspicion seems confirmed...

Everyone remember this ad?

Who knew that the big face on the screen was, in fact, Steve Jobs?

Thursday, June 3, 2010

Dear Steve, (an open letter to Apples CEO)

I love my iPad. Its a wonderful bit of kit. The hardware is top notch and the software smooth and elegant.

I've been a software developer for more then 30 years. I already have an Android app on the market. I will not, however, be developing anything for my iPad. And the reason is your latest restrictive developer rules.

Its is unfathomable to me that you, as the platform maker, feel you have the right to restrict what tools I can use to develop my application. No platform maker has ever demanded such of their developers.

This is like your Chinese assembly plant dictating to you what trucks you could use to carry the resulting product or how you could sell them. Manufacturing is their business, sales is yours.

And software development is *ours.*

Even Microsoft, when they decided they wanted to own the PC compiler market, did it by devious competition and not through direct arm-twisting of their developers. They understood how much they needed their developers. Do you?

This is a dangerous time to be playing such games. Android use is on the rapid rise in cell phones, far out-pacing current iPhone sales and Android pads are about to break into the market. All it will take is one that feels as comfortable to me as my iPad and you will have lost not just a developer but a customer.

Regardless of whether I keep my ipad as a consumer or not however, one thing is certain. Until you retract your ill-considered language and tool mandate, the only way I will be personally developing iPad software is if the iPad version happens to come free as a by product of a tool I am using to reach another market.

And given the fact that your position is now to reject applications created by such tools, this isn't very likely.

Tuesday, June 1, 2010

Objects Considered Harmful


Its time for a programming vent.

As many of you know, I wrote the "Early Access" version of what would become the Project Darkstar server. When that project transferred to its eventual team in labs, the team there spent well over a year debating and re-creating what I had already created. As I watched this I comforted myself with the belief that this team of specialists would produce a better result each in their own area then I had the time or ability to do, doing it all.

Well, I am now deep in the client/server transport and protocol sections of the code right now... and I have never seen a more overly complex, totally obfuscated mess in my life.

The thing about protocol stacks is, they map beautifully to a simple, proper, structured coding approach. What we used to call top-down design/bottom up implementation. Each layer of the protocol is a layer of structured code with a well defined interface, calling the level below it. PDS (now RedDwarf) has two layers of fundamental abstraction-- a transport that moves packets around and a protocol that interprets them. To be fair and give credit where credit was due, that idea was implicit in my original implementation and the author of the re-write did pull that out as an explicit organization principle and observe that there should be a plug-in interface for each.

That, however, is where my praise of this code ends.. It is an unholy mess of calls and callbacks on passed objects running up and down the stack in higgeldy-piggeldy fashion to the point where so much of the logic is spread out in so many places the total execution is virtually untraceable.

This is not the first time I've seen this in code in recent years. I think the culprits are primarily University professors and CS programs who are so in love with concepts of "Object Oriented" programming that they are failing to teach the basics, which still come down to data structures, interfaces and layers of code. Those of us who WERE taught such concepts recognize an "object" as just a convenient packaging of data structure + interface and continue to write clean, clear encapsulated code.

But it seems the kids these days don't have those clear organizing principles in their heads. As a result they write their code as a whirling cloud of disorganized interacting objects. This chaotic swirl is virtually impossible to statically trace on paper as we had to, instead they count on debuggers to show them run-time behavior and praying that what they saw in this limited sample really represents most if not all possible interactions.

I think its time for a harsh remedy. I am calling for teachers of coding everywhere to rip those
Java and C++ books out of your students hands. Give them C, or if your nice, Pascal, to learn their basics on. Teach them what data structures are and how to do top-down design/bottom up implementation. Take away their debuggers and make them debug with trace calls.

When they can do that with aplomb, they are ready for the objects. But when you put power tools in the hands of someone who has never used a saw or screw-driver, you get messy accidents. And thats what were getting in code today.

Or to paraphrase a common witticism I never agreed with anyway as a statement I CAN agree with...
"There is no problem in Computer science that cannot be totally obfuscated by the addition of too many levels of abstraction."