Arsalan Zaidi's Blog

Turkey Stuffing

2008-06-15T21:55:00.002+05:30

As part of the team selection for a certain business function, I was given 60 minutes and a clean slate to express my creativity. With only 45 minutes to go for the bus to leave, I was a bit pressed for time. The fact that I didn't care if I was selected in any case may have had some effect on the final product.

So without further ado, I give you:

"Turkey Stuffing, or How I learned to stop worrying and love economy class"

With oil prices shooting through the roof, airlines are looking at further innovative ways to inconvenience their customers and perhaps cut costs. Having reluctantly ruled out pay per kilogram ticket schemes (Pounds for your pounds!) and having been told off for attempting to recycle seat stuffing as in flight meals, they’ve settled on trying to limit baggage allowances to the bare minimum. You’re now only allowed a total of 20 kgs for checked in luggage and some airlines are thinking of limiting you to just one bag. Since you know your company’s never going to shell out for business class, here’s a short guide to stuffing as much as possible into one travel bag and still being able to latch the damn thing.

Now the first thing to keep in mind is that not only do we have only one bag to put everything we need in, we’re limited by weight as well. So the first priority is to figure what you absolutely need and what you can do without. The first thing to go should be the toiletries. There’s no sense carrying around deodorant, toothpaste or anything else even remotely connected with hygiene. Your body odour hardly bothers you, so there’s no need to waste precious space on perfume when you can stuff in your Nintendo Wii instead. Don’t worry about your overseas colleagues; they’ll chalk up your reek to cultural differences when they finally regain consciousness.

Toss out your underwear too and only carry a single white shirt and a single pair of dark trousers. No one will be able to tell you haven’t changed or that you have nothing to change into. The same goes for your socks, handkerchiefs and every other article of clothing. A quick shower with everything on will suffice for laundry and a short lie down with ‘iron’ everything out quite well. All this leaves more space for the things that matter, like the gazillion adapters you need to keep your gadgets charged up.

Wrap all your clothes into one tight bundle and use the socks to lash it all together. Press down on the lump several times to force out all the air and you’re good to go. All the essentials now occupy a tiny portion of the bag, leaving you free to carry several kilos of samosas, pakodas or any other savories that you absolutely cannot do without.

In the final step, slam the lid down forcefully and press down firmly with your elbows locked. The hinges may protest a bit, but now is not the time for mercy. Holding down the lid with out hand, slam the latches shut and lock firmly.

That’s it, you’re all set. Be sure to read next times newsletter for details on how to further push your ‘baggage allowance’ by ingesting bits of your kit. All will be revealed (or rather concealed)!

The Eye of Sauron

2008-06-15T14:36:00.004+05:30

Oxford Street, London (looking towards the North)

"The Eye was rimmed with fire, but was itself glazed, yellow as a cat's, watchful and intent, and the black slit of its pupil opened on a pit, a window into nothing."

Reaching Clojure on Java

2008-02-01T14:26:00.000+05:30

Read Java: Evolutionary Dead End on Artima first, then come back here.

…Done?

Well, I couldn’t agree more. Java – the language – has got to stabilise. I’ve had an uneasy feeling about it ever since those God-awful generics were shoe-horned onto it and now I get the heebee-jeebees every time I hear of the new ‘features’ they intend to tack on in Java 7. Closures? Weird imports? Enough already!

Now I’m not saying that all these proposals are without value, but I get the distinct feeling that Java is suffering from a severe case of ‘language envy’. If C#’s got it, Java’s got to have it too. And like a middle-aged businessman passing through a mid-life crisis and dressing two decades younger than he should, Java wants to fit in with the cool crowd. Ruby’s got closures? We want them too! Groovy and Scala have built in support for XML? Hell, lets pile that on as well! The Java crowd has still to realise that the battle for cool was lost a long, long time ago. There’s no point getting all tooled up and charging the enemy now.

Java has found its niche. It’s an excellent language for large, complex enterprise applications. It’s perfect for building massive, scalable apps using large teams of programmers. It’s got excellent tool and library support and it does what it does quite well. It’s COBOL for the 21st century and there’s Nothing Wrong With That!

The JVM

However, we need to make a clear distinction between Java (the Language), Java (the JVM) and the Java Class Libraries. The Java language needs to stabilise and the Class Libraries need to be cleaned up and slimmed down a bit, but the JVM is absolute gold. It’s the best part of the entire stack and an excellent target platform.

The Java language is IMHO, the weakest part of the chain. It’s good for enterprisy apps built by large teams of ~~trained monkeys~~ skilled programmers, but not so great if you have more kinetic needs. All the language features which help enforce some modicum of control are precisely what come in your way when you need to rapidly prototype a solution. However, you don’t need to throw the JVM baby out with the Java bathwater. You can still leverage the JVM by using the plethora of languages which build upon it, like JRuby, Jython, Groovy, Scala and no doubt a whole stable-full of more esoteric options. You can use a language more suitable to the task at hand without having to abandon the vast ecosystem of high quality Java libraries and that sweet, sweet virtual machine.

Clojure, on Java

So let’s segue smoothly to the real topic I wanted to discuss.

Clojure.

Groovy is nice and Scala is sweet, but I’ve had an unfulfilled hankering for a good Lisp on the JVM for a very long time. There are some Common Lisp implementations which work on the JVM, but there’s a difference between a language which has been ported to run on the JVM (E.g. JRuby, Jython) and one which has been designed to run on the JVM (E.g. Groovy). There’s an unpleasant impedance mismatch when you try to stick one language environment on top of another. For example, while using Jython, should I use the Python libraries or the Java ones? Can I easily pass the return values generated by one set of libraries to the other? Mixing them both together is ugly and error prone.

That’s one reason a language like Groovy feels so much better. Since it’s targeted at the JVM, it follows a well-know set of idioms and patterns. It’s easy to pick up and comfortable to use.

So I was on the lookout for a Lisp which didn’t just run on the JVM, but embraced it. And eventually, I found Clojure. It’s precisely what it says on the label and presses all my buttons. It’s a Lisp for functional programming with excellent support for concurrency, targeting the JVM. In fact, the STM support is based on MVCC, which is the first time I’ve heard of someone using this technique for thread transactions. It also has excellent support for calling Java code from within itself (the ‘.’ is beautiful)

A good Lisp on the JVM has the potential to be a real blockbuster. I detest the closed feel of most CL implementations and Clojure feels like a breath of fresh air. The ability to fit in with a multi-lingual and multi-paradigm world is IMHO essential for any general purpose language.

Requests and unsolicited advice

Since I’m feeling both excited and generous (ha!), here’s some unsolicited advice for Rich Hickey, the guy behind it all.

Read Yegge’s Lisp is not an acceptable Lisp: No doubt he already has, but as a newcomer to lisp, I can agree with a lot of what he says, especially about the moribund community and general lack of direction and vision.
Don’t emphasis the Lispness of Clojure: Yes it’s a Lisp and there’s no way to hide that, (not (with (all (those parentheses)))), but talk about all the cool things you can do with Clojure, not why it’s a better Lisp. You need to reach out to the people looking for a cool language, not try and convert existing lisp fanatics. For the great unwashed, the Lisp heritage is a negative and that has to be accepted and death with. BTW, it looks like the Logix guys agree, ‘cause what they’ve come up with looks like an infix Lisp without the parentheses to me! No mention of Lisp on their front page, though you’ll find plenty in the docs.
Better Documentation: This is related to points 1 and 2. The docs are decent, but only if you already have a fairly good idea about Lisp. They need to start from a far more basic level (take a look at Arc's Tutorial for example). No one needs to write a book on Clojure (yet), but you do need lots and lots of code samples, starting from “Hello World” to a complete application, exercising different parts of the language. A wiki would be nice too.
IDE Support: It’s an obvious hole. Target Eclipse or NetBeans, not Emacs. Remember, if you really want to reach critical mass, your target audience is going to be Java weenies and not Lispers!
RAD tools: You need Clojure on Rails, or something. I personally think magical frameworks like Rails aren’t a very good idea, but apparently there are lots of people out there who disagree.
Better OOP support: Remember, you’re trying to interop with Java. Being able to extend and define classes and interfaces in Clojure itself would be nice.
Spread the word!: I literally stumbled across Clojure while reading a thread on Reddit. You need to start screaming about the language from the roof-tops! :-) Get the word out. Ruby is going through a bad patch now and there’s plenty of bloggers out there looking for The Next Big Thing. Get them to start talking about Clojure and you’ve got it made. But you need to have better docs and IDE support in place first.

If all this has piqued your interest, check out the docs on the Clojure site, and listen to the Clojure presentation (audio / pdf). They’re worth the time.

So that’s how I reached Clojure on Java (what a terrible pun! I’m almost ashamed. Almost.). Am I going to adopt it as my alternative language? It’s too early to tell. But I am going to be keeping a very close eye on it.

Note: Arc's out. And by that I mean it's out of the running. No Unicode support and it's just another gated Lisp dialect. Sorry Paul, no cookie for you.

Socialize: del.icio.us | digg | reddit | Technorati | Yahoo My Web

10 interesting lessons from 1 interesting project

2007-12-25T12:30:00.000+05:30

I’ve spent six interesting months on my current project and my association with it is at last coming to a close. The design phase is largely over and I can finally move on to other things.

Like some sort of technological Santa Clause, I skip from chimney to chimney spreading good cheer, pixie dust and sooty footprints as I go. I like to think I leave happy families in my wake, opening the little ‘presents’ I’ve left behind to shrieks of excitement (or is that terror? I never can tell). I do know they’ll be looking forward to seeing me once more, no matter how much coal they ended up with in their stocking this year :-).

Anyway, this current assignment has been a most interesting project; as in “May you live in interesting times” and “Why yes, Nurse, this is quite an interesting case”.

Yup, that kind of interesting.

It’s a pity that most of the lessons that this project have taught me are of the political, managerial and interpersonal variety than those of the technical type! I’ve noted some of them down in this post, more as a reminder to myself than anything else.

A quick overview

The project aims to develop a Java based data entry application for a large Swiss financial services firm. The onshore team was from a German company (part of the corporate group) and the offshore development was handled in Mumbai. There are around 20 devs, 5 designers and various testers, managers and other assorted mischief makers. The project is now over budget, delayed and the quality of the deliverable is not up to snuff. The only reason there’s any hope of completing in time is because individually, the team members are very highly skilled. It’s just that getting people to work together seems to be very difficult.

I joined the project just six months ago, when the good ship INS T******s had already struck ice and was beginning to list rather alarmingly. I came onto the scene just in time to miss the preceding bit where most of the mistakes had been made, but just in time to start seeing their effects start to become apparent. It’s no fun joining a project and immediately realising that you’re going to have to fight your way to the lifeboats before long! :-)

Mind you, it’s not been as bad as some projects I’ve worked on, but in many ways it’s been even more frustrating, because success was so close, and now it’s oh so far.

The 10 lessons

1. People have to be aligned to project success

If people can succeed at the expense of the project, then the project will suffer. If you make it almost necessary for them to bury the project to further themselves, then stand clear of the stampede for the shovels!

People are not intrinsically evil. They want to do the right thing and they will too, if given the chance. However, if you inadvertently stack the environment such that the only way they can advance their own position is by stepping on someone else’s face, then there will be a lot of people wandering around with bloodied mugs. It’s the responsibility of the project manager(s) to align individuals and teams properly, so everyone is pulling together towards project completion and success.

Fail to do so and you doom the project to delay and possible failure.

Some things to keep in mind:

There should be no gain in shunting blame between onshore and offshore.
Onshore should not be allowed to ‘succeed’ by leaving offshore behind and vice-versa.
Onshore should gain nothing by show-casing itself independently before the client and neither should offshore.
Onshore should be reassured that their roles and jobs are secure and that they will not be ‘Bangalored’.
Offshore should not attempt to aggressively infiltrate and displace onshore. See point 4.

2. Architectural Vision is vital

You don’t have to nail down each and every detail before you start the build. You can back-track once the build has started and update the design to reflect new learning’s. However, you cannot start the build without having a very clear picture of what you want, how you want it and how you’re going to get it.

The first thing I noticed and flagged when I joined the project was a lack of project vision. No one really knew how exactly things were going to interact with each other or how changes to one component were going to impact another. There were a lot of things which were just up in the air and it was anyone’s guess as to where they were going to land.

A major reason behind this was the lack of a proper POC (proof of concept). Had one been constructed, the entire design and build stages would have been several orders of magnitude easier. If there’s one thing I’ve taken away from this project, it’s this:

Don’t skip the POC.

3. Never split tasks and teams across geographies

Take a stale, grilled cheese sandwich and start pulling it apart. You’ll notice that there’re all kinds of tendrils and gloopy bits and amoebic pseudopodia keeping the ends together. There’s also a rather distressing smell, but that’s orthogonal to our discussion (thanks be to God). Now if you pull the bits apart far enough, the tendrils start to snap and you’re eventually left with two soggy pieces of bread rather than a single, disgusting whole.

The communication links within a team look like those tendrils of stale cheese. There’s a tremendous amount of communication which goes on within a team. You simply can’t stretch those links across a continent and expect them to hold together. You won’t end up with one team, but two distinct teams.

Now if you acknowledge that and formalise the interface between the two teams, then there is no problem. However, if you ignore the separation you’re going to end up facing all kinds of problems, all of which can be traced to the narrow communication bandwidth.

In short, stack two sandwiches one on top of the other if you want, but don’t try to pull one apart. That’s just nasty.

4. If analysis is incomplete, it’s a major red flag

Is analysis incomplete? Are the analysts walking around looking sheepish and mumbling something about Agile project management? Well, then, start screaming now and don’t stop till they bundle you away in the coat with the wrap around sleeves. Electro-shock therapy is positively relaxing compared to what you’re going to go through otherwise.

Not convinced? Then be prepared for a constant stream of ‘defects’ which are simply holes in the requirements and specifications. Watch the analysts dodge and deflect criticisms as they desperately try to blame everyone but themselves. Laugh as the client tears the hair off his head in frustration. Cry as you work week-ends to try and reduce the defect count. It’s a never ending spectacle of terror and rage!

Coming soon to a project near you! Well, unless you insist that the analysis be up to snuff before you start to build the application. I don’t care how much the client is screaming, complete the analysis. To do otherwise will simply postpone the whipping, not help you avoid it.

5. You can’t estimate use cases which have not been analysed yet

Seems pretty obvious, doesn’t it? So why oh why did the drivers of this train wreck go right ahead and do that? Why oh why did they then commit on these fantastical dates to the client? And why oh why did we not fall over ourselves laughing when they wanted us to meet those deadlines?

6. If the onshore team has never done offshore before, it’s a major project risk

There’s a first time for everything and ignorance is nothing to be ashamed of. However, not recognising the lack of experience as a project risk and not mitigating it is inexcusable. Do not pass ‘Go’, do not collect $200. It’s straight to jail for you.

7. One month RUP iterations are too short

A one month RUP iteration may be too short. The team was always running to keep up, with hardly any time to breathe. With a one month iteration, you have one week of defect fixing from the previous iteration, two weeks of build activity and then one week for integration. Of course, you’ve not actually planned for that one week of defect fixing, so everything is running behind schedule from the get go.

You have to choose a pace which is sustainable. Anything else is asking for developer frustration, burn-out and murderous rampages.

8. Requirements – keep them simple, keep them consolidated

If you find yourself with more than 3-5 requirement documents in your design document’s references section, then you’re in trouble. Scattering requirements across too many documents means you’ll always miss something out and have to re-work it.

Keep the analysts on a short leash. Left to themselves, they’ll loose themselves in a twisty maze of interdependent documents, all alike. Only it’s you who’s likely be eaten by a grue, not them.

9. Regular, formal communication is a must

If the project can afford it, then get yourselves a full or part time secretary. Involve him in all your onshore/offshore meetings and have him keep the minutes and publish them. Appointing someone from within the team might also work, but people hate to keep minutes.

You need at least two long video conferences a week to synchronise on design and one quick sync meeting a day for the team leads and testers. Keep them short.

10. Constant reviews are a must

You have to keep reviewing project and team performance on a background thread. Someone has to have enough mental bandwidth to spend some time every Nth iteration examining all the problems faced in N-1 and apply any lessons learnt to N+1. Don’t expect the project manager to do this, since he’ll be too busy fighting fires. Ideally, this should be done by the delivery head or the project champion.

So that’s it. The project is limping along with the harried offshore build team chained to the oars. Morale is low and the pace is slow. However, it’s still likely that the project will be delivered in some form or another. We’ll have to wait and watch.

The only bright spark is that the onshore team (which I’m holding responsible for much of the mess here) has had their bonuses canceled and are going to be getting coal in their stocking this year. Now that’s something to put a smile on Sadistic Santa’s face.

Ho. Ho. Ho.

Socialize: del.icio.us | digg | reddit | Technorati | Yahoo My Web

Borged!

2007-11-03T21:41:00.001+05:30

I’ve finally started blogging again after a long hiatus, but this time it’s from the belly of the beast. I’ve been swallowed by the Borg. Yes indeed, I’ve abandoned my earlier aversion to formal pants servile ties and joined a large, faceless multi-national.

Due to the vagaries of chance, I’ve always ended up in smaller companies before this. Things just turned out that way. Anyway, I’d always suspected that I might have a bit of difficulty fitting into a more formal corporate culture. Dilbert (the true guide to corporate culture everywhere!) didn’t paint too rosy a picture either :-) But surprise, surprise, it’s not so bad (he squealed, as he hung by his thumbs), it’s not so bad at all.

Some quick points of comparison:

The Facilities: Most smaller companies are unable to offer amenities like a bus service, a proper canteen, housing or other sorts of facilities. These may seem like little things, but they’re important hygiene factors. And speaking of hygiene, you finally get clean toilets! :-)
Training: This is the first place I’ve been in which offers compulsory training; 40 hours at a minimum every year. More if you can swing it. Now, I’m not a fan of structured, formal learning (having been processed by enough educational institutions in the past), but it’s not a complete waste of time either.
The Impersonality: Brilliant! I’m finally anonymous! :-) It feels great to be a little fish in a big pond, instead of things being the other way around. Now, this will surprise many people, but it’s actually tiring (and then eventually irritating) when everyone from the janitor to the CEO knows your name, face and birthmarks. This is probably the introvert in me talking, but there’s something to be said for being able to walk through the entire building and not have to constantly ‘Hi!’ everyone you see.
A larger pool of potential friends: Now for the extrovert in me :-) In an organization of several tens of thousands of wage slaves, you’re bound to come across malcontent deviants as insane as you are. What’s that you said? So you're a fan of red staplers, coke bottle glasses and naked flames too? Brilliant ! :-)
Openness: Paradoxically, larger companies are more open. Try and get the owner of a SME to divulge the details about the companies finances or its future direction. You'll have to break out the pliers to get anything close to the truth. Public corporations are legally obliged to reveal their financial details and you can read about the companies prospects in the daily broadsheet.
Permanence: The chances of you coming to work one fine day and finding a padlock on the door and shit-eating grin on your 'bosses' face are quite remote.
Multiple escalation paths: Got a problem with your superior in a smaller company? Tough luck, he’s probably the owner (or a close relative – hello nepotism!). Either live with him or leave. In large organizations, there’s usually a structured escalation path and conflict resolution forums. It’s much easier to iron things out.
Professionalism: The people you’re working with were (theoretically/presumably) hired because they are the best fit for the job, not because they’re the owner’s retarded cousin from Jalgaon or a member of his community.
Varied Projects: You don’t need to switch companies to switch projects.
Brand Recognition: Having to explain what your company does every time gets real old, real fast.
Better Opportunities for Travel: You don’t get many big spenders contracting with smaller companies. If you want to travel a bit, it’s better to join a larger firm.
Better long term prospects: Finally, room to grow! Larger firms have more space for growth, bother vertically and horizontally. In smaller organizations, I’ve usually ended up in a position where the only way up is to kill the owner or marry his daughter (preferably both). It feels great to be able to contemplate a career plan which doesn’t include the liberal use of rat poison to open up some space in the ranks first.

So what’s the reason behind the differences? It’s all pretty straight-forward: money and scale. And one more thing (echo’s of which can be found in this post). Larger organizations are run by employees in part for their own benefit and not the benefit of nebulous, anonymous ‘shareholders’. It’s not fair to the actual owners (a.k.a shareholders, a.k.a. chumps), but it’s a fact.

“What’s that you say, the team’s feeling ‘stressed’? Well, it’s off to Lonavla for a week-end then!” – Manager in Faceless Multinational Pvt. Ltd.

In smaller companies, the owner’s breathing down your neck every time you fill in an expense account.

“What’s that you say, the team’s feeling ‘stressed’? Well, call them in on the week-end for a side project I’ve been thinking about, that’ll cheer them up!” – Hari Sadu (SME CEO)

Maybe the only reason I’m enjoying myself here is because of ye olde “Herbage be greener on the other side”. Or maybe things really are better over here. Time will tell. But as I contemplate by assimilation into the beast, I have to accept that the Borg were right after all.

Resistance was futile.

Socialize: del.icio.us | digg | reddit | Technorati | Yahoo My Web

Blinkenlights

2007-10-28T22:38:00.000+05:30

I’ve been struck by a sudden interest in Electronics and Electricity. It’s not too surprising to me, since I was drawn to programming through my interest in computer hardware. In fact, I was first bitten by the bug while in college and I would while away hours in the library, laboriously reading Horowitz's “The Art of Electronics”. However, the siren song of computer programming and the gentler learning curve soon hijacked my interest and I haven’t looked back since. Until now.

So what sparked my interest now? I was reading an article in Popular Mechanics covering their annual Breakthrough Conference and one of the winners was the Windbelt . I was stunned by the simplicity of the design, its cleverness; by its down-right, flat out hackish nature. Simple and effective. It also lead me to start researching the topic of Appropriate Technology and I was hooked. Further reading of Make Magazine, EcoGeek and Hack a Day just made things worse :-)

I’ve always had an interest in making things. Unfortunately, I was always stymied by my lack of electronic knowledge. The age of steam and gearing is long past. If you want to make anything of any significance, you have to stick a circuit in it. That’s what drew me to electronics in college, but the steep learning threw me off. This time, I have a better grasp of what I want and how to get there.

My major mistake was to try and use college text books as my source of information. This is an absolutely terrible idea if you’re not actually in a college course! College text books are geared towards helping students pass tests and not necessarily towards helping the reader acquire any actual, usable skills. Tests are treated as ends in themselves. This is precisely the wrong approach if you’re an enthusiast or a hobbyist. You’re interested in the subject because you want to get things done ASAP. If you need deep theoretical knowledge, you’ll pick it up when required. Show me the blinkenlights already!

This time around, I’ve managed to track down some electronics books for hobbyists and there’s a world of difference. No doubt, I’ll pick up some massive canonical tome sometime in the future to fill in the gaps, but by then I actually expect to have a structure with gaps worth filling. If I were to start off with the doorstop, I’d still be stuck on chapter 5 months later. :-)

So anyway, if I stick with my study plan, I hope to be able to build simple devices in a couple of months time. I’m particularly interested in eco-friendly power generation, like pico/micro hydro-power and wind power. Stuff that is simple/cheap to setup and simple/cheap to run. That’s the mantra that works in the developing world, which is what I want to target.

Ambitious much? You bet! :-) but at worst, I’ll end up wasting a few (hundred) after-work hours and pick up a thorough understanding of computer hardware. Building up your own board to support a microcontroller and writing code which has only a couple of Kb of EPROM and 128 bytes (!) of RAM (OS, what OS?) is going to be a very useful learning experience in any case.

People who know me well are probably holding their heads and groaning after reading this missive. I’m notorious for starting projects and dropping them half-way when I'm distracted by the next shiny thing and I lose interest in what I’m currently working on. There’s no guarantee this won’t happen this time as well, but I’m hoping that I’ve become a little more stable over the years (Ha!). Let’s see how this turns out. :-D

Socialize: del.icio.us | digg | reddit | Technorati | Yahoo My Web

Development and Delivery or Management and Marketing Gimmicks?

2007-07-11T15:38:00.000+05:30

SURGEON GENERAL’S WARNING: The following post contains extreme amounts of cynicism brought on by excessive contact with various marketroids and PHBs. Read at your own risk. May lead to hair-pulling, spontaneous gnashing of teeth and depression.

I’ve been working for a fairly typical, small IT services shop over the last year or so and I’ve seen projects come (rarely) and projects go (often). I’ve become increasingly frustrated by the insistence of upper management on concentrating on the wrong things, viz. management and marketing gimmickry rather than core delivery. I’ll be leaving this place in a couple of days (Hallelujah! :-), so here is an amalgam of what I’ve learnt about servicing your clients and knowing your markets (usually by watching us fail to do so properly).

At the lower end of the SME segment, the customer is more concerned about the actual delivery/success of the project while at the higher end, he's more concerned about the perception of delivery/success.

Let me illustrate what I mean by taking an extreme example. Let’s compare the actions and attitudes of a large trans-national IT services company (Big Corp) v/s a one man code shop (One Man Army a.k.a. Rambo). The actual situations below are not directly applicable except in the most extreme cases since you’ll no doubt be somewhere in the spectrum between Big Corp and Rambo, rather than at the ends of the rainbow. You’re relationship with your customer will thus be suitable nuanced.

The ‘customer’

Big Corp’s end customer is usually not the actual business entity they’re dealing with. It’s far more specific. It’s actually the business person they’re interacting with; the guy who’s brought them in. A ‘company’ has no mind of it’s own and despite the legal precedent set in many countries, it is not a ‘person’ in any sense of the word. It has no concept of profit or loss, or success or failure (or right and wrong for that matter). The people within it do.

This may seem like an extremely trite observation, but it is central to understanding the actions of any business. In any business relationship, the vendor/consultant/etc. will try and align themselves to the people they’re reporting to, not to the business at large. If an action will help their corporate patron succeed (and thus help them succeed) at the cost of the client business entity, they will do it

This is true for the one man shop too, but at the market level he operates within, he deals with people who are directly and immediately affected by the success or failure of the business as a whole. He’s usually dealing with the business owner or is only one step removed from him. He thus has to justify his presence by providing actual, immediate and tangible business benefits. He has to deliver.

The end goal

Now keeping in mind that the end customer is not the business but someone within it, the end goal shifts in a subtle way. It’s no longer necessarily about providing value, but the perception of value. Big Corp has to concentrate on providing its corporate patrons with ammunition they can use in the boardroom. They have to justify the expenses they’re incurring and to bolster their position. A project which is wildly successful, but cannot be used to further the position of the patron is useless compared to another which is a failure, but can be successfully spun as being otherwise.

The goal is to help the customer (i.e. Big Corps corporate sponsor) to move up the ladder, thus putting him in a position to reward Big Corp with larger and juicier contracts.

Rambo on the other hand, has to stay on the ball and actually deliver the product as specified. In a smaller business, any investment has to start showing returns pretty fast and a failure to do so can be catastrophic. Small business owners are infamous for trying to squeeze the maximum benefit out of every dime, since the dime in question usually belongs to the owner himself. The one man shop therefore cannot simply deal in perceptions, but has to provide tangible benefits in order to justify its presence. Its goal is thus to deliver the product and satisfy the customer (which is usually the actual business, not an employee within it) in order to receive more contracts in the future.

The ‘product’

The end product description too now undergoes a subtle change. The product is thus not necessarily working software - in time and under budget - but the perception of this having been delivered. Any roll-on effects on the business are usually so delayed that they can be safely ignored or blamed on other people later.

Rambo on the other hand, is stuck trying to actually deliver the product as specified.

The deliverable

Now we come to the meat of the matter. Having laid out the realities of life in the industry, what is the actual deliverable expected of the vendor and thus, what is it that is actually delivered.

Big Corp will concentrate on strengthening it’s corporate sponsor. Quick on-time delivery of the product is one way to do this, but it may be easier and cheaper to provide him with talking points, studies and white-papers instead. For example, Big Corp will spend quite some time giving it’s sponsors documents and presentations which will show just how profitable it is to farm business out to Big Corp like entities (but especially to Big Corp). Thus the deluge of studies favouring flavour-of-the-month management methodologies and out-sourcing techniques. A quick glance at the web site of any large IT vendor will show it to be replete with things of this nature.

The one man shop will concentrate on quick, on-time delivery. It’s very difficult for him to duck the bullet and find excuses for any defects. He has to deliver! Since he’s smaller, he doesn’t have a vast pool of potential ~~victims~~ clients to fall back on. Since the investment of the business in him is usually small as well, it’s easy to cut him adrift. Having relatively more to lose and few ways of weaseling out of his obligations, Rambo is usually forced to do a better job of things, or perish trying.

The end

So what does all this mean for smaller IT service shops? Simply this.

Cut the crap.

If you're a small company, you need to concentrate on development and delivery rather than trying to copy the big boys and talking about ‘management initiatives’, two-in-a-box hierarchies and all that jazz. Your customer is not interested in your marketing spiel because the market you’re trying to serve is extremely result oriented. Save the bullshit for when you’re all grown up.

Figure out how to deliver projects on time and under budget or be forced out of the market. It's as simple as that.

In fact, it's so simple and obvious, I just might have to write a white-paper on it...

Socialize: del.icio.us | digg | Furl | reddit | Rojo | Spurl | Technorati | Yahoo My Web

The Great Switcheroo

2007-05-23T11:38:00.000+05:30

There is a God!

Just a couple of days ago, I decided to back up my system and lo and behold, within an hour or two of my having done so, my partition tables mysteriously disappeared and I had to re-partition and reformat my hard disk. I'm blaming it all on solar flares.

So anyhow, I'm left with one clean disk and no operating system to put on it. I'd recently finished downloading Kubuntu and so I decided to go ahead and install that.

Now anyone who's known me for any length of time knows that I've only every run GNOME on my system(s) since time immemorial. And I've been using Gentoo since the Universe first flashed into being. I firmly believe that the Earth is simply the result of an errant 'emerge world', which explains a lot of things.

Unfortunately, I no longer have the time to download ginormous source tarballs and sit patiently while they compile. Squeezing out that last drop of performance out of my system no longer excites me as it once did and quite frankly, I'm no longer convinced that looking at compiler messages as they flash by increases your intelligence. Portage has been a bit of a mess recently and by the end, my 3 year old installation couldn't compile some basic packages I needed.

GNOME too has become a bit of an embarrassment lately. I mean look at it! It's become all corporate-y and boring. It's like cola that's been left out too long; flat, sugary and unwholesome.

So it's been out with the old and in with the new. KDE replaces GNOME and (K)Ubuntu replaces Gentoo. And I'm loving it! KDE is absolutely brilliant to work with. It's very configurable and I absolutely LOVE YaQuake. Apt-get is sweet too and it's brilliant how little time it takes to download and install stuff. The installation was a breeze and the default application set is fairly decent. Of course, I have 'special' needs, but I can satisfy them fairly easily.

Kubuntu is really a lovely distribution and I plan to stick with it for a long time to come. Or at least until the next solar flare anyway...

Zen and the Art of Functional Programming

2007-04-16T14:22:00.000+05:30

I’m a regular at http://programming.reddit.com and just about every day there’s at least one (or two or three) posts about some functional programming language or the other. Usually it’s Haskell which is being showcased, though you’ll also find entries for Erlang and occasionally for some of the more obscure ones like O’Caml or Dylan. I finally zoned out under the constant barrage of propaganda and moaning softly (“brains! braaaaiiiiins!) zombie-shuffled over to check out what the fuss was all about.

What’s all this about Zen then?

The Zen of programming is when you internalise the correct way of solving a problem using the programming model you’re working with. You might start off programming with something like C, using it in a classic procedural fashion. When you move from Procedural Programming on to something like Object Oriented Programming (OOP) using Java or C++ etc., it’s a bit of a culture shock at first. You keep trying to program procedurally, fighting the language every step of the way. There finally comes a moment however, when all the abstract concepts behind OOP fall into place with an almost audible snap and suddenly, in a moment of epiphany, you attain OOP enlightenment.

Now I can’t say I’ve achieve that level of union with the Tao of Functional Programming, but I am starting to finally grok what the whole thing is about. However, all opinions listed below are subject to rather radical change!

What’s Functional Programming (FP)?

I’ll save me some time and copy-paste in some definitions.

Functional programming is a style of programming that emphasizes the evaluation of expressions, rather than execution of commands. The expressions in these language are formed by using functions to combine basic values. A functional language is a language that supports and encourages programming in a functional style.

-- FAQ for comp.lang.functional

Functional programming is a programming paradigm that treats computation as the evaluation of mathematical functions and avoids state and mutable data. It emphasizes the application of functions, in contrast with the imperative programming style that emphasizes changes in state.

-- Wikipedia.

As far as I can make out so far, FP is all about decomposing the problem down to the various algorithms and data transformations involved and then cleanly enumerating them. We don’t really need to worry about the ‘objects’ involved (there aren’t any), or their relationship with one another. It’s all about dividing and conquering the problem by slicing it up into small bits and then figuring out what we need to do to each of the slices. Rather than identify objects, couple the data with behaviour and then deal with those objects, we pass both data and code around as required (and as easily), assembling and disassembling relationships as required.

Mind you, this is pretty much the SOP for most programming tasks, it’s just that FP makes it easier to work in this fashion. Besides, if you un-gag the Lispers for a moment, they will endlessly lecture you about the benefits of having small bits of code operate on large blobs of data. Rather like a shoal of Piranha reducing a buffalo. Be sure you re-gag them once you’re through or else they’ll never shut up.

Why spend time learning Functional Programming?

My primary reasons were:

A New Paradigm: Learning a new programming paradigm helps to stretch your mind and makes you a better programmer overall, even if you never directly apply any of the new techniques you’ve used. Notice I’m talking about paradigms here, not languages. Learning C++ if you know Java may make you a lightly better programmer over all, but going from Procedural programming to OOP for example, can be a mind-bending experience.
The Next Big Thing: The Functional programming weenies just can’t stop babbling about how they’re going to take over the world. And who knows, they just might. It takes a while for this sort of momentum to build up (look how long it took OOP to become mainstream!) but the signs abound; FP just might be the next big thing.
Increased Productivity: Anecdotal evidence suggests that writing code in a functional way leads to smaller, cleaner code and fewer bugs. The logic of the algorithm is clearly detailed and many of the internal details of the operations are hidden away, leading to less clutter. I’ve often heard that FP is about describing what you want done, while Imperative Programming ends up detailing how you want it done as well.
It’s Popping Up Everywhere!: FP isn’t all that obscure any more. You’ll regularly come across bits of functional code in various decidedly non FP languages. Java’s Comparator Interface is a good example of a common FP idiom, where you pass along a bit of code as a parameter as well as the data and have the code act on the data. Java 7 might have closures as well, which are already to be found in Ruby. Python has things like list comprehension, which has a distinctly FP feel and so on. I thought I might as well experience all these concepts in one integrated functional package rather than piecemeal.

FP vs OOP

Invariably when you start to talk about a new programming model, you’re met with slack jaws, blank stares and mewling cries of “But, but, but… OOP!”. Now I’m not one to deride OOP because I like the concept quite a lot. It’s a great fit for a range of applications and can really help model a lot of complex domains and interactions. However, it isn’t the end all and be all of computing that the OOP aficionados (and their groupies) make it out to be. One particular domain which seems to be a bit of a mismatch is the Web.

Most web programming involves a lot of pointless conversion from flat data to OOP and back again. Take a basic CRUD application. The user enters plain data without any OOP savvy behaviours or what have you. Just characters strung together. When he hits submit, we convert this data to fit into our OOP model and play around with it in the middle layer. We then flatten it once more and stick it in the database. We might also have some stored procedures in the database as well (usually written in a non-OOP language/manner). So the only place we’re really using OOP is in the middle layer and most of what we’re doing is simply converting data from one model to another. It’s just a huge waste of time. Embrace the fact that all we want to do is apply transformations to data and use FP (which is admirably suited to the role) to do just that.

I mean, what’s so Object Oriented about Servlets? They're actually very functional. You usually just implement one method/function which accepts user data as parameters, munges it and then forwards more data somewhere else, where we display the response.

Reuse?

As far as reuse goes, OOP hasn’t proven to be all that. Look at the Java Library. It’s just a bunch of methods. Useful one’s no doubt, but how many times have you inherited from one of it’s classes (other than Object of course! J)? You make an object which represents some data and you call methods on it. Most of the reusability is at the level of the methods. How much more useful then if we decouple the methods completely from the data, use duck typing and work on just about anything that’s passed in? Reusablity goes through the roof! Certainly, it won’t be any less than an OOP design.

Which FP Language should I go for?

“MMRRGH! (LISP!)” scream the Lispers through their gags, shouts of “Haskell!” from one corner and “Erlang!” from the other. They choice is endless. There are a whole load of functional languages out there, so which one should you pick up?

My 2p? Go for Erlang and Haskell. Both are relatively pure functional languages (unlike chimera like O’Caml, which are partly OOP and Lisp which is undifferentiated gloop and can be anything you want it to be) and fairly mainstream. Mind you, there’s nothing bad about being multi-paradigm, but when you’re learning FP, it’s best to suffer under a bit of disciple and be forced to be functional. Erlang is actually used in The Real World, though largely only in specialised hardware like network switches etc, which Haskell is under active developments and has a lot of mind-share.

I’m learning Erlang first because along with being FP, it has slightly different way of going about threading, though I hope to pick up Haskell as well (since it has another way of doing threading as well).

An Aside on Threading with Erlang and Haskell

Both Erlang and Haskell have taken a novel and (to me) refreshingly different way of going about threading. Neither concept is blindingly innovative, but it’s the first time I’ve seen it implemented as part of a language.

Threading is really coming into its own now. We’re moving into an age of massively multi-core CPUs where each core may be less powerful than the chips of today, but there’ll be so many per chip that the net speed will be tremendous. However, programs don’t multi-thread themselves. Developers have to identify concurrent paths and co-ordinate their interactions; something which can be quite difficult to code and fiendishly difficult to debug.

One advantage of FP is that functional code is inherently much easier to parallelise. Since functions don’t access or affect global state and act only on their parameters, you can infer possible parallel paths and have them run concurrently.

For e.g.

A = foo()
B = bar()

Here, the interpreter can run both foo() and bar()in parallel since they are not related and thus are guaranteed not to affect each other.

But wait, there’s more! Both Erlang and Haskell make threading even easier with innovative threading models. Rather than have process communicate through shared memory where you have to handle locking/concurrency yourself, both help make the process of writing multi-threaded code much easier.

Erlang (Actor/Message Model) : It’s Unix IPC all over again! You basically have pipes which you use to communicate between processes. Messages are asynchronous and not location specific, so processes can migrate to different machines transparently. Errors are piped to related processes as well, giving you robust error handling. No shared memory and scaling it trivial. In fact, the possibility of basically almost unlimited scaling across multiple machines is what really draws me to Erlang and has me drooling like an idiot. Write your code properly and you can just keep slotting in boxes. Erlang also has the ability to update code while it’s running, which means theoretically zero downtime if you’re careful. And it’s all actually in use in the telecommunications industry, so all this is real, not vapour.
Haskell (Software Transactional Memory Model) : Database transactions, but in local memory! Separate threads run within their own transactions and see a consistent view of the world. No need to explicitly lock bits of shared memory, we just let the system handle all the error prone bits and concentrate on our logic, confidently that our threads won’t be stepping on each other toes. This is a really powerful abstraction and it’s something that had me smacking my forehead, wondering why I didn’t think of it before. However, I see some fundamental problems with multi-machine scalability. This is a fairly well explored problem in the database world and I’m not sure I want my code doing two phase commits and roll-backs in a cluster. Still cool though.

Conclusions

There’s still a long way for me to go yet. I’m going to be going for a vacation in a couple of days, so there’s going to be a bit of a break in my journey of exploration. I hope to pick up the thread once more on my return and forge ahead. Let’s see why else I find worth writing about :-)

Socialize: del.icio.us | digg | Furl | reddit | Rojo | Spurl | Technorati | Yahoo My Web

Generation Gap

2007-02-25T13:16:00.000+05:30

"The virtues required in military officers [in Second Generational militaries are] careful, even obsessive attention to process; avoiding risky decisions, and whenever possible making decisions by committee; avoiding responsibility; careerism, because success is measured by career progression; and generally shining up the handle on the big front door. Time is not very important, while dotting every i and crossing every t is vital, since at some point the auditors will be coming...As time goes on, efficiency tends to become more important than effectiveness...

...the virtues a Third Generation military requires in its officers [are different]. Those virtues—eagerness to make decisions and take responsibility, boldness, broad-mindedness and a spirit of intellectual inquiry, contempt for careerism and careerists—are not wanted in Second Generation militaries, and officers who demonstrate them are usually weeded out early. A Third Generation culture is difficult to maintain, and even more—impossible perhaps?—to restore once lost."

-- William S. Lind (Regression)

I’m a bit of an armchair general. It’s nothing more than a boyish fascination with things that clank around and go bang, but I do believe that the stratagems of war and the organisations which implement them have much to teach us. The battlefield is Darwinian by nature. If an idea has merit, then you live another day and if it’s DOA, then you’re KIA. In war, a lot of things are stripped to their core and stand naked in their essence. If an idea works on the battlefield, it’ll usually work just as well in a less lethal environment as well.

Now this isn't exactly a stunning new insight or anything. MBA types have been proudly lugging around copies of "The Art of War" since at least the 80's and perhaps longer. However, I believe it's not just overarching stratagems which might have some value, but the nitty-gritty of day to day organisation as well.

One area where there is a lot to be learnt, is in team organisation. An army deals with ‘projects’ which are under severe time, resource and quality pressures and with team members who are consequently under intense pressure as well. Ground realities change on a minute by minute basis and new challenges and opportunities pop up constantly. The quality of personnel is quite variable, which a few star performers and a whole load of dross, but everyone has to be put to work as best as possible. The overall techniques are well understood, but the devil is in the details of application. Hell, it sounds just like a software project! :-)

The Generation Gap

Military historians tend to segregate the organisational structure of fighting forces into ‘generations’:

First Generation armies/warfare: This was the first proper organisation of forces beyond a violent mob. It is completely obsolete and no longer observed. We’re talking lancers in formation and cavalry charges here.
Second Generation armies/warfare: This generation is geared towards wars of attrition where both the enemy and your own men are de-individualised and treated as numbers. It’s all about lobbing the maximum tonnage of shells at one another and slow, steady advances, with victory dependant more on industrial capacity than brilliant planning. The communication is largely top-down, with (one hopes) military savants on top directing every move on the ground far below. WW 1 is a good example of this, with static lines of defence and trench warfare.
Third Generation armies /warfare: This relies on surprise and speed, and depends far more on the quality of the individual soldier. Units are small and highly independent and attempt to get inside the decision loop of the opponent, acting faster than he can respond. The lines of communication are more bi-directional here, with significant input coming from below. In fact, most tactical decisions will probably be made at the lower levels directly. The German Blitzkrieg from WW2 is a classic example of this type of warfare.
Fourth Generation armies/warfare: This is war by decentralised, non-state actors against states, populations and other non-state actors. Units are very small and cell like, almost completely independent and ideologically committed; relying on the media as much as on force of arms to achieve their aims. The recent military and strategic victory of Hizbullah over Israel in 2006 is a stunning example of the effectiveness of this strategy, if properly implemented. It’s Third Generation warfare on steroids.

So what’s the difference in levels of effectiveness? Let’s compare 3G to 2G first. The Wehrmacht in WW2 was certainly 3G and performed very well against the rest of Europe. German tanks cut through the Maginot Line with ease and swiftly defeated every army they faced. It required the combined resources of two continents (Most of Asia and Northern America) and several disastrous decisions on the part of the German high command to finally roll them back. When Allied forces war-gamed some of the battles after the war, they found that it required 25% more Allied troops to equal the performance of the Germans and this was attributed almost entirely to the high quality of the officer corps (in other words, their application of 3G concepts which requires well-trained, independent troops).

Even more dramatic was the recent clash between a 4G and a 2G force, when Hizbullah defeated Israel (Israel was once a 3G force, but you don’t need to be a good soldier to massacre civilians and so the IDF has gradually withered in competence). By the last days of the war, Israel had fielded in excess of 40,000 troops, with artillery and air/naval support, while Hizbullah had only one light infantry brigade of around 3000 in the fight. They never felt the need to reinforce them. In other words, 3000 whipped 40,000. With a ratio of around 1:13, that means that Hizbullah was 13x or 1300% more effective than Israel. A truly staggering difference. Read this complete analysis for more

Software organisations

So what does all of this have to do with software projects? Well, my own observation is that software organisations can also be defined in much the same ways as military organisations. If we segregate them by generations, just like we did with armies, we get:

First Generation organisations: The first groupings of programmers. Obsolete.
Second Generation organisations: Most service firms making bespoke software fall into this category. Projects are about size and scope, with managers trying to increase team size to the max. Developers are treated as cogs in a giant wheel; as perfectly replaceable components, to be swapped in and out as desired. It’s all about project plans, matrices and counting man-hours, a few PHBs attempting to control the entire project from above while the unwashed mill about below. It’s a war of attrition against the client and the goal, with rigid attention to rules and an emphasis on blind obedience.
Third Generation organisations: Most start-ups, especially those geared towards producing an application, fall into this category. Teams are small and the work fast-paced. Individuals care more about doing the job than looking like their doing the job. Leaders emerge almost spontaneously and eagerly accept new responsibilities. Innovation is encouraged and boldness is rewarded.
Fourth Generation organisations: I’m going to go out on a limb here and say that Free Software is probably Fourth Generational. You have widely distributed teams, amorphously organised and made up of disjointed individuals united only by ideology. Individuals and sub-teams join and leave almost at random, but the project still forges ahead under the leadership of a charismatic leader.

A comparison of how the various generations fare against one another is fairly straight-forward. Start-ups don't always succeed against entrenched players, but they're the ones who usually supply the surprise upsets and market changing products which unseat the Big Boys. Netscape, Google, Amazon and Apple are some names which come to mind. Companies like Google seem to instinctively realise that they must retain their 3G edge, even as they grow and we've seen a whole lot of very innovative ideas on project and people management come out of there.

It's the 4G actors which are complete wild-cards. A good Open Source (though it's Free Software which is really4G) can either open up new markets and platforms for commercial concerns or completely take over a segment and devastate existing players. Or both.

You can really go far with this analogy, co-relating the tactics and strategies of 4G armed forces with 3/4G software entities. Much can be gleaned from examining the successes of 3/4G actors against less evolved opponents. I might elaborate about that at a later time, since I have a truly marvelous post about that in mind, which this column is too narrow to contain.

Personal Considerations

There are few things which guarantee more frustration than being a 3G person in a 2G shop and there are few things more pathetic than a 2G person in a 3G team. The last part of the quote by Lind above, the bit about 3G personality types being weeded out early, is very relevant since it happens quite frequently. The person may not be physically removed, but his 3G characteristics are usually excised. He may not leave the company, but he will dampen down his native enthusiasm and vigour and fall in line with the rest of the drones; at least for a little while. It can’t last forever though and eventually, he will leave for more hospitable shores.

Organisations are not completely stagnant though. Small 3G organisations eventually grow larger and devolve into 2G ones, while large 2G behemoths may occasionally become 3G (or at least 2.5G) in times of crisis. This opens us new opportunities for dormant 3/2G types. You’ll see this happening all the time in armies. Generals who’ve done very well for themselves in peacetime armies are usually dead within months of the start of hostilities, killed either by the enemy or their own side. On the other hand, effective commanders who rise rapidly through the ranks during war are usually shunted aside once combat ends and it’s back to boardroom battles. History is replete with instances of charismatic Generals who’ve ended up committing professional or physical suicide once the war is over.

Some Parting Advice

My personal experience is that the generation gap between your own personality and that of the organisation you work for can be the source of a lot of mental and emotional stress. Trying to swim against the current is very, very exhausting and only very rarely worth the effort. If you’re a 2G type, then accept that and work in an organisation which rewards your particular leanings and if you’re a 3G or 4G type, then for God’s sake, avoid <3G organisations like the plague. You may strike it lucky and end up in a 3G team in a 2G world, but that’s usually a complete fluke. Just skip the frustration and head straight to where you’ll be appreciated. That’s my personal experience and for once, I’m going to be applying this bit of advice to my own personal life.

I can’t help it, this post's author just makes so much sense! :-D

On the business of software

2007-02-06T15:09:00.000+05:30

A long, but very accurate quote from Joel Spolsky. I completely agree with both the points made by him. I wish I had more to say than that, but there really isn’t much else to add… :-)

"The number one thing is a micro-ISV shouldn't be one person, it should be two people at the very least and one of them should have the business and marketing and sales skills experience. The other one should have the tech skills and the programming and the inventing the product type of skills. That kind of partnership is far more likely to be successful than the individual working alone just because people don't usually have both of those skill sets and so they really need to all be covered.

Or if you have only the sales and marketing you're not going to be to be successful because you won't have a good product and if you don't have product development skills you won't be successful because no one will hear about you and the business side won't really work. Having two people, I feel, is crucial just to validate your idea, almost to keep each other motivated, bounce ideas off each other and so on - that sort of thing.

The first part is the minimum size for a micro-ISV that can go anywhere beyond a fun project.

The second part, and Bob alluded to this earlier, which is my prototypical example of the photo gallery which is probably nine million micro-ISVs have made an application where it's like "Hey, everybody's got these digital cameras my application lets you upload all your pictures and put them on the web and make web galleries." There have been about a million of these and a very tiny number of them have been successful and the vast majority of them have been instant flops. For some reason this is an incredibly appealing idea for software developers to do, maybe because they feel like they know how to do everything, all the steps they're going to need to do to write the code to make this work, but for some reason they never really make it work.

But what I've always told these people time and time again, and they never listen to me, is instead of making the generic "upload your pictures application" take a very, very small niche audience - wedding photographers - and make the ultimate application for wedding photographers. Find out exactly what wedding photographers need. There's a lot of money around wedding photographers, they get paid an awful lot of money, and figure out exactly what their workflow is. If you need to find wedding photographers because they're in the yellow pages and there are directories of these things. Call them all and find out what they want and try to sell them your solution.

And so what I always tell micro-ISVs is, and that's just an illustrative picture, try to narrow your potential audience almost as much as possible to get started. In order to bootstrap you're going to have to find a very small initial audience you can serve extremely well of people who all speak to each other. One you can find all in one place, where there's money being spent because you're going to need to get a part of it for this thing to work. And once you find that very narrow niche, that's the way you get bootstrapped and you can think about crossing the chasm as Jeffrey Morris says into other kinds of industries and other kinds of larger markets. But you really need to pick something vertical to start with."

Read the rest at The MicroISV Show #10 - Joel Spolsky

Codephobia

2007-02-05T18:26:00.000+05:30

Grady Booch had come to Manchester for a couple of days last month and I’d gone for his talk about "The promise, The limits, The beauty of Software". There were several interesting themes explored, but it was one comment made by him, almost in passing, which really struck a chord with me

He mentioned how he’s seen organisations which seem as if they’re afraid of code and that jibes with what I’ve noticed as well. An organisation or project or team which is completely tied up with process, to the extent that almost nothing can be done without reams of paper being produced, is usually a victim of codephobia. Before a single line can be written or modified, several Word documents will have to be either produced or updated, items in the project tracking system will have to be massaged, meetings will have to be called, recalcitrant team leads will have to cudgelled into submission and developers will have to be dragged to their seats – their nails leaving deep groves in the carpeting as they go.

Now mind you, this isn’t the usual screed by frustrated programmers against the horrors of ‘Process’. The ability to track, managed and control a project is vital to it’s success. However, smart, successful firms realise that all of these things are a means to an end. The customer wants a working application, not reams of design documents and lists of tracked defects. All of these are meant to enable you to write code better and faster.

This simple concept however, seems to be beyond the ability of many people. They act as if the various artifacts of process adherence were what the customer was paying them for and not the actual application. At heart, it’s all about being afraid of putting pen to paper - of producing the code - because that’s when the inadequacies will start to show and the incompetence will start to bubble to the surface, like marsh gas from a bog. In other cases, it’s the managers fear of the unknown. Most project managers are code-illiterate and so fear what they cannot understand or accurately track. They understand documents though and are happy to lose themselves in them. They’d love to have people code in Word if they could. Notice the popularity of code generators in such teams. It’s a dead give away :-)

In any successful team that I’ve seen, the focus is completely on the code. Everything is subservient to it and team is made up of and lead by competent programmers. Only a minimum amount of ‘process’ is tolerated and it’s all about knuckling down and churning out working code as soon as possible. Codephobic teams postpone code generation to the last moment and have to be dragged to their compilers kicking and screaming…

Which is kind of poetically just, because that is exactly what their customers end up doing when they see the end result.

Because the stakes are so small

2007-02-01T20:38:00.000+05:30

"University politics are vicious precisely because the stakes are so small."
-- Henry Kissinger

I’m not a fan on Henry Kissinger by any means, but even the Devil can be right sometimes. It’s not university politics which concerns me though, but the sometimes byzantine intrigue which takes place within even relatively minor projects.

I’ve found office politics to be in turns, disgusting, depressing and distressing. It can occasionally be amusing, but only in the slightly tight-lipped, pathetic way an argument between two drunken bums might be amusing. What it usually is, is soul-destroyingly depressing. It sours the atmosphere of the entire project, splits teams and causes you to loose respect for people you’ll probably have to deal with on a daily basis.

And it’s usually so petty. The motivations are so base; jealousy, imagined slights, over-reaching ambition and profound insecurities. The tactics are so filthy; lies, rumour mongering and gossip. And what are the fruits? The imagined goals are usually minor things like a promotion, a slightly better appraisal or even something as petty as sucking up to management. The eventual result is usually bitterness, a loss of respect of others for ones-self and the debasement of your own soul.

How is one to deal with it when it starts? I have no clue. The people who are of this mould are usually incorrigibly bent out of true. You can try to straighten them out or bend yourself to fit their twisted psyche, but it’s usually futile. Both your resistance or compliance will trigger something within them which will make you their target. The base (and it is very base) cause, is that deep down, they actually enjoy the cut and thrust of it. And that won’t change until they do.

So should one get down in the mud and wrestle with them? Nope. You’ll feel disgusted with yourself, while they’ll be loving it. The best policy is to keep your interaction with such people to a minimum and just get on with doing a good job. They’ll either make so many enemies, they’ll finally be pushed out…

…or they’ll become the CEO.

In the eye of the beholder

2006-12-19T22:00:00.000+05:30

What is art?

Is it only something like this or this? Or may be even this or this or this. How about this? Is this art or just the random scribblings of a demented monkey? Does splattering paint on a canvas qualify as art? If it does, then gulls are consummate artists. With better taste too.

Can you call this art? Or this, or even this. Is the man who shits in a jar and then sells it as high art, an artist? If poo in a bottle is art, then I've got Picasso beat. Every day.

Everything up until now has been the work of man (or ape). Is art something which necessarily has to be the creation of Man?

Is yes, then what about this? Or this or this or this? True, you need a computer to really bring these images to life, but they’re just mathematical functions. Order from chaos. Can we perhaps broaden our definition to include anything that’s beautiful to look at maybe? This looks great, but few would call the scene ‘art’. They’d call the photographer an artist though. But what about the programmer who wrote to code for the Mandelbrot program? No one calls him an artist even though both of them are simply capturing the beauty of nature. How does that make any sense?

Or does it? One can argue that given the same camera and scenery, I’d end up capturing disappointing images of mis-framed peaks, but given a computer and the algorithm, any one can produce the exact same images of chaotic functions. Maybe that human spark is key?

So if art isn't necessarily just something pretty (though it must be pleasing to the eye) and everything humans produce isn't necessarily art (though human involvement is necessary), then ‘art’ must lie at the intersection of these two planes.

So what is art?

Art is beauty, which is the result of skill or talent.

fin.

GTD and Me

2006-10-26T19:10:00.000+05:30

I've spent some time hanging around GTD aficionados and I've been itching to give it a go for quite some time now. Never had the courage to dump my over-flowing inbox though. The clean break required and the abandonment of old and tested ways was always a little too scary. Working at this new place though, I decided to go clean from the get go. I've been 'GTD' for the last month now or so and here's how I go about my business.

What is GTD?

At it's heart, GTD is about two very simple ideas:

Be ruthless in how you organise and process tasks.
Group actions according to how/where you'll do them, not when.

Point 1 means you never let your inbox get crufty with old emails and posts left around for reference. Dump all non-actionable items in the appropriate folders. Focus on what needs to be done and (point 2) group your activities according to how you'll do them.

And then do them.

If they can't be done now, defer or delegate them.

Rinse and repeat.

How do I GTD?

Everyone's got their own particular flavour of GTD which fits their requirements and personality. Here's how I process the mountains of emails I usually receive.

I've set up a bunch of folders prepended with '@' which I use for all my GTD needs. There's no particular reason to use the '@' character to mark your folders, it just helps group them together and on top. All these folders (except for @Reference and @Everything Else) have been set to show the total number of mails within them, not the number of unread items.

When a new email comes in, I read it and:

If it's spam, a duplicate or completely useless, I delete it
If it was worth reading, but it's purely informational, I dump it into @Everything Else
If it's worth keeping as a reference, I put it in @Reference
If it's something I need to act on, I put it in @Action
If it's a call I need to make or a meeting I need to attend, I put it in @Calls or @Meetings as appropriate

Once I'm done with this initial processing loop, I take up the actions in @Action one by one and:

If it's something I can do and finish off immediately, I do it.
If it's something that can be done now, but it's going to take some time to complete, I get to work on it and put it in @In Progress
If it's something I need to wait on for sometime/someone, I put it in @Waiting
If it's something I would like to do someday, but not right now, then it going into @Someday

And that's it! :-)

I keep reviewing @Action, @In Progress and @Waiting and acting on the items in there, while keeping my inbox empty at all times. All non-email related todo's are converted into emails using self-addressed mails and put into the appropriate @ folder. This keeps everything organised and collected in one location.

This may not be the best way to organise a GTD system, but it's been a real productivity booster for me. It also keeps my stress levels under control :-). At all times I know the exact status of every task currently under way, the things that need doing and the people who need pushing.

GTD?

Yes.

11.2 km/s

2006-09-07T22:47:00.001+05:30

Since I'm now busy in an office from morning to evening, I find I have plenty of time to blog when I get home. Strange how that turns out. When you have all the time in the world, you have zero motivation to do anything with it. When you're forced to squeeze every free minute out of your schedule, suddenly, you're inspired!

A friend mentioned in passing that it seemed that I'd finally returned to the corporate world. I don't think I truly ever left. I'm sure that when Sputnik was soaring through space, it too thought it had slipped from Earth's grip once and for all. But the great funnel of gravitational suck that is the Earth wasn't through yet. Within three months, it had dragged the spunky little satellite low enough that it burnt up in the upper atmosphere.

Escape velocity is hard to achieve, especially when having attained separation, you realise just how cold space is.

A streak of light in the sky;
celestial debris coming home.
Wish upon a falling star.

God, I sound depressing! :-/

Khaki Blues

2006-09-06T22:41:00.000+05:30

Steve Irwin bites it. And good riddance!

Here's a man who spent his life running around after hapless beasts, provoking them into attacking him and then prancing around as if fending off animals with brains the size of walnuts is something to crow about.

"Lookit me! I'm sitting on the back of a trussed up croc while ten men hold it down! Ain't I the man!"

South Park 's caricature of him was biting and insightful. An empty headed, khaki shirt filling buffoon, running around shouting "I'm going to pin 'im down and jam my thumb up his arse!" in his trademark 'australian-for-beer' accent. Pray tell, how exactly does wrestling with a Dingo or putting the smack down on a Koala further the cause of either science or conservation? Will the fact that you clotheslined an alligator help protect the species or will giving a Kangaroo a pouch wedgie help spread environmental awareness? I don't see erstwhile Steve's audience of WWE watching mouth-breathers running out to embrace either trees or conservationism anytime soon.

Nature has the last laugh as usual though, as Steve is stabbed through the heart by Touche the Sting-ray; no doubt as he tried to wrestle it to the seabed and jam his thumb up its arse. Et tu Brute! and all that.

Now it's off to the happy hunting grounds for Steve, to spend the rest of eternity being chased by the spirits of the very animals he abused, as they for once, get to shove their thumbs, claws, pincers and what have you up his arse.

Crikey! Now that's what I would call some real entertainment!

Perfection Paralysis

2006-06-23T18:55:00.000+05:30

It's taken me more than a month to finally get cracking on a pending project of mine. I've been wanting to get this thing done for months now, but could never seem to get started. The problem? Perfection Paralysis.

Being a bit of a perfectionist (HA!) and I'm always fussing over whatever I do. If I write a couple of classes, I'll spend the next few days/weeks/months constantly refactoring, re-designing and re-structuring them. Invariably, I'll either lose interest in the project before I finish or else trash the whole thing to start from the beginning. I was paralysed by my quest for perfection. It was incredibly frustrating.

In the case of this particular project, I was fussing as usual about the design and the technology to use (Spring? something simpler? JDBC? but I want to use Hibernate! etc...) and I just had enough. I finally just sat down and started to push out code (at my usual blazing rate :-). Viola, 2 days later and I've written some 700+ lines of working, tested code and I'm happy :-D. Every time I sit in front of the code, I get the itch to refactor, but I squash it. There'll be time enough for that when I get this out as Alpha. Right now, I want it DONE and I want it OUT!

So yeah, there's a bit of the ol' copy-paste in there, and I can maybe reduce the code size by 20% or so. There are several egregious instances of global variable use and a few too many static methods. One particular class is ballooning alarmingly and needs to be split up... but I'm consciously ignoring these warts. The code works, and it works quite well and at the end, slightly messy but working code trumps code that's beautifully designed, but which exists only on the whiteboard.

It's painful, but I'm learning to say it...

IT'S GOOD ENOUGH!

The Monsoon scale of privilege

2006-05-31T18:22:00.000+05:30

The Monsoons are here in Mumbai and how happy you are about that seems to be directly proportional to how wealthy you are.

If you're in the Upper Middle Class and above, it's a great time. The weather is cooler, there's a refreshing breeze and finally there's some relief from the unrelenting humidity and heat of summer. A perfect time to visit Lunavala, Mahabalashwar or some other hill station or just to relax in front of a window with a hot cup of cocoa.

If you're a part of the teeming Middle and Lower Middle Classes, your emotions are more mixed. On the one hand, your home and work environment are now much cooler, but you also face terrible problems in your commute, dripping walls at home, flooded compounds and a higher incidence of disease. You're still glad of the rains, but only for a while. Then it's back to struggling to ensure that you survive another deluge. No trips to the green ghats for you!

If you're a part of the multitudinous Poor, you're in deep, deep trouble. You're probably going to enjoy the season for all of one day, before your shack starts to float off. If you're lucky enough to have a shack. If you're living on the streets (and a very large percentage of Mumbai's population does just that), you're going to be reduced to holding off the rain with a plastic sheet drawn over yourself, while you soak from below. You're in for several months of misery, as you're forced to live in several feet of fetid gutter water, struggling to find something clean to drink. But hey, at least the demolitions of your homes is on pause! :-(

Enjoy the 'soons!

Why Science Fiction is like Diabetes

2006-05-29T05:16:00.000+05:30

I like Science Fiction (Sci-Fi). I like it a lot. While in the shower a couple of days ago, I got to thinking about it in a lot more detail than I usually do.

What is science fiction all about? What's at the core of it? How do you classify it? Why do we have a genre of fiction called science fiction at all? Is science fiction about space aliens and laser blasters and space fighters impossibly going 'whoosh' though the vacuum of space? (Well no, that's what crap sci-fi is about, but I'm getting ahead of myself...)

Or is it more?

It's more.

Allow me to broadly classify science fiction into two wide categories. I'll name them in the style of diabetes; Type 1 and Type 2 Sci-Fi. As I discuss this taxonomical system of mine, I hope it'll bring out what I believe is at the core of science fiction.

Type 1 Sci-Fi: Asking the right questions

Good science fiction, like good science, is all about asking interesting questions.

What if...?

What if there was no more scarcity and everyone could have whatever they wanted in whatever quantity they wanted? What if it were possible to indefinitely delay death? What if we faced an immediate, external existential threat? How would human society or a set of human being react to these situations?

You take human society and/or a human protagonist and place them in a new situation and you see what happens.

Individual episodes of Star Trek, for example, when they're not talking about 'reversing the polarity' of some gizmo or another, are usually of this type. So are BattleStar Galactica's episodes (the 're-imagined' series). For example, in the episode "Flesh and Bone" a very interesting issue that was dealt with, was that of torture. It's unethical to torture and summarily execute a human being, but is it ethical to torture an artificial but sapient creature? This raises other interesting questions. If it's ethical to prefer the safety of a human being over that of an animal's because of sentience, then shouldn't we prefer the safety of a machine over that of a human being if it's smarter?

If you start thinking of Sci-Fi in these terms, then many books which you might not have ever thought of as Sci-Fi, can actually be classified under it. A good example would be Orwell's 1984. Not too many people would call it 'science fiction', but it is a very good example of the genre in my opinion. The movie THX 1138 (Lucas' first proper movie) is basically an adaptation of 1984 and it's considered pucca Sci-Fi.

Good Sci-Fi is not about machines or robots or technology, it's about people and society.

Type 2 Sci-Fi: Space Opera

Space Opera is all about splashing about and painting on a broader canvas. Things like Star Wars, Firefly, Lost in Space etc. all fall under this category. Let's take Star Wars for example, since it's the most familiar. The entire story could just as easily have been set in a more contemporary time and 'galaxy', instead of being set "a long time ago, in a galaxy far far away". Replace light sabers with steel swords, X-Wings and TIE fighters with horses and the space ships with galleons and you don't really lose too much. At its heart, it's a take of adventure, war and magic and would fit right into the 14th century.

Having the story play out across an entire galaxy however, increases the sense of grandeur and 'space', if you will. Why have Vader destroy a village when you can have him blow up an entire planet? Why give him tuberculosis when you can have him breath like an asthmatic horse by putting him in a ventilator suit?

Type 2 Sci-Fi is not as deep as Type 1 Sci-Fi, but it can be a whole load of fun! :-)

Science Fiction: The thinking man's time-pass

Type 1 Sci-Fi is what I really love, though I don't mind Type 2 when I'm in the mood. I find Type 1 Sci-Fi, like the works of Banks or Baxter extremely enjoyable and I can say that some works have significantly broadened my mind. For example, it was one of Baxter's short stories that really helped me understand the concept of Space-Time! :-) My brother thinks it's a waste of time, but I can think of worse ways to relax.

BarCamp Mumbai May-2006

2006-05-14T15:59:00.000+05:30

It was the best of camps, it was the worst of camps...

So I went to the Mumbai BarCamp held appropriately on the 13th of May at IIT Mumbai; and was thoroughly disappointed by the quality of the vast majority of the speakers as well as the venue.

What went wrong? Where to begin!

1. It must have been 33-35 deg Celsius out, with very high humidity and all the slightly interesting talks were held in an unventilated, non air-conditioned room. I was sweating like a pig in sauna and my God, I stank! It just wasn't possible to concentrate in such circumstances.

2. This is supposed to be a BarCamp, not a conference. Sandeep was the one who really pointed this out. We were supposed to be discussing these topics interactively, not sitting in chairs listening to droning speakers...

3. ...and the speakers! Where did they find this bunch?! The first talk was on 'SMS Applications'. At the end of it, I knew nothing significant about this technology, but had learned that it may in fact be physically possible to be bored to death. I was really looking forward to a planned talk on OpenLaszlo and Flex, however, both turned out to be completely empty of content. The only bright spot was a talk by some guy from Pinstorm about the mechanics of optimising Google AdWords campaigns. That was interesting, however, the heat and humidity had sucked all the life out of me by then.

4. Let's not leave the audience out of this however! What a bunch of morons! In just about every talk I was in there were a couple of idiots (different ones every time!) who would bore everyone with endless, inane questions with very little relevance to the topic at hand. You're supposed to ask 'questions' in order to learn retards! Not to try and push your own agenda, you imbeciles! It's a good thing things weren't as interactive as BarCamps should be. I shudder to think of the quality of the discussion.

The only redeeming quality of the entire circus was that I got to meet Vinay and Chandrasing. We really clicked and ended up spending pretty much our entire free time holding spirited debates on everything from LISP to PHP, OOP to Procedural programming. After the fiasco that was BarCamp Mumbai finally ended, we went out to the Hirandani Complex where we held out own mini-BarCamp (FooCamp? / BazCamp?). I learnt a hell of a lot more in those few hours than I did in the entire day before it.

The plan's now to meet every month or so for our own, more exclusive and as yet un-named, gathering (FooCamp!) and discuss matters of importance to us. Code a bit too. Get our hands dirty.

Let's see how things work out! Even if all we end up doing is meeting up in the swamps and flinging poo at each other (PooCamp!), it'll be better than a BarCamp!

A fork() in the road

2006-05-14T15:54:00.000+05:30

So I fired my employers last Friday; and boy do I feel great! :-D

Hmmm, that makes things sound more adversarial than they actually were. I'd actually given my notice some 3 months ago and the parting was as amicable as these things usually are. Lots of good-lucks and fare-thee-wells and such. No fireworks or artillery or bridges set ablaze, thank God. That stuff can be quite unpleasant.

Anyway. I've decided to head out on my own as an independent consultant/ contractor/ freelancer/ what have you. I tried to tread down this path some 2 years ago as well, but things didn't turn out too well then. I'm better prepared now, or at least, I hope I am :-)

So why the big change? Well, de jure, there's been no change at all! For the last year and a half, partly for tax reasons, I've been a 'consultant' anyway. So my official designation hasn't changed at all. Of course, de facto, there's all kinds of good stuff now. I've managed to shed one of the most irritating aspects of working in Mumbai; the commute. I used to spend around 1:30 hours each way, every day just to get to and from the office. That's out now and I have an extra 3 hours everyday to myself now, even if I continue to spend the normal 9 hours at work as I used to. And there's the other difference. I have a slightly unique style of working when I'm programming. I work in bursts of intense activity, with long breaks in the middle. The average work-place can't really accommodate such a style, preferring employees to work at a steady pace through out the day. So I used to end up frustratingly trapped in the office for several unproductive hours everyday. No more of that now! :-)

I like change too, so working on a myriad of different projects for different people seems very exciting... and once things get going, I'm hoping it'll be a lot more lucrative than being a wage-slave.

So I'm going to give it 2-3 months. Let's see how things work out in that time. Here's wishing me some much needed luck! :-D

ZK and OpenLaszlo : Ajay and Vijay

2006-04-13T19:48:00.000+05:30

Bhaiyaaaaaa!

You know the story; two brothers visit the Kumbh Mela and are separated in the crush. One grows up to be a policeman, while the other becomes a vagabond and eventually a hardened criminal. Both of them are then united under extremely contrived circumstances, only to find themselves set against each other. However, everything is eventually resolved, and both of them join hands to save their widowed mother from the hands of the (muwahahaha!) evil villain. Or something like that...

ZK and OpenLaszlo seem to me like the Ajay and Vijay of Web UI. On the one hand you have ZK, an extremely rich AJAX based Web UI Library which allows you to define the interface in XML, while OpenLaszlo is extremely rich Flash based Web UI Library which allows you to define the interface in XML. They're both Open Source, use JavaScript for scripting and are absolutely gorgeous.

Designing using these libraries is really straightforward too. Here's how to make a window with the canonical "Hello World".

ZK:

<window title="1st window" border="normal" width="200px">
Hello, World!
</window>

OpenLaszlo:

<canvas>
<window>
<text>Hello World!</text>
</window>
</canvas>

Not much to choose between huh? :-)

The difference between the two of them is in their emphasis. ZK bills itself as an easy to use AJAX library while OpenLaszlo is more ambitious, describing itself as a way to create "zero-install web applications with the user interface capabilities of desktop client software" In addition, OpenLaszlo can now be compiled into DHTML, not just Flash.

So which one will I use if I need something like this? I'm not exactly sure. It's not just a competition between these two libraries, but between using Flash or Ajax for your UI too. If I'm pushed to it, I'll probably side with OpenLaszlo. This is largely because it can also be compiled to DHTML as well as Flash and because the demos at www.openlaszlo.org really put it through it's paces and show what it can do. In addition, there's a Flash player available for mobile devices now, but Javascript support on those things can be spotty. Javascript windows and animations really crawl on Firefox under Linux too and since that's my primary platform at home and at work, it's a significant downside for me.

There really isn't that much to choose between them. It'll probably boil down to personal preferences. Both libraries are well supported, stable and under active development. Both make the task of creating absolutely stunning interfaces almost trivial.

Ajay or Vijay, it doesn't really matter. The bad guy goes down in the end.

Big Ball o' Links

2006-03-28T19:34:00.000+05:30

Just a bit of link blogging on a not so slow Tuesday:

Big Ball of Mud: "A BIG BALL OF MUD is a casually, even haphazardly, structured system..." You know it's a bad idea, I know it's a bad idea, so why is it so damned popular?
The AppSec FAQ: Not exactly ground-breaking work, but it's a good recap of some common web app security boo-boo's.
How to Create a REST Protocol: The name says it all. Also review Common Rest Mistakes.
43F Recap - The best of GTD: Some of the best posts about GTD at 43 Folders.

It's not a bug, it's a feature!

2006-03-21T18:56:00.000+05:30

Here's a new one I've heard that's similar and a lot fresher:

It's not complex, it's comprehensive!

Made me smile.

Don't Ask, Do Tell

2006-02-24T13:51:00.000+05:30

There's a great piece up at The Pragmatic Programmer about some very basic, but very important OOP concepts. Read the article for a complete explanation, but here's a very short summary...

Don't ask an object for information about it's state and then make decisions based on that data. You shouldn't be making decisions about the state of an object and then changing that state yourself. This logic should be inside that particular object. Just tell it what you want done and then let it do that to itself.
Don't tightly couple objects together by passing data around from one to another. Once you've returned some data from an object, any semantic meaning associated with it is lost. Basic OOP states that data should be stored along with it's state/methods; i.e. in its own object. Related to point 1.
Don't use multiple methods to access/work upon a single invariant state variable. Multithreading will ensure that invariants can no longer be guaranteed invariable (unless you lock properly). Better to use something like a map() call to apply actions to data.

In other words, follow basic OOP fundamentals rigorously. Keep data and the methods/logic that act upon it together in one place. Don't scatter it all about.

S.P. Jain - Principles and Framework for Project Management

2006-02-21T17:02:00.000+05:30

Five, 9 hour days of gruelling work later, I must admit that the course was totally worth it. The time literally flew by and I can say with a fair bit of confidence that my perspectives on the art and science of project management have shifted significantly.

I've learnt a lot and not just from the instructor (Prof. Ajay Parasrampuria). As he himself pointed out, with more than 200 man-years of experience in the room, there's not a whole lot he could have added. 'Course, he went right ahead and did just that! But more on that later...

There were around 20 participants from a wide range of backgrounds. We had people from USAID, GAIL and Emirates. Large corporations, small companies and one hopeful entrepreneur. People with more than 40 years of organisational management experience and those with very little.

And of course, me :-)

The most important and illuminating part of the entire 5 days was the sharing of past experiences by the participants. Some were more reserved than others and remained regrettably silent, but there was enough back and forth to keep everyone interested.

Now, I don't want to give the impression that we did all the work and Ajay just stood back and listened in :-). His knowledge of the PMBOK framework was outstanding, as was his ability to communicate with the rest of us. His ability to continually relate principles from the framework to his and others real life experiences was absolutely riveting.

Perhaps the most educational part of the course were the daily 'games' we participated in. Now I can't reveal the details since we were requested not to ruin the surprise for the next batch, but I hope I can say they were excellent learning experiences. For me, the moment of PMBOK epiphany came during one of them when I noticed just how easy managing the entire (rather complicated) project became once we abandoned our ad-hoc procedures and started to follow the process framework. Things started to slot into place almost immediately and it was shockingly easy to manage all that data and derive meaning from it.

The highlight of the course for me was the presentation on "Monitoring and Controlling IT Projects" by Mr. Tapan Bose, V.P. for Financial/Banking Projects at Satyam Computers. Lots of useful observations from the trenches and insights on what works and what doesn't. The main points I picked up was not to forget the human dimension (especially team building) and to treat the process as a part of the project, not as a template filling chore carried out under threat of audit.

Of course, the most depressing part of the entire exercise was the realisation by all concerned, of how little of what we'd learnt will actually be applied in real life. We might be all gung-ho about working according to the PMBOK framework in our next project, but without institutional support (what the PMBOK would call Enterprise Environmental Factors and Organisational Processes Assets :-), it's very difficult to be an agent of change. There has got to be buy in from top management, or it's all just an expensive waste of time.

Here's to hoping I can actually use what I've learnt!

TurboGears - It's all in your head

2006-02-04T06:33:00.000+05:30

Turbogears is absolutely, positively, definitely, unquestionably completely amazing!

I started out with very rusty python (I haven't coded in it for more than a year and they've managed to sneak in new language features in the meantime) and only a cursory knowledge of SQLObject, CherryPy and Kid (the three main components of the stack). Around 4 hours later, I have an almost working Todo List web application and a grin on my face that could eat a banana sideways.

The only reason it took me 4 hours is because of the ramp-up time associated with learning any new technology. I had to stop every few minutes and read the docs, scratch my head a little and then continue. And the only reason the application is 'almost working' is because I've decided to extend the capabilities significantly and so I'll be re-writing it.

But pause to consider what I've just accomplished. I've got the canonical 'Hello World' of web applications up and running (well, almost) in less than half a working day and I'm so charged up about it, I'm already thinking of version 2. A whole SDLC compressed into half a working day! And the size of the code! The entire controllers.py file is smaller than the Hibernate XML mappings I'd have had to write to get something similar in Java.

But the most important part of the experience is the pythonic characteristic of TurboGears.

You can hold it all in your head.

With most Java frameworks and ORMs, you're running to the docs every few minutes, every time. With TurboGears, now that I've done it once, I really don't have to go back to the docs at all; at least for the bits I've worked with. That's a real source of satisfaction and a major cause behind the speed boost.

Time to complete my next app of the same size and complexity? I'm guessing 45 minutes :-)

Face Time and Free Stuff

2006-02-02T13:18:00.000+05:30

I've blogged about the need to interact with people before here and here. Christopher Hawkins has written an excellent article that succinctly sums up what it's all about:

Face Time and Free Stuff

Ruby/Rails Redux

2006-01-10T13:06:00.000+05:30

I tried. I really did.

If you've been following this blog, you'll know that I gave Ruby a look-see when the hype over Rails first started to build up. I didn't particularly like what I saw and being a bit of a Java weenie, I went back into its all encompassing, XML filled, embrace.

But I've absolutely had it with Java now. It's great for large complicated projects with teams of developers working together, but for a one man effort, cobbled together in what free time I have, Java is over-kill. It's official, I'm finally sick to death of the ginormous configuration files and over-engineered class hierarchies. Do I really need 10+ classes just to access the database? I hope not.

So I succumbed to the siren like call of the Rails fanboyz and decided to give Ruby on Rails a try... but I couldn't do it; I just couldn't. [cue weepy music]

The rational reason I'll trot out is that Ruby has terrible support for I18n/Unicode, but the real reason is that Ruby's syntax is just too much like Perl (aka 'line noise'). Enough to give me flashbacks about my time in the trenches writing that filth. They had to drag me out from under the bed and pull my thumb out of my mouth.

And don't get me started on the 'magical' ways of Rails. I hate config files as much as the next guy, but you can have too much of a good thing.

So what's the alternative?

Python.

Now, I don't need reminding that Python has it's warts, I've had to stare at them often enough. I dislike the explicit 'self' variable, the lack of access control modifiers and the almost-but-not-quite OOP schematics. But's it's leagues better than Ruby and it's got fairly decent I18n.

Pythons not been getting the buzz Ruby has as far as its frameworks go, but there are two that are certainly worth considering.

1. TurboGears
2. Django

Both promise Rails like speed of development and simplicity through a single integrated Web Application stack. TurboGears glues together various best of breed frameworks for it's needs while Django builds up everything from scratch.

Some people seem to prefer Django, but I haven't decided which way I'll go yet. This much however, is clear...

Ruby can ride the next train out of town and good riddance.

There are no uninteresting numbers

2006-01-03T13:52:00.001+05:30

Jim Loy's theorem: There are no uninteresting numbers.

Proof: Assume that there are. Then there is a lowest uninteresting number. That would make that number very interesting... which is a contradiction.

Hmmm. Interesting... :-)

More at http://www.jimloy.com/math/math.htm

3 Great Article from Technicat

2006-01-02T16:40:00.000+05:30

Ok, this blog is turning to just a bunch of links, but these articles were too good to pass up:

Great stuff!

"My Golden Rule" -- Business 2.0 Magazine

2005-12-23T16:30:00.000+05:30

My Golden Rule

49 business visionaries, collectively worth over $70 billion, state which single philosophy they swear by more than any other.

It's interesting, but as always take this stuff with a whole load of salt. Things are never as clear-cut as the blurb suggests. Who knows if it's these "rules" that made them successful or whether they just wish they had.

:-)

Are there no truly original ideas left?

2005-12-23T14:28:00.000+05:30

Look it what I found. Openomy.

Let's see now...

Online File System? Check.
Tagging? Check.
REST based? Check.
1 GB space free? Check.
Transparent Integration coming? Check.

See this blog entry for an introduction to Openomy.

Sounds real similiar to this and this, doesn't it? :-)

4 Rules for the Practical Entrepreneur -- Fragmented Markets

2005-12-22T17:05:00.000+05:30

Ian Landsman has written an excellent article for the practical entrepreneur in this article. Definitely worth the time spent reading it.

SLoPIS (sloppies): Slow Loading Pages of Infinite Size

2005-12-15T16:49:00.000+05:30

I've sometimes wondered how I'd instantiate and maintain a call-back link between a client and a server on the Internet. That is, I want the server to update the client as and when various events occur without the client having to specifically poll for them. This is very easy to do over an intranet, but seems almost impossible over the Internet because most clients will be behind restrictive firewalls and proxies. Using an arbitrary protocol over a randomly chosen port is not going to work. So is using polling the only way to go?

One way out of this conundrum might be to use something I've christened SLoPIS (pronounced: sloppies) - for Slow LOading Pages of Infinite Size - in a moment of whimsy.

What your client will do is issue a GET command to a particular URL, which will be generating the actual call-backs. The server starts to send back a 'page' with any queued events or a ping every 5 seconds to keep the connection alive. To any entity in the middle, the page simply appears to be very large and very slow loading, but not otherwise unusual in any way.

So lets say I have a REST based file system or something and I want to be informed of any file changes on the server. I can open up a connection to http://some.filesystem.com/SLoPIS/filechanges which is, lets say, a Java Servlet on the server. As part of the request I send my authentication data and the server responds with the any queued events. e.g.

<html>
<body>
DELETION: /mnt/some/file
...

If there's nothing to report for awhile and the connection is in danger of timing out, it'll send a ping, like so:

...
PING
...

to continue the downloading of the 'page'.

Now this isn't a true call-back, because the connection has to be initiated by the client, but for most applications I can think of, this is not really such a problem. To receive, the client just keeps an ear to the sloppy and reacts to any events sent over it.

So no more issues with firewalls or proxies and no need to create a special hole in them to get your application to work! :-) I can see this being very valuable for AJAX based web-apps.

There can be issues with load and running out of ports from a client source IP if there are a lot of NAT'ed users coming in from the same IP, so it's not a perfect solution. However, it may be more appropriate than polling in many situations.

On Ennui (on-we)

2005-12-15T15:45:00.000+05:30

"This is the basic state of the creative soul when work has no meaning and brings suffering. In this state, employees feel they are doing the same things day after day. They repeat the same tasks, fill out the same forms and talk to the same people. They work in an environment they cannot change. They are merely the executors of other’s projects. They believe their bodies are the extension of other people´s minds.

In this stage, employees are not supposed to be creative. Don’t think, just do it! They are told. They don’t feel their work is important because they feel replaceable. Finally, they are not satisfied with what they do. When someone spends half their life doing something they don’t enjoy, it impacts their soul. Indeed, it has a deep impact.

This is the stage of Sysiphus. Sysiphus was a character of ancient Greek mythology. He represents two states of the soul at work: suffering and lack of meaning. Albert Camus explained the fate of Sysiphus with these words:

“The gods had condemned Sisyphus to ceaselessly rolling a rock to the top of a mountain, whence the stone would fall back of its own weight. They had thought with some reason that there is no more dreadful punishment than futile and hopeless labor”.

But the soul tends to move. It is like a river that always finds a channel."

-- The Life Cycle of the Creative Soul

A tag based file system (with Bayesian Auto-tagging)

2005-12-14T15:54:00.000+05:30

So having been foiled by OmniDrive in my desire to create an Internet based virtual drive, I've moved on other, perhaps greener and defintely less populated pastures.

If you'll remember, I spoke about adding tagging support to the virtual drive I was talking about. I said that we could "... add tagging support to the virtual drive. You can tag files and folders and view virtual 'tag' folders with links to those files. Mainstream OS's don't have a tagging mechanism for files, so we'll have to add meta-data through file names. e.g. end file names with a special character and the tags (i.e. myfile.txt#work,proposal,text) which will be stripped off before being saved to the virtual drive."

I won't be working on the 'Internet' part of the virtual drive, but I can certainly implement this idea. Why not create a FUSE based file system with tag based virtual folders? Use either folder names (/mnt/tagfs/here:are:some tags/myfile.txt) or file names (/home/user/myfile.txt:here:are:some tags) to add tags and then use virtual tag directories to navigate through those tags? You can use mv to change the tags associated with a file etc.

In addition, we can have a Bayesian Auto-tagger which learns which tags you've previously used for files of a certain type and then automatically tags them appropriately if no tags are supplied. The more you tag, the better the auto-tagger.

Who knows, I might decide to run with this one! :-)

The saga continues...

Relevant links:

Flickr FS - FUSE based. Supports Flickr tags
Del.icio.us Style File Tagging - Some nice ideas and comments
Microsoft's WinFS - Much more than just tagging... but no actual tags either

Another one bites the dust

2005-12-12T17:50:00.000+05:30

No sooner do I start thinking about a globally accessible, scaleable, encrypted virtual drive that someone announces their intention of releasing just such a product! :-(

Check out OmniDrive. Pretty much what I was aiming for. They've even got their eyes set on Google and have a very interesting blog entry on The Economics of Online Storage.

Well, back to the drawing board! :-)

The Fine Art of Programming

2005-12-09T13:21:00.000+05:30

A fine and growing collection of online programming guides and such. A link worth saving and revisiting.

A virtual drive in every pot

2005-12-08T15:38:00.000+05:30

I've been mulling over the idea of a virtual drive on the Internet for some years now. Witness my ham-handed efforts at http://zfs.sourceforge.net for an early example. Well, I recently resurrected the idea of writing something like it now and it's interesting to see how my thoughts have evolved.

ZFS as I initially envisioned it was to be a network of automatically replicating file servers and the use case in my mind was a university file server. There would be a mapping of many users to a single (virtual) server, with the system (internally a cluster) having to scale to handle as close to an infinite number of users as possible.

Lately, I've been thinking more along the lines of writing a 'Net Drive' type application. A virtual disk I can mount from any machine connected to the Internet and treat as a local drive. Companies like xDrive and iDrive and MangoSoft already offer something of the sort. However, their offerings are targeted more towards the business user. I personally feel there's a massive untapped market of casual users who might be interested.

Imagine having 1GB of space available to you online and directly accessible via a virtual drive. Directly save documents, media files etc. to the virtual drive and access it from anywhere through another computer with the same drive mounted in or through a web interface. Share your password with several people and have them save in the same drive if you wish, give them a URL to the data on your drive or just share certain folders. Boom, you've just eliminated the need for a hard disk on our PC. Internet appliances, here we come!

This type of application would be ideal for someone like Google to create and I can see them stepping into this field sometime soon. It's a classic Google app. You need to scale almost infinitely, but that's easy because you can create slices of the virtual resource and limit the number of users accessing each slice. Want to support more users? Add more slices.

Take Gmail as an example. It's probably got hundreds of millions of users, but unlike the University use case, the users have a many to many (or from another perspective, a one to one) relationship with the system. That is, unlike university students, gmail users are not interested in checking other people's mail or accessing a common email account, or even sharing their email account. This makes it much easier to slice up the virtual space, assigning a limited number of users to each slice and scaling the slices. So Gmail is probably made up of thousands of individual computers, each supporting let's say 1000 users, fronted by an authentication cluster. When a user wants to log in, he goes to gmail.com, is authenticated and then redirected to the individual machine he shares with 999 other people. If you want to add another 1000 users, plug in another machine. You can keep scaling horizontally till infinity for all practical purposes. The authentication datastore will eventually become a bottle-neck, but you can support a enormous number of users before you hit that wall. *

If Google were making a virtual drive, they'd do something similiar. As new users signed up, they'd be assigned to different machines, upto a certain max cap. Just like gmail, users have a one to one relationship with their account. That is, they're only interested in the contents of their accounts and have no need to access anyone elses account or a common store. This makes it trivial to scale exponentially.

Now this is a great product to make and market, except for one small problem; there are already a whole bunch of people out there doing the same thing. So we need to differentiate ourselves from the pack.

One way to do that is to add tagging support to the virtual drive. You can tag files and folders and view virtual 'tag' folders with links to those files. Mainstream OS's don't have a tagging mechanism for files, so we'll have to add meta-data through file names. e.g. end file names with a special character and the tags (i.e. myfile.txt#work,proposal,text) which will be stripped off before being saved to the virtual drive. Users can also publicly 'share' tags.

Other features we can offer are:

Fast file indexing and searching and maybe even mapping/linking files to each other based on content etc.
Clients for hand-helds with disconnected operational ability
Single-click integration with Flikr, Del.icio.us etc.
Rsync based transfers

How are you going to pay for all this? Advertising. Have the virtual drive folder show text/banner ads and the website as well. Have premium accounts and dedicated machines for business users.

Who knows, I might work on this idea... or maybe not.

* Correction: It's possible to avoid turning the authentication store into a bottle-neck. One way to do this would be to have the store for a particular set of users reside on the machine assigned to them. So when you want to access the virtual drive abc.virtualdrive.com, you go to that URL and send in your username and password. If the authentication process running on that machine can't find the user, the login attempt fails.

This just leaves the DNS server as the bottleneck now :-)

PETA - People Eating Tasty Animals

2005-12-07T19:15:00.000+05:30

If God didn't want us eating animals, why did He make them out of meat? :-D

A couple of friends and I were discussing the various methods used to slaughter animals (over lunch, when else) and we got to talking about the Halaal method (where a stroke through the neck severs every vein, artery and the wind-pipe, but leaves the spinal column intact) versus the Jhatka method (lit. jerk - where the animal is decapitated in one stroke). The debate revolved around which method caused the least pain to the animal, with most people automatically assuming that the Jhatka method was more painless.

I disagree.

In both methods, the animal eventually becomes unconscious due to a lack of blood going to the brain and the resultant drop in blood pressure. In the Jhatka method, since the animal is decapitated and the head is no longer attached to the body, we don't see the animal kick about and grunt as animals being slaughtered are wont to do. However, the sensation of 'pain' is interpreted by the brain and as long as that is active, the animal will suffer. The head being separated from the body doesn't make any difference.

Since in both methods, the blood flow is disrupted and in one we have the additional pain of the spine being cut through, the Jhatka method should logically be the more painful of the two, with the added disadvantage of not keeping the heart going for as long as possible to clear out as much of the pathogen carrying blood as possible.

It's just an illusion that Jhatka is more merciful, brought on by the stillness of the decapitated animal corpse. A final verdict awaits the time when it will be possible for us to measure and quantify 'pain' as a value...

Hungry kya? :-P

SQL Injection and XSS Attacks

2005-12-06T17:01:00.000+05:30

Some topics everyone involved in web development must read at least once:

SQL Injection Attacks by Example - It's a lot easier than you think. And yes, you customers will try it out some of the standard approaches out of idle curiosity if nothing else.
Real World XSS - You'll be surprised at the sites which are vulnerable to attacks of this nature.
More XSS
And still more XSS

Mark Cuban - Success & Motivation

2005-12-06T11:54:00.000+05:30

Blog Maverick - The Mark Cuban Blog

In Essence:

Be driven
Know the industry you're in, inside out.
Use 1. and 2. to ensure you're ready when Lady Luck strikes.
You only need to be lucky once...

Cuban comes across as an intense, driven, workaholic; kind of like my current (successfully entrepreneurial) employer :-D. It's a bit depressing to think that the only way to free yourself from the chains of a 9-5 life, is to handcuff yourself to a 00:00-23:59 one!

ColorMatch Redux

2005-11-18T15:38:00.000+05:30

Thanks to this, I can now tell which shirt will go with which trouser.

Breakthrough!

Slacker Manager: Full frontal personal marketing assault

2005-11-15T19:22:00.000+05:30

I'm always interested in reading about innovative interviewing techniques and this post from the Slacker Manager is really interesting.

An innovative way to stand out from the crowd without using cheap gimmicks or tricks. Nice.

Corporate Cargo Cultism

2005-11-15T16:55:00.000+05:30

"In the South Seas there is a cargo cult of people. During the war they saw airplanes with lots of good materials, and they want the same thing to happen now. So they've arranged to make things like runways, to put fires along the sides of the runways, to make a wooden hut for a man to sit in, with two wooden pieces on his head to headphones and bars of bamboo sticking out like antennas--he's the controller--and they wait for the airplanes to land. They're doing everything right. The form is perfect. It looks exactly the way it looked before. But it doesn't work. No airplanes land." -- Richard Feynman in "Cargo Cult Science"

Acting like a large corporation will not make you one. The trappings of such companies - the meetings, the excessive documentation, the blind insistence of following process and damn the consequences - are a by-product of becoming successful and large, not their cause. It can in fact be argued that many large companies are actually diseased, paralysed by their size, their culture of CYA and their unwieldy processes.

No wonder then that mega-corps that still retain their drive and ambition are looking to inject some much needed small company vibe into their moribund veins. They want the agility, the passion and the personal touch that only a smaller company can provide.

So if you're a smallish company, don't blindly adopt the practices of the big boys simply because that's the way they do things. They do things the way they do because they have no choice. It's difficult to maintain the personal touch when you have a team of 1000 under you, and you need the reams of documentation when both the product and the team size is massive.

Companies like Apple and especially Google know how to retain the common touch. While the press releases of Microsoft look like they've been written by Borg drones, Googles communiques read like they've been written by the actual people behind the product. People who are genuinely excited and happy about releasing something they've worked on and sweated over and believe in. Real people.

Free flowing information and passion is what makes small, committed start-ups such great places to be. Don't stifle the life-breath of your organisation by trying to be excessively professional and all grown up.

You can make your little firm look like a flake off of a blue chip, but it's not going to make the airplanes land...

GTD TiddlyWiki

2005-11-14T14:23:00.000+05:30

This has got to be the flat-out, most mind-blowing thing I've seen all month!

A fully functional wiki in a single, standalone page of HTML. Using the magic of Javascript and CSS, the authors have managed to make a complete application which requires nothing more than a modern browser to operate. Just save the empty template to your own computer, double click it and away you go!

It's got regex incremental searching, tagging, snazzy animations... the works. It's replaced my text only todo file habit of several years and that is quite a milestone. It's got some basic keyboard shortcuts which make editing your entries (or tiddlers) quite easy. Since it's HTML, you have the ability to create links, add formatting etc. which isn't possible with a plain ol' text file natch.

It's got all the advantages of a text file (free form, completely portable, searchability) plus a whole lot more. Absolutely fantastic! :-)

It's derived from TiddlyWiki so you can use the original instead of the fork if you want.

The 3 Urinal Salute

2005-11-07T21:32:00.000+05:30

Pass by the urinals in the office loo and *gush*, *gush*, *gush*, you just might be greeted by a volley of cheerful flushing. The urinals spot the presence of what they think is a satisfied user and smugly activate their self cleaning mechanisms...

Nothing like a 3 urinal salute to make you feel appreciated; and a little moist.

Introducing the Non-intuitive Manager

2005-11-07T20:49:00.000+05:30

In this series of articles, I want to explore some of the practices we as managers follow because instinctively, we think they're effective. Unfortunately, a little experience and thought quickly shows that many of these practices are actually counter-productive and occasionally, down right destructive.

People spending far too much time chatting on the intranet? Log every key press and word sent across! Getting the feeling that people are wandering the halls with far too much abandon? Restrict access to the various parts of the office! Want an update? Drop in unannounced and demand it on the spot!

The basic problem is that of a lack of empathy. We forget - usually because it's been a while since we've been in a similar situation - how we'd feel if placed in the same spot as the one we've just stuck someone in. At other times, we lose sight of the fact that not everyone comes from a similar background as us, and so an incident which we may shrug off as being insignificant may actually be taken quite seriously by others.

As straight-forward as the problem is, it's solution is simpler still. Just about every philosopher, religious figure and ascetic has expounded some version of the Golden Rule; Do unto others as you would have done unto you. In other words, place yourself in the situation of your hapless team members. Would you like to have someone breathing over your shoulder, eyeing your every move? Or tracking every keystroke of your messaging activity? Probably not. And if something like this would make you uncomfortable, chances are, it makes other people uncomfortable as well.

There is a danger here though. Not everyone is the same. As I mentioned earlier, people come from varied backgrounds and have varied expectations and tolerances. For example, behaviour that you might consider intolerable micro-management might be comforting to someone who's less sure of himself and wants a little hand-holding. You have to make allowances for things of this nature and that's where experience helps, I suppose...

Anyway, that's why I decided to name the series, "The Non-intuitive Manager" since good management is sometimes about going against what your gut tells you is the right thing to do. You can't always rely on your intuition or your instincts to guide you, since these are often completely off the mark. If managing was something that came naturally to most people, there wouldn't be so many horror stories about the "supervisor from hell". The only way to be sure about what you're doing is to test things out and then measure the effects.

The only way to be sure that what you're doing adds to the teams well-being and overall happiness is to implement your policy and then see if it's had the desired effect. If so, continue to refine it, taking constant feedback from your ~~victims~~ team members as you go. If not, take suggestions and feedback and try something else. You have to implement a constant loop of innovation, testing and feedback if you want to be sure that what you're doing is having the desired results. Relying on whims and fancies and ruling by decree is for tin-pot dictators...

It isn't the Non-intuitive manager you've got to be worried about, since he understands the dangers of relying on instinct. It's the natural, intuitive ones who are completely confident about their inherent talents who are terrifying!

Articles in the series

Resume Writing 101

2005-10-20T20:17:00.000+05:30

So my cousin is thinking of hopping employers and sat down to update his resume a while ago. While going over his efforts, I was struck by a rather obvious 'insight'; a resume is just a marketing document!

I can only blame my complete stupidity for not having thought of this before. All this time, I've always thought of the resume to be, well, a curriculum vitae. A summary of one's education, professional history, and job qualifications... as Answers.com puts it. A numbered list of enraged ex-employers, dubious educational institutions and dodgy projects to be paraded before incredulous HR drones. A stack of paper, with as dense a mass of black on white as possible. Something to win your next assignment with by boring - or more satisfying still - bludgeoning, the opposition to death.

However if you really think about it, a resume is really the first step is marketing that most desirable of commodities.

You.

Like any good marketing campaign you've got to not only provide accurate information, but also dress it up in a manner that attracts and excites. Let's face it, there's not much difference between a good resume and what's on a packet of chips. You've got the ingredients, the promotional puffery, the endorsements by trusted spokespersons... What we've got to learn is what makes people buy one brand and not another. Especially since at heart, all they're really getting is some sliced, salted spuds and a warm feeling that's just impending indigestion.

It's - to a large part - all in the presentation.

So apply standard marketing techniques to your resume. Identify your target audience. Satisfy HR enough to get by their buzzword filter. Stand out enough so you're noticed by first level decision makers. Give HR their alphabet soup of acronyms and certifications, but make sure the tone is such that it also catches the attention of your (you hope) new superiors.

Write your resume taking into account the kind of company and industry you're aiming for. Be edgy and provocative if you're targeting a hipper crowd. Stay a little more conservative if you want to be a banker or accountant. Remember though, it's better to be specifically rejected than simply ignored. If you make something that some people hate, then others will love it. Design to elicit emotional responses. It's better to be hated than to not to make an impression at all.

Think of using colours, textured paper, blurbs from past employers/superiors, innovative designs... whatever. The people reviewing your resume plow through hundreds of boring CVs a day written by earnest hopefuls. You have to make an impact if you're going to get an invite to an interview...

...which is a whole 'nother packet of chips.

The Non-intuitive Manager: The Semantic Weight & Half-Life of Words

2005-10-03T11:56:00.000+05:30

[You might wish to read the Introduction to the Series before you proceed...]

Words matter. A lot.

How you phrase something makes a big difference, especially when you're talking to people who are technically your subordinates. Now, this may seem like the most obvious statement in the world, but it's surprising how often it's forgotten.

What we tend to forget is that when the boss speaks, his words are mined quite intensely for subtleties and hidden meanings by his subordinates. A simple "Hello" might send some of your more insecure underlings into a panicky tizzy. Now this might seem unfair to you, but that's just the way things are. Human nature isn't slated to change anytime soon, so you might as well get used to it, bugs and all.

The problem is a basic one of power. The bossman has it, the wage-slave doesn't. The managers whims directly impact the average workers life in measurable ways, while things don't quite work vice-versa. It isn't surprising then that the communication flowing from the top is analysed much more obsessively than you expected it to be.

In other words (HA!) we need to examine...

The semantic weight and half-life of words

Description: You words and opinions, even ones joking expressed, are examined much more deeply for nuances than you'd like. Often, your subordinates build-up their stances or expectations on utterances which were hasty, or meant to be taken lightly. What seemed like banter to you, was taken as a reprimand; or your flippant remark about a company product has made people treat it lightly.

The Problem: People are apprehensive in nature. Real or perceived power resides in you in this relationship, not them. In addition, you're looked at to provide leadership and direction. People will emulate your stances and align their positions to the ones they think you hold. In addition, there's no expiry date on words, so something you said 6 months ago may still be shaping the teams perceptions about itself, the product or the company, long after the situation has changed.

A Possible Solution: Being aware of the issue is halfway to solving it. You have to be very careful with what you say. Your heart should be behind your tongue, as it's sometimes put, not before it. There's no need to be fake, or a bland, emotionless robot. Joke and josh around with your team with abandon, but remember the limits. Don't put anyone down, even in jest and never denigrate an in-house product or another team.

Having to be so careful may seem like an over-reaction.

But words matter. A lot.

The Non-intuitive Manager [How doing what seems 'right' can be counter-productive]

2005-09-28T12:21:00.000+05:30

[You might wish to read the Introduction to the Series before you proceed...]

Managing people is easy.

Managing people effectively is not.

If managing people were easy and intuitive, Dilbert wouldn't exist. The fact that a cartoon strip about a disaffected white collar wage-slave not only exists but is widely read by the cubicle classes, is telling. Everyone knows or has worked under at least one PHB or been bombed by a wandering Seagull Manager, even other PHBs and SMs!

Of course, no one sets out to become a bad manager, so how come the corporate world is chock full of them?

The problem is fairly insidious. It seems to be that when people think they're doing the right thing, they're usually not. Our intuition about what is constructive behaviour is very often wrong.

A classic example is what I'll label the gratuitous walkabout:

The Gratuitous Walkabout

Description: This involves the manager in question sauntering up to his unsuspecting target on padded feet and ambushing him with a cheery "So, how're things going?". The surprised subordinate turns around and tries desperately to collect his thoughts, mumbling senselessly in the mean time. By the time he's managed to context-switch successfully, he's already succeeded in making a fool of himself and the manager has moved on in search of his next kill, smiling ruefully and shaking his head. Bonus points if he manages to squeeze in a heavy I-really-expected-better-from-you sigh.

The Problem: It's difficult for most people to instantly switch from problem solving mode to reporting mode, especially when they're tense and on the back foot from being surprised. Someone working hard at his job will find it difficult to context-switch and swap in the information required to answer your questions accurately and fully. Nervousness from being under the microscope doesn't help.

A Possible Solution: Instead of pouncing unannounced on your subordinates, it might be better to set up a regularly scheduled meeting to which they can arrive ready and prepared. Even giving someone a 5 minute warning before you go to meet them should be enough, if all you're looking for is a daily update. If you must insist on surprising them, then make some small talk for a few minutes to give them time to ready themselves and only then get down to business.

Ruby: Not quite as shiny as one would hope.

2005-04-07T13:27:00.000+05:30

Right, what with all the hysteria surrounding Ruby on Rails , I decided to give Ruby and RoR a bit of a whirl.

I was quite disappointed with the almost vertical learning curve of Zope and quite open to abandoning Python and defecting to the dark side of the force. Matz rasping "I am your father..." after he's lopped off your hand can do that to you :-P

So any, after around a week of reading, I'm back in the Python camp and on my knees begging for forgiveness and integration back into the Hive.

What happened?

Ruby happened.

So what's this short foray into enemy territory taught me?

A. The positives.

Ruby has a lot going for it. Its OOP mechanism are much cleaner than Pythons and closures are cleaner and feel more expressive. In addition, the language supports threading, which is great. JRuby is under active development, unlike the recent history of Jython (although that's changed recently with the reactivation of that project with a fresh infusion of blood (and cash!)). The .. and ... are handle stuff sweetly in for loops too.

The community's great and the platform is still far from being fully formed, so your opinions can actually help direct the future of Ruby.

B. The negatives.

Ah, now we get to the meat of the matter. Wait, I'm going to need a numbered list for this :-D

Magic variables: I left Perl and joined up with the Python camp because I hated stuff like $_, $1, $2, $foo etc. I know it's possible to avoid using these in Ruby, but not everyone's as fastidious as I am and reading this kind of code leaves a bad taste in my mouth.
Crap variable names: $why $do @I have_to @@Name $my variables LIKE @this? $pare $ME!
Verbose block delimiters: What exactly does one gain by using BEGIN..END versus {..} or significant indentation?
Weak Libraries: One of the greatest strengths of Python, Perl, Java and other mature languages/platforms is the vast array of easily accessible libraries. It makes coding up a useful application quickly very easy. Ruby's lack of robust industrial strength packaged libraries is a major failing.

You'll notice that points 1..3 relate directly to syntax. I know the niggles seem a little petty, but things like this do matter when your coding. I want something I'm going to be interacting with for several hours everyday, to be smooth and pretty. It's something which is important to me and I'm sure to a lot of other people out there.

As for Rails... I admit that I haven't really gone all that deep into it, but that's because even a cursory examination revealed it to be heavily magical. Far too many things just 'happen' and although it may speed up initial coding, it will come back to bite you later. Besides all the squealing about 10x improvements in productivity remind me of Fred Brooks essay, No Silver
Bullet. Some one should send the RoR cheerleaders a link.

And I've discovered frameworks other than Zope for Python.

More on that later.

Maybe...

:-)

Groovy!

2005-02-24T15:34:00.000+05:30

<austin powers> Yeah baby! </austin powers>

:-D

Groovy's, well, reeeeeally groovy dude. It's a Pythonisc scripting language which is designed to run on the Java 2 Platform and which is instantly intuitive for Java programmers. It's got native lists and hashes, closures, loose typing and inbuilt regex. If you know Python and Java, you'll be up and running in a few minutes.

Groovy really cuts down on the lines of code required to get things done. No need to declare variables, easy to use for loops and inbuilt list types (with slicing, ranges etc.) reduce code clutter. It's not magic, but a definite improvement on vanilla java.

Since it runs on the JRE, it's got access to Java's "everything and the kitchen sink" library and since it compiles to java byte code, you can call groovy code from within your java classes and vice-versa. Plus, you can run groovy on it's interpreter for easier debugging and testing.

What's the catch? Well, it's still under development and the specs are fairly fluid apparently. However, they've submitted Groovy Java Specification Request 241 to the Java Community Process Program and if JSR 241 is accepted, Groovy will be an official standard.

Final Word: It looks absolutely fantastic, but I'm not going to use it for anything serious till it's standardised. Besides, it's marked as unstable on Gentoo ;-P

Bob Parsons 16 rules.

2005-02-10T20:59:00.000+05:30

Bob Parsons 16 rules for success. Quite cool actually. I've pasted them here for easy reading.

The points I found particularly interesting are in red.

1. Get and stay out of your comfort zone. I believe that not much happens of any significance when we're in our comfort zone. I hear people say, "But I'm concerned about security." My response to that is simple: "Security is for cadavers."

2. Never give up. Almost nothing works the first time it's attempted. Just because what you're doing does not seem to be working, doesn't mean it won't work. It just means that it might not work the way you're doing it. If it was easy, everyone would be doing it, and you wouldn't have an opportunity.

3. When you're ready to quit, you''re closer than you think. There's an old Chinese saying that I just love, and I believe it is so true. It goes like this: "The temptation to quit will be greatest just before you are about to succeed."

4. With regard to whatever worries you, not only accept the worst thing that could happen, but make it a point to quantify what the worst thing could be. Very seldom will the worst consequence be anywhere near as bad as a cloud of 'undefined consequences.' My father would tell me early on, when I was struggling and losing my shirt trying to get Parsons Technology going, "Well, Robert, if it doesn't work, they can't eat you."

5. Focus on what you want to have happen. Remember that old saying, "As you think, so shall you be."

6. Take things a day at a time. No matter how difficult your situation is, you can get through it if you don't look too far into the future, and focus on the present moment. You can get through anything one day at a time.

7. Always be moving forward. Never stop investing. Never stop improving. Never stop doing something new. The moment you stop improving your organization, it starts to die. Make it your goal to be better each and every day, in some small way. Remember the Japanese concept of Kaizen. Small daily improvements eventually result in huge advantages.

8. Be quick to decide. Remember what the Union Civil War general, Tecumseh Sherman said: "A good plan violently executed today is far and away better than a perfect plan tomorrow."

9. Measure everything of significance. I swear this is true. Anything that is measured and watched, improves.

10. Anything that is not managed will deteriorate. If you want to uncover problems you don't know about, take a few moments and look closely at the areas you haven't examined for a while. I guarantee you problems will be there.

11. Pay attention to your competitors, but pay more attention to what you're doing. When you look at your competitors, remember that everything looks perfect at a distance. Even the planet Earth, if you get far enough into space, looks like a peaceful place.

12. Never let anybody push you around. In our society, with our laws and even playing field, you have just as much right to what you're doing as anyone else, provided that what you're doing is legal.

13. Never expect life to be fair. Life isn't fair. You make your own breaks. You'll be doing good if the only meaning fair has to you, is something that you pay when you get on a bus (i.e., fare).

14. Solve your own problems. You'll find that by coming up with your own solutions, you'll develop a competitive edge. Masura Ibuka, the co-founder of SONY, said it best: "You never succeed in technology, business, or anything by following the others." There's also an old Asian saying that I remind myself of frequently. It goes like this: "A wise man keeps his own counsel."

15. Don't take yourself too seriously. Lighten up. Often, at least half of what we accomplish is due to luck. None of us are in control as much as we like to think we are.

16. There's always a reason to smile. Find it. After all, you're really lucky just to be alive. Life is short. More and more, I agree with my little brother. He always reminds me: "We're not here for a long time; we're here for a good time."

And oh yeah, he insists I print the following...

"The above (or following) article (or rules for survival) is included with the permission of Bob Parsons (http://www.bobparsons.com) and is Copyright 2005 by Bob Parsons. All rights reserved."

AAAARRGGHH! Someone's got 'my' domain name!

2005-02-05T15:38:00.000+05:30

Picture this. You've just been hit by a absolute corker of a brain wave. The product idea looks good, the market is wide open and there's quite a bit of pent up demand. You've also got an excellent, catchy name all picked out. It's easy to use, it's 'punny' and it rolls right off the tongue. It's brilliant!

So you log on to your friendly neighbourhood domain name reseller's and check if it's available...

It's not.

Cue the screaming, tearing of hair and purposeless running around. And to make it just that bit worse, it's pointing to some chintzy site which looks like it hasn't been visited since the Middle Ages (2000 CE). Damn, you could twist that guy's head right off!

But wait! There's hope!! You check the whois records; the domain expires in two months!!! Will the current owner renew it? Won't he? Should you splurge for the domain on SnapNames or buy it for much less manually?! Will you run out of '!'s before this post ends?!

Oooooh, the agony!

Watch this space for updates! :-P

LBB Lesson - 2. Don't give up that day job!

2005-02-04T09:59:00.000+05:30

Entrepreneurs are by nature optimistic, risk-taking, the-glass-is-half-full type people. You can't be anything else if you're going to start a business. Usually, this is absolutely great! It's this kind of an attitude that gives you the ability to slog on, with unwavering self-confidence when the chips are down and the outlook looks bleak. However, it's this very attitude that tends to blinds us to certain ground realities...

Namely, that it's going to take far longer to achieve profitability (and a living wage!) that you might think.

Thinking of starting a new venture? Make as pessimistic an estimate as possible about how long it's going to take for you to start making some decent dough... Now triple that span and maybe you're in the same ball-park as reality.

So you're going to need a steady revenue stream while you develop YATE (Yet Another Text Editor) or whatever. Of course, holding down in effect two jobs at the same time is going to be challenging (to say the least!), but whoever said shedding the fetters of wage-slave-hood was going to be easy?

You could live off your savings, however, continuing to work for someone else (either as an employee or a consultant) while you plan your own independence has some other, very important advantages:

Networking: I think I've mentioned this before :-). In a nutshell, working alone can be injurious to your mental wellbeing! Well, OK maybe that's an over-reaction, but spending a lot of time obsessive working on The Next Big Thing isn't very healthy. In addition, if you cut yourself off from your peers, you're going to miss out on all those opportunities to make friends and influence people; the very people who might help you find the next, Next Big Thing.

And I'd like to remind my reader, that when I use the word networking, I don't mean the slimy digging for contacts so beloved of sales people, but genuine friendships, based on mutual respect and affection...

Inspiration: If you're cut off from potential customers and users, you're cut off from potential ideas for new products and features. You can't scratch someone's itch if you don't know they're itchy! Constant (maybe even grinding) contact with a multitude of clueless users is what's required to sensitise you to their situation. Cutting yourself off from them (and that's what's going to happen when you concentrate all your efforts on making and selling your products) is going to leave you the poorer for missing out on all that aggravation :-P

Synergetic Partnerships: Who knows, while working for your current employer, you might get an idea for a product that complements his current spread of offerings, but isn't something he's interested in developing. He might however, be open to bundling your app with his or buying it outright.

However, keep in mind that there is a fine ethical line that has to be trod here. It's fine to come up with something complementary or to inspired by some chance remark while on the job, it's definitely not OK to rip off your employers ideas or products.

So that it. The lesson to take away from here is that unless you've perfected the art of living off of air, you're going to need a steady revenue stream while you work on your product. You're going to have to work very hard, but hopefully, the rewards will be worth it.

You hope.

Webcream: The dynamic Java/Swing to HTML converter

2005-02-03T18:28:00.000+05:30

Webcream is like a car-wreak. Compelling and repulsive at the same time. It's a product that gives your Java/Swing app an HTML face, letting you put it up on the web with a minimum of code changes. That's absolutely fantastic! Unfortunately, it does this in an astoundingly ugly manner.

Take a look but I warn you, it ain't pretty.

It's an excellent idea, but I'm positive it can be implemented a whole lot better than it currently is. You'd think for the amount they're charging, they'd do a better job of it but I guess what they need is some competition to light a fire under them. Currently there isn't any, but when there's only one provider, there's always place for one more.

SQLite: An embeddable database

2005-01-21T16:45:00.000+05:30

OK, this has been written about by others, but it's so cool, I had to mention it myself!

As the home page explains, "...SQLite is a small C library that implements a self-contained, embeddable, zero-configuration SQL database engine.." It's ACID compliant, the data files are portable across different machine architectures, it can handle respectable amounts of data (up to 2 TB) and it comes with Python bindings. :-P

It's seems like a great way to store application data without having to force users to install MySQL/PostgreSQL or hacking up a custom (probably buggy) solution.

I can't wait to use it!

Tile: an improved themeing engine for Tk

2005-01-09T15:53:00.000+05:30

Tk is gag inducingly ugly, but Tile shows us that it doesn't have to be.

Here's what Tk usually looks like:

Here's what Tk with Tile looks like in WinXP:

Impressive.

Read more about it on the wiki and see here for an example using Python.

Well, I'm back!

2005-01-06T17:38:00.000+05:30

The wedding's over and I'm back in the splendidly polluted 'chity' of Mumbai once more! I hate being wrenched away from my computer, but I must say I enjoyed the break. Two weeks of 0 productivity and almost no contact with tech... Heavenly! :-P

Anyway, expect more regular updates from now on...

Achates Take a Break!

2004-12-21T23:57:00.000+05:30

Finally!

I'm out with Achates Take a Break!. This app has been hanging around on my computer in a 'nearly' finished state for a couple of weeks now and I finally pushed it out today.

Part of the reason I knuckled down to it was that I'm off for a week for my cousin's wedding (so no updates for a while!) and I wanted to finish this off before I left. Just 7 hours or so till I catch my train, and I haven't really started packing yet! :-P

<white rabbit>I'm late! I'm late!</white rabbit>

BTW, you might want to subscribe to the RSS feed to get the latest updates when I return...

RAD with Python, wxPython and Boa constructor - Part 3

2004-12-21T01:42:00.000+05:30

Here's the third essay in a three part series on using Python, wxPython and Boa Constructor to rapidly develop cross-platform desktop applications.

Last time, we discussed wxPython, the GUI toolkit we're using to create rich, cross-platform user interfaces from Python. Now wxPython is great, but like almost all such toolkits, it's a royal pain to code up an interface using it. The code which deals with creating and managing the UI is usually very verbose and it's boring, tedious work. The drudgery of trying to get your buttons set up just so by repeatedly changing the relevant positioning variables and running the script, is positively mind numbing. What we need is a way to graphically setup the interface and have the code to recreate it generated automatically...

Enter Boa Constructor (just Boa from now on).

To quote from it's website, Boa is "...a cross platform Python IDE and wxPython GUI Builder. It offers visual frame creation and manipulation, an object inspector, many views on the source like object browsers, inheritance hierarchies, doc string generated html documentation, an advanced debugger and integrated help..."

Pretty impressive.

So what's to like?

GUI Construction - This is the main reason I use Boa. Create a new frame, click on frame designer and away you go. Drag visual elements like list boxes, buttons and text areas in and throw them around until they look the way you want them to. You can access the attributes of the various visual elements by bringing up the inspector and change just about everything to do with the widget. You can also automatically generate place-holder callback functions and fill them up with the relevant code later. Boa really makes GUI construction a breeze.
Code Exploration - Boa comes with some nice tools that help you explore other people's code; or your own if you're as lazy about commenting as I can sometimes be! :-). Just open up the .py file and tab over to Explore in the editor and you can browse the various classes and their attendant methods. Mosey over to Events and you can check out the various events handled in that file as well.
Skeleton Files - Boa generates a wide variety of skeleton files which help reduce the amount of tedious typing you have to do. You can generate everything from wizards to setup files to help files, all at the click of a button.
Debugging - Boa has extensive support for debugging Python code. However, python is so easy to use that I've never had to use a debugger to solve any problems. Yet :-P.

So much for the cheerleading.

Boa is currently at version 0.3.1-alpha. Now version numbers hold very little meaning across applications. I trust FireFox 1.0 a hell of a lot more than I trust Internet Explorer 6.0. Boa is fairly stable and useful, but it does have it's short comings.

Ugly - Boa is ugly enough to make children cry, horses faint and women snort and rear up, pawing at the air. OK, that may be a little harsh... but it is pretty damned ugly. Now I know that shouldn't make a difference. Book covers and internal beauty and all that PC crap. But personally, I like working on applications which don't remind me of the bleeding, infected sores on a lepers back.
Doesn't support latest version of wxPython - The official stable release of wxPython is still version 2.4.2.4. However, wxPython version 2.5 is stable enough to use regularly and has some nifty new features. Unfortunately, Boa refuses to work with 2.5 so all that's out.
So-so editor - One of the main modules in any IDE is the code editor. It has got to be perfect, or as close to perfection as you can get... and Boa's just can't hack it. Now that's partly my fault. I'm an Emacs addict and it's chords are burnt into by muscle memory. When I want to save a file, I do C-x C-s without even thinking about it. Unfortunately, Boa's editor doesn't let me re-set shortcut keys, so when I do a C-a to move to the head of the line, I end up selecting all the text in the program and losing my place in the code. If it had offered code completion and other goodies, I still might have used it; but it doesn't, so I don't.
Slightly buggy - This is still alpha code. Weird 'stuff' will happen, usually when you haven't saved your code in a while.
Ugly - Did I mention that Boa is really really ugly?

Now as I mentioned in the beginning, I primarily use Boa to rapidly generate GUI code. What would take me days to do manually can usually be done in scant minutes using Boa. However, that also just about all I use Boa for 'cause I can't stand it's editor and looking at it makes my eyes bleed (which is a little surprising cause wxPython GUI's usually look quite reasonable).

If Boa isn't your cup of tea, you might want to check out Spe (Stani's Python Editor) which seems to offer similar functionality.

Well that concludes this particular series of essays. See you next time.

Same Bat Blog.

Same Bat Time.

The rising drumbeat of war

2004-12-19T15:43:00.000+05:30

It seems that Iran will be next, before Syria, which seemed like it was next in line after Iraq.

Bolting on Iran

Evildoers, here we come

Of course, Iraq proved that American military might isn't all it's made out to be. Here's how Iran will fight back

I'm back!

2004-12-11T04:38:00.000+05:30

I've been quite unwell over the last few days, but as you can see from my last few posts, I'm back!

I hope to finish off the RAD using Python series and write another article on pricing soon Inshallah. Still have to do a bit of research for that...

You'll be seeing me posting more often now, more's the pity. :-)

LBB Lesson - 1.5. The Network is the Entrepreneur cont...

2004-12-11T04:36:00.000+05:30

In Lesson 1, I covered the usefulness of networking to the budding entrepreneur. Having a useful social network however, is not just important when you're starting out, but throughout your whole business career
Now, the obvious benefit is increased sales. The more people who know you, the better your chances that you'll come across potential customers (or friends of customers etc.). However, here's at least one more reason to spend some time getting to know a diverse bunch of people, especially if you're in the software business.

The people you know from other walks of life are the best sources of inspiration, and help, when developing a new product.

Here's an example from my own experiences...

A relative of mine works in the advertising industry. One day I was at his house and right out of the blue, he asked me to suggest some software that'll help him organise and maintain his vast collection of (mostly video) media files. He often has to refer to old campaigns and ads and it would save him a lot of time if he could pull up just the file he needed.

Of course, what he really wanted was software that would 'review' the clip and file it automatically, but that's not possible yet. The alternative is of course to correctly annotate the files and sort them sensibly. Even a properly arranged hierarchal collection of folders would be enough in most cases.

However, his remarks got me thinking about the problems of the advertising and marketing world in general and before long, I was convinced that it was possible to come out with a product that could target this cash rich segment :-P

Now, I have several near relatives involved in this field, so I've picked up quite a bit of advertising/marketing lore through dinner table osmosis. In addition, these relatives (wonderful people, I must say (in case they're reading this!)) could act as advisers and beta testers, giving me insights into the industry I couldn't get elsewhere.

It was perfect. I was both inspired to produce a product which I'm convinced will do very well and at the same time I find myself uniquely positioned to create it. All because of a chance request by someone I knew.

I'm sure you can come up with other such examples from your own life. And of course, the more people you know, the greater the chances that one of them will cough up a chance remark which could inspire you to heights of greatness; or at least increased profitability :-P

...And remember the golden rule of networking from last time: Be helpful to others and others will be helpful to you!

Venster

2004-12-11T03:50:00.000+05:30

It's early days yet for Venster, but it seems worth keeping an eye out for.

I still much prefer my GUI toolkit to be portable across Operating Systems.

NSIS: Open Source installer

2004-12-11T03:46:00.000+05:30

A fairly impressive list of features and free to boot.

Looks good. I just might try this out.

Added an RSS/Atom feed using Feedburner

2004-12-05T23:38:00.000+05:30

Just click on the little "XML" button under Subscribe and you're good to go!

Never miss an update again. :-)

LBB Lesson - 1. The Network is the Entrepreneur

2004-12-05T17:50:00.000+05:30

Mao had his little Red Book, Ghaddafi has a little Green book, so I've decided to follow in these illustrious foot-steps and name my ever expanding compendium of experiences, my little Blue book. :-P

As I mentioned in my last post, I want to do this partly for my own benefit. I am quite absent-minded and I feel quite strongly the need to write down things I consider important enough to remember. A side benefit of this is of course, that other people can read up on what I've written and comment on it, benefiting us both.

So here's the most important lesson on entrepreneurship I've learnt as I've been battered by the vicissitudes of fortune...

Lesson 1 - The Network is the Entrepreneur

When you initially start up your business, it's going to take a very long time to show some returns. Your first clients are absolutely vital and are going to either make or break your business. And guess what? 9 times out of 10, your first clients are going to be people you know. They're either going to be friends, relatives, past employers or even employees. They could be your fellow co-workers from a previous job or club members. Anyone who's known you for a while and trusts you.

"...and trusts you". This really is the crux of the matter. The number one problem for the new entrepreneur is a lack of credibility. Sure, you may be offering the best service or product for the best price, but if no one trusts you to deliver, no one's going to buy. The fear of loss far out-weighs the greed for profit in most such cases. The only way you can overcome this credibility gap is if the buyer already knows you, trusts you or is beholden to you in some way.

Who are these people who trust you and like you already and who therefore are far more likely to give you a chance? They're the people you know before hand of course. And the more such people you know, the more likely it is that there are potential buyers to be found amongst them.

How do you build up such a network of interesting, friendly, useful people? By being interesting, friendly and useful of course! :-D

Give stuff away and don't expect anything in return. Not only is this recommended by just about every religion in existence, but it's the best way to network. Help people out, give them useful advice, go the extra mile; and people will respond in kind. Not all naturally, but enough.

If I remember correctly, there's a Hadith Qudsi that runs something like this (paraphrased from memory): "Do not be discouraged by people who treat you shabbily after you help them, because there will be others who will treat you far better than you deserve for helping them just a little". It all balances out :-)

Join clubs and organisations. Mingle. Hand out your visiting card at every opportunity. If you're shy, hide behind your PC and blog. :-P. Do something, anything but be among people and Inshallah, opportunities will present themselves.

A final word in parting. The people in your network are ready to give you a chance because they trust you.

Never betray that trust.

Lessons from my little blue book...

2004-12-03T20:40:00.000+05:30

Hmm...

I'm thinking about doing a series on the lessons I've learnt over the past year or so while trying to get Achates off the ground. I want to do this partly for my own benefit; it's quite easy to forget stuff that seems blindingly obvious now.

Stay tuned, I'll probably post the first in the series within the next few days Inshallah.

Comments and suggestions welcome.

RAD with Python, wxPython and Boa constructor - Part 2

2004-12-03T18:24:00.000+05:30

Here's the second essay in a three part series on using Python, wxPython and Boa Constructor to rapidly develop cross-platform desktop applications.

But first, some clarification!

The Mystery of the Disappearing Post - Part 1 of this essay pulled a Houdini and mysteriously disappeared a day after it was posted. No other post was affected. I've contacted Blogger.com support but I'm pretty sure that it's gone forever.

Since it seems we'll have to do with just part 2 and 3 of a three part piece, lets get on with it...

wxPython is just a thin wrapper around another library, wxWidgets. wxWidgets is an open source GUI framework written in C++ and is cross-platform from the ground up. It works reliably on various flavours of Unix and Windows and is generally usable on the Mac. Support for other platforms like PDA's etc. is under development.

Unlike good ol', butt-ugly Tk, wxWidgets gives you a native look and feel on every platform it runs on. User's can't tell the difference between something written in wxWidgets and another application written in MFC, for example. Both will look the same.

wxWidgets is fast, stable, well-documented and under active development. It's also free (in both senses of the word). This applies to its Python wrapper, wxPython as well.

Some of the major pluses of using wxWidgets/wxPython are:

Free! - I'm a sucker for free stuff. Especially good quality free stuff. The nearest thing to wxWidgets is Qt, and that costs big $$$$'s.
Full-Featured - wxPython is not just a GUI toolkit, it also gives you classes to handle network programming, threads and processes, image manipulation, Databases, Printing etc. This cuts down on the number of dependencies your application has.
Native Look and Feel - I've already mentioned this once, but it's important enough to bear repeating. With wxPython, your apps look like everybody else's. Many cross-platform toolkits have their own look and feel (TK comes to mind) and this tends to confuse and put off users. Others emulate the native design and just end up looking cheap. With wxPython, no one can tell that you took the easy way out! ;-P
Documentation - The documentation for wxWidgets is very complete. Unfortunately, wxPython uses the documentation of wxWidgets without any changes. This can be a bit irritating since wxWidgets is written in C++ and the docs reflect that. However, if you have even a very passing familiarity with C++ (and who doesn't?), it's enough to use the docs.
Demo Code - I really like this bit. wxPython comes with a very large collection of well-organised demos. These are simple, relatively small scripts that demonstrate the various widgets available. A great resource to learn from and an even better one to steal code from! ;-)

These were the features that I particularly liked. Go here to see even more reasons for using this great toolkit!

Just about everything has it's flaws and wxPython is no exception:

Steep Learning Curve - wxPython is very well documented... but there's very little to get you started. The few tutorials that exists just barely get you off the ground. The only real way to learn wxPython is to start up the demos, play around with them and spend a lot of time reading their code. It's not an app killer, but it's definitely something that'll put off quite a few beginners.
Documentation - There's lots of docs for wxWidgets, but none absolutely for wxPython! wxPython is just a wrapper around wxWidgets, but it's irritating to have to mentally switch between thinking in Python and thinking in C++ every time you look up the docs.
Large Distribution - If, like me, you're going to be distributing your application as an .EXE (after converting it using py2exe), the size of the accompanying libraries can be a hassle. A "hello world" app is going to go from a 10-15 byte .py script to a 2.5+ Megabyte distribution! If your users are going to be downloading your product, this might be a problem!
Verbose - Damn but you've got to write a lot of code to get anything done!

Anyway, that's all for now. Next time Inshallah, I'll cover Boa Constructor, which helps alleviate the code verbosity problem.

You can also check out Pythoncard. It's a wrapper around wxPython (which is itself a wrapper around wxWidgets (which is itself a wrapper...!)) and it makes writing wxPython apps a breeze. It's still under development and I wouldn't suggest it for a commercial app just yet. But it's definitely something to keep an eye on.

Till next time then!

Lit Window Library

2004-12-03T04:53:00.000+05:30

This looks interesting...

The Lit Window Library is a new way to write UI code, saving up to 90% of the usual time and source code... Rules (predicate, constraints) based programming to code UI behaviour with integrated constraints solver

I wonder if there's a python wrapper for this yet?

Blogger ate my essay!

2004-12-02T18:05:00.000+05:30

WTH?!!!

I submit a new post today, view the blog to make sure it looks right and I notice that my essay on Python etc. has vanished without a trace!

I have absolutely no clue where it's gone to and who or what ate it up. I've posted a complaint, let's see what comes of it.

In the mean-time, if anyone has the essay in their cache or something, could you please email it to me at arsalan_zaidi@hotmail.com?

Thanks!

and death to Blogger.com!

The Business of Software - Reading other people's code and the GPL

2004-12-02T14:31:00.000+05:30

A couple of days ago I asked the visitors on the joelonsoftware forums for their opinion about whether it was legal/ethical to read GPL'ed code and to learn from it, and then straight-off apply that knowledge in a closed source commercial app.

The consensus seems to be that it's OK, though michaels in particular said "I would say if you are reading it and implementing it again *only* because it is GPL and you can't use it as-is then it's unethical".

Read up more here and make up your own mind... The Business of Software - Reading other people's code and the GPL

BBC NEWS | Africa | US 'hurting' anti-mine campaign

2004-12-01T04:55:00.000+05:30

BBC NEWS | Africa | US 'hurting' anti-mine campaign

Why am I not surprised...

Project: The Game!

2004-11-29T08:27:00.000+05:30

Really quite funny. I'm a sucker for stuff like this...

Go ahead, click on the link. You know you want to. :-)

Project: The Game!

Procrastination and the self-employed

2004-11-29T06:03:00.000+05:30

There's probably nothing worse for procrastinators than the web...

I've been trying to get to work for the last 2 days and every time I sit down on the computer, I open up a browser window, I start checking a few links; and before you know it, 5 hours have flown by and I've got exactly 0 things done.

And every time you do this, you feel miserable, you swear you'll never do it again... but you do.

Anyway, time to stop typing and knuckle down to work... :-)

Achates Clock Sync

2004-11-27T21:31:00.000+05:30

Lest I forget, I've just recently put up the very first product to come out of my rather empty stables...

Achates Clock Sync

It does what the name says, namely synchronise your clock with the correct time. Not much, but it's a start.

What's all this about?

2004-11-27T20:56:00.000+05:30

Well, I've recently started an IT consultancy / Micro-ISV and like a lot of people out there, I've decided to write up my experiences.

Why?

Two reasons, to be honest.
1. There's no publicity like free publicity. ;-P
2. I hope that by sharing my experiences, I can encourage other people to do the same... which is great 'cause there's a lot I've got to learn!

Of course, there's more to life than just one's work, and since I'm very interested in both Religion and Geo-Politics, I'll be writing and commenting about that as well. Both subjects would have crept in anyway, so might as well make things clear from the start.

Mind you, I'm still a little skeptical about this whole 'blogging' business. In my experience, most bloggers are moronic, bile filled blow-hards who talk way, way too much. Lucky for me, I'm a bile filled blow-hard myself, so I should fit in just fine. :-P

Anyway, that's all for now. More later...

First post

2004-11-27T20:22:00.000+05:30

F1rst Post !!1!1!

Damn! But I always wanted to do that! :-)