Fishpool

To content | To menu | To search

Tag - software

Entries feed - Comments feed

Thursday 13 October 2011

Where the chips fall - platform dominator for 2012

By Osma on Thursday 13 October 2011, 13:50

It's been about a year since I put my prognosis skills on the line and tried to predict where technology and consumer products are heading. Since today is National Fail Day in Finland, perhaps it's time to try again. Lets see how right or wrong I end up being.

Last year I noted a couple of things about mobile platforms and of the software environments best suited for creating apps on them. While this year has seen a lot of development on those fronts, little of it has been in surprising directions. HTML5 is coming, but not here yet. If WebGL and Intel's River Trail project were supported by the Big Three (IE, Firefox and WebKit, ie Safari/Chrome), that'd make an amazing game platform - but at least the latter is research-only at this point, and IE9 isn't going to support either. In the meantime, Adobe finished Flash 11, which now has hardware-accelerated 3D in addition to a pretty good software runtime, and, after only 10 days out, already has 42% reach for consumer browsers (at least judging by stats on habbo.com). Like I've said a long time, Flash gets a lot of undeserved crap due to the adware content created on it. We won't get rid of that by changing tech, and platforms should be judged by their capabilities in the hands of good developers, not by mediocrity. And, as far as mobile goes, the trend continues -- iPhone and Android battle it out, now also in courts as well as in consumer markets, while everything else falls under the wagon. If you're creating an app -- do it either with a cross-platform native toolchain, or with HTML5. If you're doing a game, do it with Unity or Flash, and build a native app out of it for mobile.

The interesting thing, to me, is playing out on the Internet. Google+ came out as a very nice product with well-balanced feature set, but (fairly predicably, though I was rooting for it) failed to catch the early adopter fancy for long enough to displace Facebook in any niche. Facebook, on the other hand, scared (or is going to scare) 40% of their audience by announcing Timeline (eek, privacy invasion!). Brilliant move -- you can't succeed today without taking such leaps that nearly half of your audience will be opposed to them, at least initially. Smaller changes simply aren't meaningful enough.

So, I'm betting on Facebook. I'd also guess that once they get Facebook Credits working outside of the Canvas, they're going to demand that any app using Facebook Connect log-ins will accept Credits for payment. I'd hazard a guess they're even going to demand FB Credits exclusivity. They'll fail the latter demand, but that won't stop them from trying it. Having your app's/game's social publishing automatically done by Facebook simply by feeding them events, and not having to think about which ones are useful to publish, is just such a big time saver for a developer, no one will want to miss out on it.

Not even Zynga. They're doing this destination-site, we're-not-gonna-play-inside-Facebook-anymore strategy, but continue to use Facebook Connect for log-ins. That's not because FB Connect is so much more convenient than own username and password (though it is), but because even they can't afford to let go of the "free" access to people's social network. That's the power of Timeline and the new, extended Graph API.

The chips are still in the air. When they fall, I think Facebook will be stronger than ever, but strong enough to displace the "rest of the Internet"? No. As a developer, I want to push Facebook the data for in-game activities, because that saves me time doing the same thing myself. As a publisher, I'm unsure I want Facebook to have all that info, exploiting them for their purposes, risking my own ability to run a business. As a consumer, it makes me uneasy that they have all that info about me, and while I can access and control quite a lot of it, I can't know what they're using it for. I don't think that unease will be enough to stop me or most other consumers from feeding them even more data of our lives, likes and activities. Still, they're only successful doing this as long as they don't try to become a gatekeeper to the net - nor do they need to do that, since they get the data they want without exerting control over my behavior. Trying to fight against that trend is going to be a losing strategy for most of us - possibly even for Google. Apple and Microsoft won't need to fight it, because they're happy enough, for now at least, to simply work with Facebook.

Tuesday 21 June 2011

On software and design, vocabularies and processes

By Osma on Tuesday 21 June 2011, 08:55

Having recently witnessed the powerful effect establishing a robust vocabulary has on the process of design, and seeing today the announcement of the oft-delayed Nokia N9 finally hit TechMeme front page, I again thought about the common misconceptions of creating software products. It's been a while since I posted anything here, and this is as good a time as any to do a basics refresher.

A typical axis of argument sets software engineering somewhere between manufacturing and design. I, among many others, have for years argued that the relationship of software to physical manufacturing almost non-existent. This is because while the development process for a new physical product, like any involving new creation, starts with a design phase, the creation of a specification (typically in the hundreds of pages) is where the manufacturing really only begins. The job of the spec is to outline how to make the fully-designed product in volume. In comparison, by the time a software product is fully-designed and ready to start volume production, there is no work left - computers can copy the final bits forever without a spec. There's more to that argument, but that's the short version. Creating software is the design part of a product development process.

So, goes the line of thinking, if software is design, then it must be right to always begin a software project from zero. After all, all designs start from a blank sheet of paper, right? At least, all visual designs do... No good comes from drawing on top of something else.

If this truly was the case, what do you think they teach in art schools, architecture departments, and so on? Technique? For sure, but if that was all there was, we'd still be in the artesan phase of creation. History? Yes, but not only that. An important part of the history and theory of design is establishing lineage, schools of thought, and vocabularies which can serve as a reference for things to come. All truly new, truly great things build on prior art, and not just on the surface, but by having been deeply affected by the learning collected while creating all which came before them.

Not having actually studied art, I have only a vague idea of how complex these vocabularies are, and this is an area where a Google search isn't going to be helpful, as it only brings up the glossaries of a few dozen to at most a hundred basic terms of any design profession. This is not even the beginning for a real vocabulary, since those describe to a great detail the relationships of the concepts, ways of using them together, examples of prior use, and so on. However, even from this rather precarious position, I will hazard a statement which might offend some:

Software design, in terms of the vocabulary required for state of the art, is more complex than any other field of design by an order of magnitude or more. The practical implication of this is that no new software of value can be created from a "blank sheet of paper".

This will require some explanation. Let's tackle that magnitude thing first.

Any complete software system, such as that running within the smart phone in your pocket, measures in the tens, if not hundreds of millions of lines of code. LOC is not a great measurement of software complexity, but there you have it. In terms of other, more vocabulary related measurements, the same system will consist of hundreds of thousands of classes, function points, API calls, or other externally-referable items. Their relationships and dependencies to each other typically grow super-linearly, or faster than the total number of items.

By comparison, the most complex designs in any other field are dwarfed. Yes, a modern fighter jet may have design specs of hundreds of thousands of pages, and individual parts where the specs for the part only are as complex as any you've seen. Yes, a cruise ship, when accounting for all the mechanical, logistic and customer facing functions together may be of similar complexity. And yes, a skyscraper design blueprints are of immense complexity, where no one person really can understand all of it. However, a huge part of these specs, too, is software! Counting software out of those designs, a completely different picture emerges.

None of these designs would be possible without reusing prior work, components, designs, mechanisms and customs created for their predecessors. Such is the case for software, too. The components of software design are the immense collections of libraries and subsystems already tested in the field by other software products. Why, then, do we so often approach software product development as if we could start from scratch?

Why was it that the N9 reminded me of this? Well, if stories and personal experiences are to be trusted, it seems that during the process of creating it, Nokia appears to have "started over" at least two or three times. And that just during the creation of one product.. As a result, it's completely different, both from a user as well as a developer standpoint to the four devices which preceded it in the same product line, and two (three?) years late from it original schedule. Of course, they did not scratch everything every time, otherwise it would never have finished at all. But this, and Nokia's recent history, should serve as a powerful lesson to us all: ignoring what has already been created, building from a blank sheet instead, is a recipe for delay and financial disaster.

Software is design. Design needs robust vocabulary and the processes to use them well, if it is to create something successful.