At Multiplitaxion Inc; a bunch of programmers (me included) started what we called a 'knowledge sharing sessions' which would happen every fortnight. The idea was to exchange thoughts; talk about what we had learnt; and get inspired.

As months passed; the number of people joining these knowledge sharing sessions increased and so did the frequency of these discussions. We moved from once every fortnight to twice a week. With an ever growing audience; discussions moved from hardcore technical topics where people would program on stage; to discussions on design; abstract philosophical topics connected to project management and sometimes these talks even touched the social aspect of things.

Before we knew it; we had turned a technical session planned with a specific purpose into a general purpose discussion forum where people got together and --- well; talked; about --- anything.The little fortnightly meet of ours; dear reader; had turned from a meaningful specific into a wondering generality; and it was happening two days a week.

Now as someone who is a big time fan of TED videos and inspirational books; I completely understand the importance of inspiration. Having said that; most good inspirational book nudge you to read them and then go out there and work. TED talks range for just 18 minutes where people talk about what they have 'done' or 'built' and the entire event ends in about three days; after which you get down to real work of trying to make dents in the universe.

That is exactly what makes TED so beautiful.

We; on the other hand; were doing inspiration two days a week; and that dear reader; was a real problem. We were talking more; and doing less. Jeff Atwood describes this phenomenon rather articulately in his post about doer-or-talker. He explains:

It's an easy conceptual trip from building bridges to building software. In software, some developers take up residence on planet architecture, an otherworldly place where software is eternally planned and discussed but never actually constructed. Having endless discussions about software in a conference room or mailing list feels like useful work-- but is it? Until you've produced a working artifact for the rest of the world to experience, have you really done anything?

There is something to be said about getting ready for and then assembling for a serious meeting in a conference room. Its really easy to fool yourself into believing 'this-is-necessary' or 'this-is-important' when in reality it is nowhere in the same vicinity as 'necessary' or 'important'.

Every time you find yourself spending more time getting inspired or discussing stuff than you spend actually doing stuff and shipping things; may I suggest; dear reader; that you take a pause and indulge yourself in some serious work.

Charles Miller uses the example of open source project to illustrate the same point. He explains:

The best way to start an open source project is with code. Working code. Hack away at home on weekends, maybe get a couple of friends to help you out, and don't go public until you have something to show people that does something interesting, and that other people can use to build more interesting stuff on top of.

You need this for a bunch of different reasons: it establishes the original contributor's bona fides in the open-source meritocracy, it shortcuts all sorts of damaging debates about coding styles and architecture that can stop a project before it starts, and so on.

Most importantly, though: working code attracts people who want to code. Design documents attract people who want to talk about coding. I've seen what happens on projects that start with no code and a commitment to produce a design. Some of the procession of UML diagrams were really well put together, but that's about the extent of it.

Yes; inspiration is a critical part of moving forward and so is design but if you surround yourself with people who want to 'talk' inspiration and design all the time; without doing any real work on it; you are going to have highly scalable systems that don't exist and highly rewarding careers which produce no real meaning.

Word of advice; stop talking and ship.

If you are a programmer; slog away at a truly remarkable system; if you are an author; go ship a book; if you are a blogger; blog consistently; if you run a podcast; package and deliver it consistently.

Yes inspiration is important; but remember; it is a medicine and an overdose of inspiration can have some serious side effects.

Take the right amount of inspiration; know when you have had enough; and when you realize you have enough of it; stop; get your ass out there and slog at shipping something.

I wish you good luck.

If you are a programmer or even remotely associated with the world of software development; you have probably seen an entire team; built and function on lies. No; I am not talking about the occasional long nosed marketing weasel who lies to a customer about how much functionality your product has; and how quickly you can get stuff built.

What I am talking about; dear reader; is an entire ecosystem that stems out of the lie of one marketing weasel. Somewhere; during the life time of your project; usually even before the project starts; someone lays a foundation or a contract built on a lie; and then it snowballs from there. Before you know it; you have an entire ecosystem built to survive and thrive in an environment of lies. Jan-Erik explains this much more articulately than me. He explains:

Back when I was doing project work in the traditional waterfall way, I noticed liars all around. Developers lied about the status of their work (more or less deliberately) to the project manager, the customer lied to the project manager about how much functionality they really needed in order to use the product. The salesmen lied to the customer about how quickly the team would deliver.

It was lies all around and we where so used to it that we started to make daily routines to cope with the effect of lies . For this reason, all estimates would for example be padded with a fixed percentage and in all contracts you would find legal statements that would punish the parties if they was caught lying.

It was a cruel environment to work in. We even lied about the process we used, what we said we would do in a sales meeting was often quite different from what we actually did when we started to feel the pressure of delivering.

If you have lived the world of professional software development you can probably connect to Erick's post. Of all the things that Agile does; one of the most important things it does; is that it brings things out in the open. But even Agile; in all it's glory cannot keep the liars out of your project and your professional life if the very foundations of your project are built on lies. Jan discusses this while talking about the benefits and limitations of agile. He explains:

So, where have all the lairs gone? The lying people are still there, even in Agile teams. But it is simply too hard for them to lie and they gain too little from doing it.

Whenever it becomes easier to lie than to be honest and the immediate gains of lying is high enough, they will be back.

If you miss the times of deception and lies, please feel free to put more formalities and team separation into your process. And make sure to have lots of fixed price projects. The liars will be back before you know it.

Let's try to stay honest for a while, it feels much better than the alternative, don't you agree?

Visualize for example; the vice-president of marketing in a meeting room when a simple statement - we-can-get-this-done-in-a-month - can land him with a fixed price project worth a couple of hundred thousand dollars and you might understand how easy it is to find yourself engaging in a tiny little lie that you feel can be turned into reality by putting a just-a-little-bit-of-pressure on your team.

That's when the grand saga of lies begin which pretty much runs downhill; till the time developers give into the pressure and start looping around in the infinite loop of failure.

Look around your office hard enough; and you might actually come across a manager or two who actually want you to lie and tell them the every-thing-is-on-schedule even when it is not.

Look around your office hard enough; and you might also find developers who cannot break the bad news or give up.

Whenever it becomes easier to lie than to be honest and the immediate gains of lying are high enough; people will lie and those very lies will create broken windows that result in projects; careers and organizations coming to a slow painful end.

If you are a programmer; a manager; or a young and budding entrepreneur starting your own organization; might I present to you; dear reader; three simple ground rules that you can stick to and avoid the painful software-development-ecosystems built on lies. The rules are really very simple:

1. Do not work with clients who want you to meet unrealistic hard dead-lines on fixed time fixed price projects.
2. Do not hire managers who have a habit of estimating tasks in man-hours.
3. Do not hire developers who cannot say no and are always ninety percent done.

Yes; all of the above is easier said than done; but I have personally seen organizations that stick to these rules; and reap the benefits by building remarkable software and building meaning.

Remember; every lie in your professional life; is a broken window with the full potential of snowballing into something nasty. Go ahead; say 'no' to your manager; give your estimations in days or weeks instead of hours; fail remarkably and turn down a client who just has to get the product built with every single feature discussed; before the road show which is three weeks from today.

I wish you good luck.

During my stay at Multiplitaxion Inc; I am asked to oversee a project that folks in the management team think is not shipping as effectively as it should. I am given access to the project repository and the mailing list. By the time I close my outlook on the very first day; I see project members communicate using very different medium of communications than the ones I am used to. Somewhere; a connection seems to be missing and they don't seem to be 'talking'.

Emails --- rule how project communication happens; how tasks are assigned; how task completion announcements are made.

On the very first day in the project; I quite literally; get spammed with over a hundred emails.

Emails providing details about mundane; irrelevant facts like:

1. A programmer just checked in a couple of code file.
2. A tester is taking the local development database down for five minutes.
3. A tester is taking SVN update.
4. The local database is back up again.
5. Bug IDs of bugs that have been assigned to a particular developer.
6. Bug IDs of bugs that have been fixed and assigned to a particular tester.

People in this project; had a tendency to paste SVN logs into emails and send those out for every check-in that they did. For every piece of work that you did; for every minor assignment you completed; it was expected that you to write an email; and send it out. When you send the email you were expected to  copy the entire team.

Now; to be honest; there was nothing wrong with me getting over a hundred emails. I would have been happy deleting the emails and moving on with my life; but then a hundred plus emails in my inbox meant that:

1. People on the project were wasting a lot of time writing these emails.
2. People on the project were wasting a lot of time reading these emails and dealing with random redundant noise.
3. People on the project were doing some level of CYA.

It was generally believed that if a programmer sent out a cryptic email with a SVN log of a check-in; he basically passed the responsibility of testing the code over to a tester; who was supposed to grab that email; get an update; understand what changed by looking at the log; and test the newly built functionality.

Shivers of chill ran down my spine as I saw the hundred plus emails get downloaded into my mailbox; emails with cryptic signals that you had to monitor like a hawk to see what was getting done or for that matter; what was not getting done. Terror struck with the number of emails I was getting just from this project team; I decided to investigate and find out what started the whole CYA exercise of emailing the entire team every time you did anything.

Turns out; the team had once been told to send out regular email updates on every SVN commit they did. Being the introverts and un-social creatures we as programmers are; every single programmer in the team; even the best of the builders; started following the rule; and in some little perverted corners of their geeky-brains started somewhat enjoying the rule.

When I was asked in a management meeting what it would take to get the team to become fully productive; my response was simple; direct and straight forward. The team was already productive. All you had to do to get things done was cut off their email accounts from them and you would have a golden team that not just flocked well; but communicated and connected with each other.

That dear reader; was of-course easier said than done. After days of trying to convince people to walk up to person in the next cubical and talk; if there was one thing that I learnt it was this: if you want your programmers to succeed; keep them as far away from meetings and emails. Get them white-boards; get them markers and more than anything else get them to talk to each.

So the next time you find yourself writing an email to your colleague; stop. Think. Can you use better forms of communication than a random haphazardly written email? If you must use email; can you limit your audience to people who really need to act on your emails rather than randomly emailing the entire team? Take some time and indulge in some serious soul searching before you press that send button.

After all; you might be spamming your whole team; and you might not even know it.

What is worse; is that you might be spending hours of your day pretending to yourself that you are indulging in an act that is professional when all you are doing is indulging in a CYA excursive; wasting your time and the time of those who work with you.

Facing a problem fixing that code you are working on?

Don't send an email yet; go talk to the person sitting in the cubical next to you; ask for help and try to strike a meaningful one on one conversation.

I wish you good luck.

During my childhood I was told by many that I was what they called an --- 'introvert'. As far as my side of the story was concerned; I found human beings; to be these hugely  complex creatures who were very difficult to understand and establish a connection with.

If I can be honest here; it was not the human race that was a problem. I actually liked interacting with other human beings. It was just the first five minutes; the small-talk; the how-are-you-doing or how-is-the-weather-there discussion along with that phony smile that I found hugely complicated and pointless.

Computers and compilers on the other hand; were hugely different. At times they were unpredictable too but they came nowhere close to human beings; besides there was no small-talk; weather-talk; and phony-smiles involved.

Armed with my programming skills; I entered a profession where interaction with human beings was just as important as interacting with the compiler.

Then as I grew and morphed into a better programmer; something funny happened. My quest of becoming a better programmer started making me interact with other fellow-programmers and I; dear reader; started connect to them. Then there was the ability to explain technology to explain technology to clients and business folks; that started getting developed as I worked more with people who were not very technical.

Put simply; as I grew up as a programmer; I realized that I was not the 'shy' or 'introvert' character I was told I was.

I just had a slightly different medium; way and approach of connecting with people.

As a part of my job; this blog and my online presence I think on any given day the number of human beings that I interact with; is probably more than any typical social lawyer or insurance agent out there; and I love it.

Having said that; for the programmer within me even today; connecting to random strangers is not easy; and yet; every time I get an opportunity to connect to people; I try my best to do so.

Michael Lopp in his post about 'Your People' explains why I make a conscious effort to interact with people through twitter; blogs; and conferences every time I get an opportunity. Michael explains:

There are two types of networking. Basic networking is what you do at work. It’s a target rich environment with co-workers, your boss, and those of interest in close proximity. It’s work, but it’s easy work because your day is full of those you depend on and you’ve learned that professionally befriending these people keeps you comfortably in the know.

The other type of networking I’m going to call people networking and it’s harder work. This is when you put yourself out there. It’s attending a conference where you know no one. It’s driving to the city to sit in a coffee shop with ten strangers bonded by a programming language. It’s a leap for the socially awkward, but the infrequent reward is that you discover Your People.

While Michael's definition of 'your people' is a definition that I would rather use to describe close friends or colleagues; he makes a point that is rather valid. As programmers; it is easy for us to interact with our compilers; talk to other fellow programmers and completely miss out on opportunities that allow us to connect; share; and learn from other smart individuals around the world.

My Point?

Look around. Connect with other human beings whenever you can.

If you are a programmer; who finds peace by being in flow and talking to his compiler; my advice to you dear reader; is that you go out there and start a dialog with smart people out of your current workplace.

If small talk makes you nervous; find other way of communicating with people. If constant ongoing conversation is your medium on conversation; start a twitter account. If you like a coherent stream of organized thoughts and discussions around those thoughts sign up for a blog. If personal one on one communication makes you happy; start attending conferences.

Whatever it is that you do; connect to people every time you find the opportunity to do so; because at the end of the day; that is what will make you a better programmer; a better professional and a better human being.

I wish you good luck.

What Are You Spending On - Programmers  Or Infrastructure?

If you are a regular reader of this blog you probably know that I do not do not usually do not do travelogues in this blog; unless of-course my travel results in meeting a really interesting individual or finding a meaningful insight which I can share with you dear reader.

This one did. This by no means is this post just a travelogue. Read on.

In a recent visit at Ted India I spent three days in the beautiful and plush campus of Infosys.

Before I start this post; let me go ahead and mention that Infosys is an amazing organization; and is often referred to as the one of the best software firms of India with high employee satisfaction. The guys at Infosys were not just kind enough to sponsor Ted but were actually kind enough to give some of us a very elaborate Infosys campus tour; even though we were not registered for the tour.

The intent of this post; dear reader; is not to criticize Infosys; put the organization on the spot; or bore you with a detailed description of the entire Infosys campus tour; but to leave you with a few facts; a few questions and a thought worth harping on.

Ready?

Here we go.

Fact one - Infosys campus is huge and beautiful.

As you read hear me say that the Infosys campus is huge and beautiful; dear reader; you have to keep in mind that this comes from someone who has seen some amazing campuses in his career as consultant across the globe. Just so that you know; I've worked in campus ranging from filthy rich oil companies at Texas; all the way to the Microsoft Silicon Valley campus.

The Infosys campus with its plush green environment, clean roads and huge intimidating architectural structures which look like palaces of Paris or the epcot center building; beats anything I have seen till date. Try cycling through the campus and your panting breath will tell you how huge the campus is.

There are guest houses, swimming pools, bowling alleys, super markets, saloons, multiplexes, cycle stands where you can grab free cycles and pretty much anything you can think of.

It's clean beyond imagination; huge beyond imagination and has buildings which are shaped beyond imagination.

Fact two - Pillars Without A purpose.

As we tour through the Infosys campus; we are accompanied by a Tedster who happens to be in the business of reconstructing old buildings.  I stand in awe looking at the huge marble pillars; when suddenly; I am told by this gentleman; who can differentiate a fake pillar from a real; that the marble isn't real marble.

They are in all probabilities a synthetic material; he tells us.

The guide agrees.

Turns out, the pillars aren't even a structural necessity. They just happen to have been constructed using a compound that 'looks' like marble purely for beautification purposes.

Fact Three - Domes without a meaning.

Infosys buildings seem to copy or replicate structures from around the globe. The primary training facility resembles palaces in Rome or Paris.The primary planetarium looks exactly like the epcot building. In fact, most TEDsters; me included; actually start referring to it as the epcot building.

Turns out; the epcot building is a perfect rectangular box like any other building from the inside. The epcot-like-dome is a facade on the outside of the building purely for beautification purposes.

You can see the taste; the diligence; and the pride Infosys folks have when they are talking about their campus. It almost feels like being in the silicon valley of India --- till I make a request to one of our tour guides.

What I decide on doing is applying my litmus test of finding out if a software development firm is truly remarkable; on Infosys. Promptly I express my desire to see the offices where developers work.

Fact Four - Infosys Refers To Software Development As 'Production'.

After a little bit of thinking our guide is kind enough to get permission and give us a quick tour of the Infosys 'Production' area. I ask him if this is a common term used across Infosys. Turns out that software development is actually referred to as 'production' across Infosys. I cringe.

Fact Five - The Programmer Bill Of Rights Happens To Be Non-Existent At Infosys.

Shivers run down my spine as I walk into the 'production area' which looks like any other 'cubical farm' of any other organization. Engineers work on desktops and tube based monitors. They sit in cubical with very little division or privacy between four cubical.

You can see effort; or lack of it thereof; that went into designing the office. Compare it with the effort and money spent on building the amazing and intimidating domes; and you will realize that workplaces received very little attention.

Clearly; seems to have been outsourced to an architect or a designer who knew nothing about software development.

And The Point.

Put simply; Infosys workplaces are just like any other software development shops around the globe. Absolutely nothing special or different about them.

The work environment pretty much seems to violate every right in the programmer bill of rights.

I watch the engineers code away to glory as they work on a project; which is about writing software which controls the wing of an air-craft; in averagely mediocre offices; on desktops; with single monitors and not very quite work environment. Had I blind-folded you; took you in; and opened your blind-fold once you were in the 'development' center; chances are you would not know you were at Infosys.

If you have not yet figured out where I am going with this; here are some questions to play around with dear reader in your head as you read along.

Lets face it. Programmers are what build Infosys. While most programmers look decently content with their work environment; why does Infosys spend all this money building Domes around boxes, copying the epcot building, or building with fake marble pillars when the environment where the developers work most of the times are barely mediocre?

Does Infosys; like most other software development shop around the world; miss the whole point?

To be honest here; dear reader; this post is not so much about Infosys; as it is about the sorry state of software development world and how we as software development shops treat programmers.

Of all the companies I have seen; worked with; or read about; I am yet to find a company other than Google, Fog Creek and Microsoft which realizes the important of giving the basic necessary infrastructure to development teams which ends up making their developers genuinely productive.

Now; if you happen to be a young and budding engineer or even a veteran looking for a job; chances are that you are going to find yourself in a cubical farm. Even if they do not explicitly mention it; chances are that your organization too considers software development synonymous to 'production' as it spends spends millions in marketing, management and building hollow pillars which look like marbles; well at-least metaphorically.

Lets face it; dear reader; There is not much you can do to change any of that; yes you can try to change your organization but chances are; you company may have already run out of budget to do anything and there will not be much they can do.

Having said that; if you are a young and budding entrepreneur; setting to start your own company; might I suggest that before you hire that architect who designs hollow pillars and fake domes for you; spend some serious time understanding software development; what your developers truly need and get them those quite offices with privacy; aeron-chairs; powerful laptops; dual monitors and a silent work environment which allows them to get in the flow.

And that; dear reader; is what will make your campuses much more beautiful than most other software development firms out there.

I wish you good luck.

I write this from the Plush; huge and amazing campus of Infosys Bangalore where TED India 2009 is being hosted.

Before I even start with this post; let it be known that I love TED and have been watching TED videos for three years. Being at a TED is an experience any creative mind should indulge in and I would highly recommend TED to anyone who as I say - aspires to make small or big dents in the universe.

TED India; much like all other TEDs was an amazing experience.

I have been blown away with the hospitality; arrangements and the insightful talks.

But this post isn't about reporting TED events or doing a shameless plug for TED.

This series of posts; dear reader; is about 'entertaining' a few thoughts that whisked through my weirdly-different mind during the last two days spent at TED India. It is also about sharing, raising and discussing a few of my very own personal questions and perspectives that I carry back with me; besides the amazing things that I learnt from TED India speakers, fellows and participants.

May The Best Man Win.

If you happened to be at TED India one of the things that you would have found striking is the amount of conversations and talks around; India, Indian Culture, How India is different from the west, How Indian infrastructure is growing; how corruption in India works; how the Indian poor are being helped by Indian NGO's and how nothing in India is perfect but in spite of that things still 'work'.

The amount of discussions and content around the whole mechanics of how India works; what India is up to and how India is coming up; in TED-India were fascinating; but if I can be brutally honest here; they were also a little overwhelming.

Put simply; by about the evening of second day; as I saw almost every speaker and participant touch the topic of 'India' and how it works; I was starting to miss talks which touch universal problems like happiness; education; drawing inspiration and many more like it in a rather fascinating and engaging way . What was also happening by then; was that a few question were starting to find their way through my mind:

1. Were the TED India speakers and even we (me included) as TED-India participants spending just way too much time on understanding the differences that are either going to pretty much automatically find a way to co-exist or are going to be wiped off in a matter of few years?
2. Are we not rapidly moving towards a world where the best of efforts and products cross the dip; stand the test of time and eventually survive; irrespective of the country that they originate from?
3. Are we not already in a world that is so mind-blowingly fair that just one rule stands - may the best man, woman, organization, thing or effort, win.

No seriously.

Before you knit your brows at the questions; and go on the defensive; consider this:

If you happen to be the best social worker out there; you will figure out a way to help those who most need your help; irrespective of the country that they belong to.

If you are the best architect; you will find a way to build the best of the buildings that people find fascinating.

If you are the best musician; you will find a way to touch people's heart with your music in a way that moves them.

If you are the best software developer; you dear reader; will find ways to build the most remarkable software out there.

So the next time you see me at a cafe; I do not care if it is in India or California; lets get together and talk about insights that makes you the best whatever-it-is-that-you-are. If you are not the best let us exchange ideas, thoughts and experiences about what can; as professionals; make us; the best at whatever-it-is-that-we-do.

Everything else; is just details.

May the best man, woman, organization, idea or product win.

Now; tell me what makes you the best? If you are not there yet; how are you working towards getting there? What have you learnt from your failures so far?

I will take what applies to me. As an educated man I will try my best to filter the inapplicable and entertain your thoughts without accepting them.

I do not care where you are from; where you are located or how amazingly different we are. Seriously.

Go ahead. Start the conversation.

I am listening.

Are you?

You Might Be A Spammer And You Might Not Even Know It. 

From Saving cost; increasing my IQ; getting a free degree; living a happy life to increasing my man-hood; the number of spam emails that I get on any given day is astonishing.

While I am hard-wired to ignore these emails; there is yet another kind of email that is also technically spam and that I also ignore.

This dear reader; is not the typical malicious spam sent with an intention of spoofing; identity theft or running a Trojan on your machine.

Instead; these email include a real organization and a real marketer trying desperately to market a product that he or she has set out to make you interested in through what I like to call 'brute force marketing'.

Examples include:

1. Valid and Authentic Placement Agencies checking to see if you have openings in your organization and if you would like to interview their candidates. 
2. Web conferencing companies trying to show you their solution and help you get; what they call; a higher 'ROI'.
3. Training organizations wanting to check if you are interested in attending their next paid training session or workshop which will 'boost' your productivity.

Read between the lines and you willl sense both; the mediocrity of the product and the frustration of the person sending the emails.

For months I struggled with why anyone would indulge in the act of spending all this time and effort to spam your mailbox when it is a vastly known fact that we as computer users ignore most of the emails that we get.

For months I wondered how the idea of writing Trojans and spammers worked. Were there organizations that had developed this as a Niche? Were there whiteboard meetings; backlogs and scrums around the features to include in the next version of the cutting-edge-spammer these guys were writing?

No; seriously; this entire 'industry'; for lack of a better word; and its workings; were beyond my comprehension.

It was then that I happened to work with the client where I saw how it all begins.

This client of ours; who for the purposes of this post; we shall refer to as Multiplitaxion Inc; had a marketing department which undertook the task of sending out monthly mail blasts to what they called their 'potential clients'.

To give them credit for ethical conduct; the mail blasts were not malicious though. They contained simple HTML emails with harmless irrelevant stock-pictures of planets like Saturn or smiling people. The idea of these emails was to get the receiver of the email excited about the insurance product this client of mine worked on.

A little more investigation into the process told me how it typically works:

1. There were people hired (usually outsourced from marketing firms based out of India) to search and collect email addresses on 'potential customers' from the web and multiple other sources.
2. There were companies which sold database of email addresses. These database were purchased on a regular basis.
3. People were added to the centralized CRM database without their express permission and is most cases even without their knowledge; albeit they were offered a small 'un-subscribe' link at the bottom of every email that went out to them.

Yes; this client of mine was one-hundred percent ethical; with no malicious intent and yet they had taken their first step to becoming what can otherwise very technically be called a --- 'spammer'.

As a fully ethical organization; which was working on a genuinely good product; why did the marketing teams of Multiplitaxion Inc; feel the need to do this?

My personal theory behind this is simple --- because the math associated with this thing was staggering. It was an expensive insurance product for the enterprise this client of mine owned. The product had just three huge paying clients; which was good enough to sustain the product development team and keep the product running.

On any given month they sent out around five thousand unsolicited emails. Assuming that just 1% of the recipient clicked on the email and then 10% of  that 1% came to their website and spent considerable time there; they would have 5 interested customers that they could track and follow up with.

Now if your marketing could turn just 20% of those into paying customers; you had one new customer - which basically translated to 25% more revenue coming out of the product.

It was huge.

Human beings; are driven by different motivations; and when the motivations are high; people tend  to lean towards what might be wrong without even realizing we are doing so. This is exactly what had happened here. Multiplitaxion Inc; was sending out spam-mails without even realizing it was 'spamming' people.

No-one in the marketing department; development team or the entire organization saw this as spam. Everyone just called it a 'mail-blasts' and we even had calls around how we can improve the email sending job so that we can track the people who were getting these emails and see what they were doing with these emails that we were spending so much time and effort to send.

That is when we started embedding GUIDs and JavaScript in our email to track who was clicking on them; who was deleting the emails without reading them and who was spending time on our website.

We never went beyond this point; but as we sat through some of those meetings; I as a developer; could almost see what the natural next-steps or set of 'features' could be to take our mail-blast program to the next level - introducing a small executable or active-x component (or should we say a Trojan) to see which other insurance products the recipient of the email was running?

I cringed at the very thought of it.

It freaked me out to even think how thin the line is between being a software developer who is building a great product and helping the marketing team get the word out and a spammer who is writing state of art tools for spamming people.

The only good thing; that I can say about that episode is that this client of mine; knew where to draw the line and stop. No-one even thought of or spoke about introducing executables or active-x controls for better tracking visitors.

Of-course; as we sat in that meeting room; none of us; even thought that; just by sending those emails out; we had taken the first step to becoming the spammers we all hated.

Now; pause a moment; dear reader.

Reflect.

Does your organization send out an email blast about any of your product or service?

Harmless HTML emails that go out to a few hundred or thousand readers?

Maybe; and I am just saying maybe; much like those placement agents checking in to see if you have openings; or the training institutes checking in to see if you would like to boost your productivity; your organization might be spamming people too; and you might not even realize it.

Just a little something to think about.

The Mango Warehousing Business In India.

The Mango-Warehousing business in India is huge and yet very few people do it.

If you were to look at the business of warehousing mangoes; you might realize that; in order to get into the mango warehousing business; all you need to do is to go stay at the Mango-Farms in remote villages in India; during the mango season; look for the best prices that you can get and stock as many Mangos in your warehouses as you can.

The whole process involves some work; particularly before the mango-season in India.

Usually this translates to about a month worth of work.

Once you have put in that effort and have stocked the mangos; you go back home and sign a few sale-deals with retailers or grocery-stores. The signing of contracts with major groceries and distributors typically takes another month and does not involve any real hard-work.

If you; like a friend of mine; work in the business of warehousing mangoes; chances are that you probably work for just two months a year; and you make a truckload of money.

As tempting as some of these money making stories are; mango warehousing; dear reader; is not what I do for a living.

I build software and weave stories around software development.

Not to bring the people in mango warehousing business down; but I; dear reader; am not particularly interested in stocking mangoes for a living.

Are you?

The Point.

Now; if you have been knitting your brows with my mango-warehousing-commentary or the funny question it ended with; and nothing in this post seems to be making sense to you so far; would you; dear reader; do me a favor and count the number of business domains that you and your organization may have worked with in the last three years.

If the number crosses a dozen; chances are that your organization or you are a free floating developer with no niche or passion for the problem-domains you work in and you should seriously consider mango-warehousing in the farms of India as your next project.

I've witnessed quite a few consulting and product companies out there venture out into random business domains that have nothing to do with their niche and what most of them indulge in; can be referred to as trying-out-mango-warehousing-of-the-software-development-world. The cycle pretty much goes like this:

1. You find an industry in a remote corner of the world that no-one seems to be interested in; this gets you very little competition.
2. You spend couple of months building an application with a few CRUD screens around that industry.
3. You try to sell your CRUD screens to business folks on this industry; and then you make a truck load of money from those CRUD screens; or at-least that is what you try to do.

Put simply; you focus on making quick-buck by targeting obscure domains that have not been targeted yet; and then you build collection of random CRUD screens and PowerPoint presentations on the industry.

My previous organization for example was a classic example of this mode of working. We woke up one fine morning; discovered that there was a lot of money to made in training and literally ventured out in the business of software training.

A few wannabe-programmers; which no passion for teaching; were hired and turned into teachers.

It worked for a few months. Then we started sucking at it.

It ended with students literally rallying on their doors protesting against the poor quality of training they were providing compared to the money they were charging for these trainings.

Not to mention that in parallel; we has also ventured out into the world of retailing computer peripherals.

While this may sound like an extreme example of an organization trying to make easy money; by doing anything that can get them a quick buck; reflect on just how many absurd industries that you as a programmer might have worked in; for your current or past organizations.

Remember specialized accounting and payroll product for the tea-estates of the world that you organization was working on; or that specialized document repository designed specifically so that the oil mine workers can upload their well-files; or that specialized inventory tracking system that was supposed to help hospitals keep a track of their bed sheets.

You didn't feel anything about tea-estates; oil-mines or hospitals; did you? Neither was it your organization's niche. You were just trying to work for two months; get a few CRUD screens stocked and make a quick buck.

Your organization; dear reader; was indulging in act of trying to start mango-warehousing-in-the-software-development-world.

Genuine Mango Warehousing Happens To Be Hard.

Back to digressions. Remember how my friend does mango warehousing; works for just two months a year and makes a truck load of money?

If you were an average Fred looking at the business of Mango warehousing business from the outside; it seems simple. You work for two months; you hardly do any real work and you make a truckload of money; it seems so very easy.

It is only when you try it; that you realize that mango warehousing in India is serious business. It involves:

1. Owning warehouses; maintaining them; securing them; running them and operating them. All of it requires truck load of money.
2. Learning local languages (curious side-note: India; has more than twenty local languages); adapting to the local culture and knowing how local cultures work - not knowing this means you can literally get beaten up by the locals.
3. Developing a deep gut for how much harvest would happen in any given year.
4. Developing a gut for what a fair deal is; and then buying at the right price in the right time.
5. Developing contacts with retailers or people who would distribute your stock when the price is right.

The list dear reader; is endless.

As simple as it seems on the surface; Mango warehousing in India; dear reader; is serious business; it is hard; and can take you a life time to master.

For my friend's family; it took them two generations.

And believe it or not; during those two months; I think he feels really passionately about --- mangoes.

Where I am Going With This.

You see where I am going with this; don't you?

If your objective is to make money; it is easy to think of a thousand unexplored industries where you do not have a lot of companies building software. Then build a few CRUD screens around that industry and hope to earn millions through the collection of half-assed CRUD screens.

Next time you target a business domain; only because there is very little competition there and you think you can get away by not feeling-the-pain or just building a few oddly-stitched CRUD screens that save something to the database and spit out a few reports; think again.

Remember; mango warehousing is hard and the amount of passion and work you need to succeed in it is probably just as much as you need to build a project-path; even if; you do not see it at the surface.

Stop hunting un-explored industries and jumping from one domain to other in a desperate attempt to hit a gold mind.

Find a niche; become the best in the world at it and go build stuff that makes meaning.

I wish you good luck.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.