Turkey Stuffing

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

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

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.

1. 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.
2. 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.
3. 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.
4. 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!
5. 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.
6. 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.
7. 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

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:

1. There should be no gain in shunting blame between onshore and offshore.
2. Onshore should not be allowed to ‘succeed’ by leaving offshore behind and vice-versa.
3. Onshore should gain nothing by show-casing itself independently before the client and neither should offshore.
4. Onshore should be reassured that their roles and jobs are secure and that they will not be ‘Bangalored’.
5. 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!

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:

1. 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! :-)
2. 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.
3. 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.
4. 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 ! :-)
5. 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.
6. 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.
7. 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.
8. 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.
9. Varied Projects: You don’t need to switch companies to switch projects.
10. Brand Recognition: Having to explain what your company does every time gets real old, real fast.
11. 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.
12. 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

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?

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

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...