Here’s a thought I’ve been meaning to write about for a while. Why don’t we have location-aware operating systems yet? I want my laptop to know when I’m home, when I’m at the office or when I’m traveling - and I want it to give me relevant information and perform tasks based on my geographical location.

One can argue you can already mimic some of the functionality I’m talking about using existing tools (virtual desktops, multiple user accounts, etc.), but now that the physical technology to actually develop something like this is readily available - using GPS to figure out where you are and programming associated behaviors into the system -, why isn’t anyone working on it?

Imagine the experience

You are at work, doing your documents, reading your email and RSS feeds. Work time is over and you close the lid on your laptop to pack it home. You get home, open the laptop lid again. The laptop realizes it is in a different geographical location, recognizes it as “home” (through GPS, RFID on your home desk or even though your wireless connection) and switches the running application environment. It automatically starts itunes, downloads your music and streams the news (it gives you “home stuff”).

One machine, several environments. With a system such as this, we wouldn’t need the concept of a home PC or a work PC. Any machine would work on any environment, because it would adapt to it, and we’d always feel comfortable with it.

Getting hands dirty

Implementing such a system isn’t hard. It may not be at the grasp of a single developer down at one basement (because it is a complex system), but it sure is at reach for a team of people willing to make peoples’ lives with computers a little easier. And since none of the big players (Apple of Microsoft) are tackling this issue, why not get the ball rolling as an open source initiative?

I was just skimming through the blogosphere on the Google “Office” (which is nothing more than a control-panel served Mail, Talk, Calendar and Page creator) and came across this comment on Techcrunch:

People hardly care about collaboration in the corporate world. The term collaboration is overhyped. If I am preparing a technical design document along with couple of coworkers (say Mark and John), there is no need for collaboration. I contribute to section #1, John contributes to section #2, Mark contributes to section #3 and in the end we merge the documents i.e. cut and paste. I dont want John and Mark to see all the changes as I type , I only want them to see my version only after I finish it completely. I hate collaboration.

Reading this was rather strange for a couple of reasons: one, I wholeheartedly disagree (I believe collaboration and collaboration software make better, more productive professionals), and two, because it doesn’t reflect my view of the “corporate world”. Odd.

Peter Van Dijck nails it in 2 sentences:

At DEMO, they’re charging US$ 15,000 to do a demo (…). In other words, DEMO is only for VC companies, not web 2.0 companies (who are supposed to do without VC cash, right?).

DEMO’s not the only case of conferences where you need to pay to play, but if the whole thing is about the companies and products, shouldn’t money flow the other way around - or just not between conference and speakers?

Without companies, there would be no conference. Maybe I’m seeing things from the wrong perspective here, but I’d much rather go to an event where companies were invited for their merits instead of the money they can cash out in order to tell me how great they are.

One of the most important parts of building an application is actually just that - building the application. It follows that particular attention should be given to the process of planning and elaboration of a timeline. Many projects take longer than expected to complete, with never-ending iteratings and constant adding of new features. Ever wondered why that happens? Keep reading.

From an idea to development

You have a great idea, you want to make it into an application. You have a stable picture in your mind of what you want the application to accomplish. You gather a team to build it. You try your best to make sure the picture you have in your mind is passed on to everyone else on the team. You fail, problems ensue.

The planning stage in a development process is constantly overlooked. People assume (particularly in a start-up, loose environment) that planning is unnecessary, a waste of time or (and this is extremely frequent) something that can always be interleaved with development. Truth is, this sort of behavior leeds to the developer’s worst enemy: scope creep.

Defining scope creep

Here’s Wikipedia’s definition of scope creep, as of this writing:

Scope Creep (also called “requirement creep”) in project management refers to uncontrolled changes in a project’s scope. This phenomenon can occur when the scope of a project is not properly defined, documented, and controlled.

Typically, the scope increase consists of either new products or new features of already approved products. Hence, the project team drifts away from its original purpose. Because of one’s tendency focus on only one dimension of a project, scope creep can also result in a project team overrunning its original budget and schedule. As the scope of a project grows, more tasks must be completed at the same cost and in the same time frame as the original series of project tasks.

Fighting the bastard

Fighting scope creep is quite simple, really. Plan, plan, and plan. Make sure you (or your team) and the client know what the intended purpose of the web application is, and that you agree on it - to the finest of detail. Make sure your vision and the client’s vision is one and the same, not the intersection of one-another.

Remember that a project must be built in close connection and discussion with a client, whoever it may be. In fact, even if you’re doing something for yourself, make sure you don’t ask yourself about new features. You’re not experiencing a multiple personality disorder: it is innate for humans to wonder about the “what if’s” of development all the time. “What if I could add this super cool feature?” - Say no, even to yourself, if saying yes will be walking away from the vision.

Putting it together

In sum, scope creep delays projects, messes project budgets, diminuishes developer productivity and ruins client satisfaction. Fighting it is simple - it requires planning, prior to writing the first line of code, to make sure the vision of the application is the same for client and implementor. Agree on the features beforehand, and aim for the same goals. Do it right, and it wont bite you in the butt.

Remember to say no, keep your vision in focus and don’t allow it to blur with “what if’s”. You’ll build better, tighter applications - and you’ll be happier doing it.