free html hit counter
Posted on: Thursday, November 12, 2009 by Rajiv Popat

Programmer Tip: Stop Those CYA Emails And Engage In Meaningful Discussions.

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.

posted on Thursday, November 12, 2009 11:01:14 PM UTC by Rajiv Popat  #    Comments [3]
Posted on: Sunday, November 8, 2009 by Rajiv Popat

Programmer Tip: Strive To Connect With Human Beings Whenever You Can.

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.

posted on Sunday, November 8, 2009 11:53:08 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Saturday, November 7, 2009 by Rajiv Popat

TED India 2009: Experiences And Observations Of A Rogue Thinker - Part 2

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.


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.

posted on Saturday, November 7, 2009 9:33:11 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Thursday, November 5, 2009 by Rajiv Popat

TED India 2009: Experiences And Observations Of A Rogue Thinker - Part 1

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?

posted on Thursday, November 5, 2009 6:56:26 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Sunday, November 1, 2009 by Rajiv Popat

Random Thoughts On Truly Remarkable Story Telling - Part 1.

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.


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.

posted on Sunday, November 1, 2009 8:52:58 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Saturday, October 31, 2009 by Rajiv Popat

Random Thoughts On Builders At Work - Part 19.

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.

posted on Saturday, October 31, 2009 9:14:22 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Wednesday, October 28, 2009 by Rajiv Popat

Random Thoughts On Builders At Work - Part 18.

At one of our clients; who for the purposes of this post; we shall refer to Multiplitaxion Inc; I sit through a project meeting with a heavy heart.

We are talking about adding features to a product that just does not seem to have taken off or generated any form of revenue, adaption or excitement; after almost two years of hard-work; effort and sweat of more than five genuine builders.

The marketing team still thinks we have a 'great' product that is gaining a lot of 'interest'. We hear sentences like 'our-product-is-getting-noticed' and 'our-product-is-gaining-traction'.

The vice president of technology; thinks the product just needs a little bit of more work and then it will be golden.

The director of marketing feels a few new features would help us sell the product in completely new markets.

Everyone seems to think that the product will eventually cross the Dip if we keep going at it.

Everyone; thinks; and has been continuing to think since the last three months; that we are really close to a version that customers will love and buy.

Something tells me we are nowhere close; we are just what I call --- 'lost'.

I cringe as I sit there and watch people preparing to-do-lists and backlogs of features which they believe will rescue the product and get us adaption.

What I am feeling right now; is what Malcolm Gladwell defines when he talks about Vic Braden who is able to predict with impeccable accuracy which one of the serves by a tennis player will be a double fault; every time he is watching a match. In his book; Blink; Malcolm explains:

Braden is now in his seventies. When he was young, he was a world-class tennis player, and over the past fifty years, he has coached and counseled and known many of the greatest tennis players in the history of the game.

He is a small and irrepressible man with the energy of someone half his age, and if you were to talk to people in the tennis world, they’d tell you that Vic Braden knows as much about the nuances and subtleties of the game as any man alive.

It isn’t surprising, then, that Vic Braden should be really good at reading a serve in the blink of an eye. It really isn’t any different from the ability of an art expert to look at the Getty kouros and know, instantly, that it’s a fake.

Something in the way the tennis players hold themselves, or the way they toss the ball, or the fluidity of their motion triggers something in his unconscious. He instinctively picks up the “giss” of a double fault.

He thin-slices some part of the service motion and - blink! - he just knows. But here’s the catch: much to Braden’s frustration, he simply cannot figure out how he knows.

I can smell something weird. I can tell you with utmost confidence that the project will not get any adoption, excitement or revenue in the years to come.

There is nothing technical that brings me to this belief though. Not the code; Not the implementation.

To be fair; we have a clean code base built to sustain the test of time.

And yet; something seems 'wrong'.

It does not seem like a half done project. It seems like a half-assed project; without any meaning; designed for the soul purposes of 'somehow' gaining revue in an unexplored business domain. Maybe it is the idea; maybe the industry; I cannot clearly lay my finger on the issue or explain it articulately in the meeting; but I can hear myself thinking out loud - 'This thing will not work'.

None of these 'feelings' can be found on the initial project documentation though. The project has an amazing 'Project Charter' document. It has a strong business case document and a flashy PowerPoint presentation which makes the 'marketing' and the 'business' very excited about it.  

And yet; as everyone in the meeting room sits there trying to nudge us to do one more sprint - we; the team building the product know rather well; that another sprint and a few new features will not change anything.

After the meeting none of us speak; we just get to work for the next sprint.

Simple Reality Check; Watch your builders.

Within a couple of weeks; three of the best developers associated with the project contact me multiple times asking me if they can be removed from the project and moved into a different project.

When asked specific reasons on why they wanted to be moved - their responses are nowhere close to specific. Some of them 'think' the product would never get adaption. Others are not 'feeling it' while one goes so far as saying that he feels he is just wasting his time after an idea that would never work.

Years later I got an insight into how Google works on their product portfolio:

Developers can switch teams and/or projects any time they want, no questions asked; just say the word and the movers will show up the next day to put you in your new office with your new team.

I am sure there is some level of exaggeration here; but then having said let us assume that you work at Google and you end up proposing a really lousy idea that you think is great and will change the world.

Now; assuming that you know people in the right places inside Google; even if you were to get the product funded by Google you probably might not find a team to build a product based on this idea; primarily because your builders will probably just move to a new project and a new office before you even know it.

Let us be honest here.

If it is an idea you came up with; unless you are a super-genius-freak; chances are that you are going to fail pathetically at finding out the crapiness of the idea. All your time and energy is probably going in defending the idea from others who feel it is crappy anyway.

You builders on the other hand; are a completely different story.

Watching how happy or frustrated they are as they work on your product is probably the best way to figure out the genuine usefulness or uselessness your product will have when the first release is out.

Builders As Power-Users.

By the time you reach Betas which are stable enough to test out with your first set of sample business users it is probably too late to end the project and surrender gracefully.

Let's face it.

By the time you get to a Beta ready stage you have probably spent too much time, money and ego to come out say - sorry guys; we f@#cked up; lets stop all the work on the project; quit it cold and move on to something more productive.

What most organizations do not realize however; is that they have another set of really powerful users capable of giving them this exact same feedback even before the first line of code if written.

Any guesses on who this set of power-users are?

Your development team.

Yes dear reader. If you have hired seriously; your development team probably has some of your alpha-geeks who have spent years submerging themselves in technology; using software and using websites online.

Letting your builders have an opinion about the product that they are working on; and giving due attention to that opinion is pretty much like having a Vic Braden from Blink on your side and knowing in advance every time your product is going to ship with a result that can be best described as a --- 'double-fault'.

The Power Of Disassociation

Disassociation is the biggest form of dislike and disagreement that you can express towards an idea. When one of your genuine builders walks up to you and says he wants to disassociate and remove himself from a product he is working on; it is time to:

  1. Remove him from the project --- No questions asked. Move him to something that is genuinely exciting; fun and something he believes in.
  2. Question the very premise on which the product is being built --- are there elements of wishful thinking which will make you realize the truth only after you have wasted years of development effort and dollars?
  3. Stop and talk to your team of genuine builders and this time; for a change; listen.

I leave you dear reader; with a thought worth harping on: The team that builds a product is the very first set of users that uses each screen of the product; as it is being built. If they; themselves find your product boring; mediocre and safe; to an extent that they want to disassociate themselves from the product; do you really expect others to adapt and use the product; dear reader?

Go ahead. Try giving your team the power to disassociate themselves from their current project if they do not believe in it; no questions asked. Now; go see how many of your genuine builders stick around; because that; dear reader is a genuine litmus test of how interesting your product really is.

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.

posted on Wednesday, October 28, 2009 10:57:49 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Sunday, October 25, 2009 by Rajiv Popat

Random Thoughts On Builders At Work - Part 17.

Motivation For Your Genuine Builders.

Steve McConnell in his classic book Rapid Development - Taming Wild Software Schedules describes a typical organization's approach to motivating their teams of builder; and what is wrong with the approach using the following illustration:

In the same book Steve talks about the importance of having some serious story-telling revolve around your project or your product. He explains:

The shared vision can be of something important—such as putting a man on the moon by 1970—or it can be of something relatively trivial - getting the latest update of the billing system out 3 weeks faster than last time. The vision can be virtually arbitrary, but as long as the whole team shares it, it will serve the same purpose of helping to bring the team together.

To have a motivating effect, the vision also needs to be elevating. The team needs to be presented with a challenge, a mission. The Amish farmers responded to the seemingly impossible challenge of building an entire barn in one day. High-performance teams don't form around ho-hum goals.

"We'd like to create the third-best database product and deliver it in an average amount of time with below average quality."

Ho hum. Yawn.

No team is going to rally around that.

Of-course; no vice-president high up in the pecking order will spell out the fact that he wants the boring database product with below average quality; but builders tend to have seriously strong gut-feeling built around reading between the lines and sensing what their organization ultimately wants from them.

If you are a manager; you could be sending out the mediocrity message to your team all the time. Multiple subtle ways of sending this message out exist:

  1. Deadline Driven Development.
  2. Panicking And Policing.
  3. Lack of trust and empowerment.
  4. Demo driven development.
  5. Optimism and inability to accept the facts.

The list is really endless. Reflect; and you might realize that your organization is sending out the mediocrity messages to your right now as you read this. Messages that you are taking and passing on to your team; as you sit and wonder why they are not hugely productive.


There is a reason why dead-lines; panic; threats and policing does not work in software development - if your team is a team of whiners; you are trying these techniques on them will cause them to break down and black out. If it is a team of genuine builders --- they just do not care about you scoring fouls. Chances are; that they will either not listen; or if they do; they will eventually hibernate.

Most genuine builders that I have seen do not work for a ten-percent salary increment at the end of the year. What moves and motivates genuine builders around the globe are opportunities to make dents in the universe and leave their mark upon those dents.

They want to build stuff which changes things.

They want to work in teams and organizations which add meaning.

It's a purely selfish desire; with huge long-term benefits.

The drive most builders have for this desire is usually much more than a short term ten percent salary hike in a yearly review or a pat on their back from their managers. If these; and the items mentioned in the list above are the only tools that you can offer your builders; you are better off moving or outsourcing your development to a third-grade Indian body-shop.

If on the other hand you are lucky to have landed up with a team of genuine builders and you want them to take your products, business and organization to the next level; may I suggest that you:

  1. Weave a remarkable story around your product and mean it.
  2. Show them how the story impacts them personally and aligns with their long term goals.
  3. Give them the tools to turn the story into a reality.

Now; Get out of their way.

Watch them innovate; contribute and execute flawlessly.

Observe and learn.

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.

posted on Sunday, October 25, 2009 9:03:01 PM UTC by Rajiv Popat  #    Comments [0]