Bungle Air is the latest to take unusual steps to tackle rising operating costs and the recession. Bungle Air has rolled out it’s new Air Use Fee which charges passengers for breathing on the aircraft. Passengers will be charged one cent per breath. A company spokesperson did clarify that the duration of the breath will not matter, thus encouraging passengers to take long breaths and holding it in for a while.

The number of breaths will be measured by an innovative device that looks like a face mask. A bright LED display shows the user their current charges. Passengers can purchase their own device for $100. The alternative is to rent one from the airline, a disinfected mask is available for a $10 charge and a community version is available for $5.

A company spokesperson highlighted all the innovative pricing models Bungle Air has rolled out in recent weeks. “We are very proud of keeping our advertised prices very low, thus providing customers with customizable low prices. Customers can choose their own breathing pattern to lower costs”, he said. Here are some other innovations Bungle Air has pioneered.

• Seat use fee – A Bungle Air ticket only promises transportation from point A to point B. Use of a seat requires a use fee of $20. A clean seat costs more, add a cleaning surcharge of $5.
• Bathroom use fee – Charges are calculated based on the time spent in the bathroom. A minimum 1 minute charge of $1 applies, 50 cents for each additional minute.
• Flight attendant fees – Any conversation with a flight attendant carries a $2 flat charge. Flight attendants can charge more if they deem it necessary. For example, “Orange juice please” is considered a normal request, “I would like orange juice and coffee with cream and sugar” qualifies for a surcharge. These surcharges are on top of the base cost of $5 for a drink and $8 for coffee.
• Emergency exit fees – In case of an emergency, the oxygen mask use fee is a flat $10. In addition, use of the emergency exits requires a fee of $10. Flight attendants have to collect the fees before they allow you to exit, exact change will be appreciated. Other passengers lives depend on exact change being available, fumbling around in one’s wallet may cost lives.

A Bungle Air flight from New York to LA will just cost $100 as long one does not breathe, keeps his or her mouth shut, does not eat or drink, is comfortable standing in the baggage compartment and carries no bags.

Twenty20 cricket is not really cricket, I propose renaming the sport Tricket. There are plenty of advantages to be had. Tricket is easier on the tongue than Twenty20 or even T20. Tricket fans will not have to join the staid and boring ranks of cricket fans. Fans of test cricket will not need to argue with addled tricket fans that tricket is not really cricket. Cricket players need not get confused about which format of the game they need to specialize in, they can just pick a new sport – Tricket.

Tricket will be free to change the rules of the game and not be bound by tradition. Tricket can add laser shows, music concerts, fireworks displays, roller coaster rides etc. to the mix. You can never be bored by a tricket match. Imagine a batsman hitting the ball, a fielder riding the roller coaster at that very moment, catches the ball just as the coaster hits a bend, the rock band hits a crescendo and the laser lights up the sky !

Given the crowded international cricket calendar, one of the formats is going to die. The current bet is on the one day format, it seems most likely to go extinct. But those are cricket’s problems, tricket on the other hand gets a fresh start, a brand new sport with a cool name and completely new calendar. Tricket fans need not wait for official cricket tours to go through time consuming test matches and one days.

Cricket has reached a fork in the road, too many formats, too many choices for players, fans and cricket boards alike. Fork tricket off as a new sport and may be cricket can be around longer.

Erlang is a functional language, something that worries a long time OO programmer, especially when said programmer is starting a new project in it. My background is predominantly in OO languages that Alan Kay did not have in mind when he coined the phrase OO. I have used Smalltalk in an academic environment, never commercially.

OO is amongst the more subtle concepts used in programming. Besides silly interview questions involving OO modelling of living rooms and bathrooms, attempting to apply OO concepts in real life commercial programming is harder. However, once indoctrinated in the OO ways as currently practiced in the industry, a language like Erlang can look pretty weird, there are no classes, no objects in the Java sense. How does one ever model the nouns as objects and the verbs as methods ?

Look up OO in a textbook and you will find words like encapsulation, polymorphism and inheritance thrown about. Of these, encapsulation is probably the single greatest contribution OO has made to the discipline of thinking about organizing a software system. After having used Erlang over the last few months, Alan Kay is right (it does appear that Turing award winners usually are) message passing is what I need to achieve encapsulation. Far more important than the use of a narrowly defined construct like a class or even an object, the way Java or C++ define them.

Message passing implies encapsulation, the entities passing messages to each other do not have any knowledge of the each other’s innards. Their only contract is the message. Each side must understand the other side’s message or fail gracefully. It so happens that message passing is at the core of Erlang.

Once you break the shackles of narrow definitions of what an object is, turns out that a far more powerful abstraction of an object as a component emerges. A component constructed internally of many modules (files in the most general sense), exposing a contract, a contract composed entirely of messages. I can not only build these easily in Erlang, I can take the notion of encapsulation one step further.

Erlang comes with a built-in database called Mnesia. Mnesia is a standard library and can store any Erlang data structure. I can now encapsulate even the persistent state/representation of my component (complete with transactions). The component (or application as it is called in Erlang) is a completely independent entity with all it’s external dependencies and the services it offers specified in message oriented contracts.

Unfortunately, the contracts themselves cannot be formally specified in a language construct. Erlang is dynamically typed and so are the messages. In addition, many of the messages can be passed asynchronously, a recipient can fail “silently” if it cannot grok the message. Loose coupling can be good and bad, I prefer to leverage the good and work to avoid the bad. Erlang is the closest I have ever come to reusing software components which are not stateless lumps of code in the form of a library.

Writing blog posts seems to require a certain emotional threshold to be crossed. No wonder micro-blogging is really popular, no real thresholds to cross there, visiting the restroom constitutes a post. Rank amateur bloggers like me have to expend quite a bit of effort in writing a post (even with posts that reflect the amateurishness), that effort requires some emotional energy. That emotional energy, I would argue seems to come more easily when a person is frustrated or angry. The next time you read a bunch of blog posts, try to gauge the emotion behind the post, count the number that you think were not fed by frustration or anger (anywhere in the spectrum from mildly peeved to a foul rant counts). In fact, some of the funniest posts are rants, nothing like an expletive to let off steam.

I have been working solo for the last few months using Erlang and Flex/Actionscript. The technologies I have been working with (especially Erlang) have been an absolute pleasure. Flex tends to be big and bulky, with APIs running amok, lots of choices to do the same thing, but somehow it all hangs together very nicely.

So, why this post ? Well, some of my old frustrations came to the fore when I saw this new language fan. More specifically, when I read a few lines describing the features in the language – REST oriented transactional memory. Reading further, I came across this line – Resources may be mounted into a common Uri namespace as a “shared whiteboard”.

What does this have to do with my frustration ? In one of my projects in the past, I proposed this very same idea and met with the most unreasonable resistance I have ever come across. Resistance that would have required plenty of machiavellian tact to overcome, something I did not have the inclination for at the time.

This is what is so great about open source, a movement I feel guilty for not having participated in so far. I hope to remedy that in the future. I hope Fan succeeds, they have some very good ideas (including message passing concurrency based on Erlang). Even if Fan does not succeed, I hope ideas like REST oriented transactional memory have a shot at gaining acceptance. I am now emotionally vested in seeing this idea survive, may it live long and prosper.

Software reuse is one of the most fascinating topics there is. A source of many myths and the basis of many project management blunders. I came across this brilliant article by Peter Naur. The article touches on so many points near and dear to my heart. From the industrial era project management techniques used in software to why teams consisting of smart programmers will frequently produce unusable junk and become miserable in the process. More on those topics in subsequent posts.

Programming as theory building is also a big reason a lot of software is not as reusable. The original programmer’s theory building exercise in the context of the problem domain has to be applicable to the problem you are solving. If you either do not understand that theory or even if you do not agree with that theory, it is far wiser to not reuse the code. The love/hate posts on Ruby On Rails I have seen on the net are a good example of this effect at work. Folks who agree with the original theory find the framework amazingly productive. Folks who either don’t get it or don’t agree with it, find it useless and will refuse to reuse the framework. Personalizing the theory behind Ruby On Rails, modifying it to suit one’s world view has resulted in so many other frameworks being created.

Another fascinating book that touches upon this topic of reuse (albeit in a slightly roundabout fashion) is The User Illusion. The book goes into a deep discussion on the nature of information, a discussion that then supports the author’s theory of the brain. One point that stuck me while reading the book relates to software reuse that Peter brings up in his article. Documentation does not really help in reusing software.

The amount of information that programmers discard before writing a line of code is actually far more important than the line of code that gets written. In fact, the complexity of a program is more a result of the amount of information discarded than the amount of information that gets encoded in the program text. No amount of documentation can make up for the information that is in the programmer’s head when the code was written. Without that information, the code is useless. Unless, you face the exact same problem and the code maps well into your context.

The exceptions are the gems, libraries that help you without imposing their theory on your code. Ironically, artifacts like EJBs which were built with reuse in mind, failed miserably at that task. The theory behind EJBs met with violent disagreement, theory building is fine, imposing that theory on everyone is and always will be risky business.

The next time you are wondering why that other programmer’s code looks like crap, it could be because the code is truly crap or maybe you just do not understand the underlying theory of the program or maybe you sub-consciously do not agree with it. It might be that the original programmer discarded way too much information that is relevant to you or you have clue no why they discarded the information. In all these cases, the best course of action is to just re-write the code. Now, if you find yourself wanting to re-write something as complex as Windows, reusing Mac OS X or Linux might be easier.

The first challenge – build a web site that can handle the load.

I got a really creepy piece of mail today. What looks like a newspaper clipping arrives in a white envelope, my address hand written with a blue ball point pen. There is no return address on the envelope and is postmarked with a Research Triangle Region post office stamp. The newspaper clipping has a hand written Post-It note attached to it. The notes says ‘Sai, you gotta see this, J’

The Post-It note is on top of an article about someone who helps folks with sub-prime mortgages.

Frantic google searching followed. It appears that this is the latest method for delivering spam. Found blog posts that talk about this scam, like this one here.

Time sure flies fast, my blog is now a year old. It has been an interesting experience. Blogging can be easy one day and really hard on another day. I am still not sure what I should or shouldn’t blog about. Take today for instance, I can either blog about how to get the Eclipse plugin for vi to work properly in Flex Builder or profound truths about how not to do things. Given a crowded blogosphere, chockful of opinions, some days I feel like I probably should not even bother writing a blog. On the other hand, blogging is pretty therapeutic, just getting my opinions out of the system helps me.

One thing that I can blog about is a transition, I no longer work for IBM. It was a tough decision, I worked there for 8 years with lots of great folks. I will be working for a startup on some exciting new stuff. It was an opportunity I could not pass up. Let us see how this experiment works out.

Patrick’s post on AppJet and my comment on their ability to make money made me dig up this old draft. Every software project you work on, whether it is in a startup or in a big company will eventually get asked the question – how will this make money ? Having thought about this question a bit, I think a much better question is – who will find this useful ? A subtle difference, one might argue, but I think it makes a big difference in how you design a solution.

The “making money” part has to be a side-effect of “build something useful”, so in that sense AppJet is on the right track. Promote money making to be the primary consideration and you will either end up in building a strong sales operation or a bad product (sometimes both). Selling is important and often a difficult task (one which programmers have very little appreciation for). However, it cannot be the foremost concern for a software project in it’s infancy.

If on the other hand you decide to build something useful, you will always focus on delivering something useful to a customer. Once you have succeeded at that, money is more likely to follow. More likely, not guaranteed. Google struck gold by building an excellent search engine, the ad revenue followed. That does not however mean much to all the other startups out there.

Finding a good answer to who will find this useful will contain clues on whether it will make money. The problem is, most of the time, programmers focus on tools other programmers will use. AppJet is an example. In my opinion, this is usually indication of something that will not make a whole lot of money. Examples include, the next big programming language, a compiler for the next programming language, the next big web framework, a framework for building frameworks, tools frameworks that build frameworks and other recursive framework related projects. These projects are ideally suited for open source and if successful, will end up in services and support based revenue streams at best.

Maybe AppJet will succeed with a lean, mean utility-like hosting model, differentiating itself from all the other hosting providers with a novel app development platform or maybe as Patrick pointed out, this is all just a big bubble.

I came across Nick Carr’s offer to get an advance copy of his forthcoming book The Big Switch on his blog. The premise of the book is a very interesting topic for me, I work on enterprise software and there are big changes coming in this space. To get an advance copy I had to be amongst the first 150 folks to send an email to the publisher. The book showed up last week in the mail. Very innovative way to get some buzz going, although my blog is probably at the tail end of the long tail. My part of the bargain is to blog about the book, so here goes.

The book makes for an engaging read when drawing parallels between the electric utility business at the turn of the nineteenth century and the IT industry today. The book also does well as a survey of the different approaches being used by companies to supply software and hardware as a service. Nick builds up to the notion of a World Wide Computer and it all flows nicely. The author then tries to tackle some very complex and thorny topics and they prove to be overwhelming. Topics like the economic and social impact the World Wide Computer will require a lot more pages and a much deeper analysis than the book provides.

The book tries to maintain a neutral tone and succeeds when describing the past and the present. Nick’s predictions on the other hand, tend to be of the doom and gloom sort. Nick does not believe in the when a job is lost in one place, two more get created elsewhere theory. He believes that the World Wide Computer will cause far bigger economic upheavals and jobs will stay lost, millions of them. Disturbing stuff, that I don’t really want to believe in (maybe I should). The IT industry is going to expect and extract enormous efficiencies from hardware and software, folks are going lose jobs in large numbers as these efficiencies kick in.

The best example the author has is this site here. Apparently, this entire site is operated by a single guy who rakes in 10,000 dollars a day at times. The entire revenue stream is based on ads. Examples like YouTube and Craigslist are also cited, very successful sites based on very few employees. These companies highlight the highly skewed distribution of wealth that will occur. 60 employees of YouTube make 1.6 billion, all the suckers who put their content on there get a thank you note.

If these examples suggest a macro-trend then all this is indeed bad news. Good old large corporations sound benevolent by comparison. But, I am not convinced that this is a macro trend. I had read
another book on economics the week before last. This book had a whole chapter
on economic incentives and how they govern our behavior. The suckers who put their
content on YouTube don’t have much to lose right now, at some point they lose the incentive to participate and things are going to work out differently. These community based valuations seem suspicious anyway. EBay seems to be finding out that buying communities like Skype is not a viable business model in the long run.

People will not participate if there are no economic incentives. Open source programmers write code for free because there is someone paying them, maybe not for the open source code, but for something they do for an employer. Take away that job and there will be no free open source code anymore.

In the end I wish the author had not diversified as much and focused on a few topics in greater depth. Should you buy the book ? Sure, buy it. It will get you started on thinking about the future of IT.