Categories: Top ::

Mobiles: Where do you draw the line?
Mon, 06 Feb 2006

Another way too long unorganized thought stream.

The question I pose here is not unique to any particular branch of software development, or even in truth to development .. it is a fundamental question to all producers be they of software or frisbies. The question is - when developing and refining a product, how far is far enough? How much shine to apply to your shoes? In the case of software, where do you place version 1, version 1.1, and version 2, 3, and 8?

With regards to software, some projects just meander along their own path for years with no well-defined gates or milestones - never truly done. These projects are always in a permanent state of 'done enough' or 'not done.' Others, such as an operating system release, will draw lines and say "this here is version 1.7.3.5", based on premeditated goals - or perhaps simply on the principle of its been in the oven long enough, it must be done. The harder method of operation is to set milestones in advance - and stick to them.

I'd say progress (in the general sense) is easy.. but meaninfgul progress towards a milestone along some sort of ramp, that can be challenging. Imagine using a compass in a dark forest -- you know you have to get to point "Z" but simply cannot walk a straight line towards it - a ravine may lie in your path, or a dense copse of trees, or a firebreathing garden gnome. The right path will forever twist and meander as you pick your way until eventually reaching the goal. The trick in software, the one so many people will forget, is that the goal should not be "product with XX feature list" but instead should be "good product", where that is further defined with attributes such as "meets user goal of such and such" and "it cost us money, better make some back." These goals too can be further broken down of course, but walking through the forst you want to end up at "good product," a target that may have changed while you were lost.

Anyone who has used my software will appreciate my approach (not that I coined it, but that I do live it) -- release early and release often, making clear the expectations. ie: An early release from will be clearly marked as to risks and benefits and come attached with a requirement for a reply.. a response explaining the users position. If you want to get in early, I make it all available and on the table and expect the user to tell me if they lvoe it or hate it and why. I get feedback, and the user gets what he needs or wants right up front.. everyones happy and everyone is excited. Some people just like a minefield and want to jump in right up front, and some just want to get a feature early so they can get to work - knowing that I generaly don't make minefields or will at least let them know if they should expect one. Others still just want the later more pollished release -- let others walk through the forest at night. These are all good, and certainly most should fall into the regular user mode.. the last there. But we do need those brave alpha testers who like to live dangerous!

I digress, but the reason I like to release early and often is because it lets you manage the Z point better -- if you work away in isolation for a year on something, then your Z-point - your end point - may be the wrong one. While you worked towards Kansas the goal may have moved to Vancouver and you just don't know. Instead of working away in private I try to keep my head up and the project in the open - let people complain and bitch and be overjoyed the whole way, so as you navigate with your compass you're always working towards the right endpoint. Naturally with this model of operation you invest much more time in communications and in management of the information -- the sheer volume of response has to be handled, and extremists especially so. The cost is high, but the benefit can be enormous -- a better end product, and a decent little community raised around it. Cool stuff.

Anyway, I mention all this because I thought some of you might be interested in this problem of setting appropriate milestones; generally, they must be laid, otherwise you might toil away not being aware of time wasted, or spending too much time on any one thing and ultimately not moving at all without ever realizing it. I call it developer quicksand though others might say 'spinning your wheels' or 'walking in circles' -- Progress is made, just not anywhere useful.

All producers work through this.. iteratively so as well; while making a movie, I'm sure they weigh the cost advantage of one style of film over another, and one style of lighting over another, and so on. And how much post production computer-graphics to add, to what detail level? In a dark scene I'm sure they do less refining on some artwork than in others. Many thousands of little choices about quality and where to draw lines along the way, with a guiding vision describing how to determine where these lines go.

I'm working through the process now, of setting milestones and working out what the expectations for delivery are; I've got a well established product and brand in the Palm OS martketplace, and dare say a good community since I spend much more time than I should hanging out with folks. (Its not all business to me folks, which is why I help out so much, and charge so little.) But for Pocket PC the Codejedi brand is still week; I've done a few things there and I'm sure a lot of folks are aware of us due to being Palm OS converts or having envied the software from their vantage point, but assuredly most have no idea. So we have to impress when we make a splash in that pond. The question is -- this whole blog entry is -- how far do we have to go? How far do we have to go to impress? Or how near to go for those that just want it simple.. our core audience?

Most Pocket PC (Windows Mobile, whatever its called this year :) applications aren't really attractive, while others (especially in the Today screen category) are very nicely crafted; simple or complex, a really good presentation is important.. and some candy can't hurt. (Too much candy can certainly be a problem, but thats rarely occuring in the handheld space where resource limits always make us keep things simple.) So do we splash early and release often as is my norm, starting with a simple more cut down application.. and risk competition or regular joes writing us off forever as a simple app? Or do we hide away in private and pop out something later that is more refined and attractive, hoping its what folks on that platform want? (Another aspect non-developers don't think about is that when you release early and often, you're also asking for money earlier than otherwise. This means you have to treat everyone as gravy, and had better price accordingly or you deserve the Big Flamage. Certainly after investing a significant amount of time and resources into development you could use bucks earlier than later..)

As typical with any blog entry, I will do the easy part.. pose the question, without filling in the answer. Suffice to say that I still believe in going simple - for our products its always been canon -- simple, useful, efficient and lean. So simplicity is not only a release early item, its part of the core atraction and what makes our software desirable. We leave the big ugly complex stuff to Microsoft so they can try and support the mess. How pretty to make the buttons, I'll worry about later, because we're all about function here. But the time to decide will come soon enough..

Start small and managable with a big vision I say.

[ Category: / technology / mobile ] [link] [Comments]