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.

@BuildersAtWorkBookNotice

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.

@BuildersAtWorkBookNotice

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.

Newsflash!

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.

@BuildersAtWorkBookNotice

It's Learning Time.

If you have read this blog more than once; you probably know; that as an highly opinionated individual; I tend to express my strong-opinions-weakly-held; rather openly; loudly and boldly.

What you may not know however; dear reader; is that for most of the posts that I write; I try to give a quite bit of time; effort and attention to see to it that as I express my strong opinions openly I do not end up sounding like my self-proclaimed-authority or end up posing as an expert on the craft of building software.

I have very little respect for experts and have no intentions on posing as one. Besides; self-proclaimed-experts shouting at the top of their voice are a dime a dozen and no-one cares about what they have to say anyways.

How I think of myself; as far as the field of programming is concerned; is pretty much on the same lines of how Jeff Atwood describes himself as a programmer:

I'll be the first to tell you that I am not an exceptional programmer. A competent programmer, yes. Always. On a good day, perhaps even a decent programmer. But I don't kid myself, either. I'll never be one of the best. But I have an ace up my sleeve that most don't: what I lack in talent, I make up in intensity.

When you think of yourself as someone who is nowhere close to being an exceptional programmer; coming out saying that you are going to start writing a series of technical posts with a different style of technical writing is hard and might even sound like stupidity.

In spite of that; in one of my earlier posts; I explained my gripes with technical writing and announced that every one in a while; I am going to be trying to indulge myself in some interesting fun filled technical writing on this blog. Technical Writing about developing better code that programmers and even managers who were once passionate about programming can enjoy and learn from.

As I mulishly work on trying to develop a writing style that does not doze you off to sleep while reading a technical article; and continue my research for some of the topics and articles I plan on writing about; here is one question that keeps coming back from people I know personally: 'Why?'

'No seriously; Pops' - people I know or work with have told me recently - 'There are tons of technical books on programming out there; why do you want to write another one?' --- or at-least they have said something to that effect.

On the face of it; the obvious reason; dear reader is that I am not hugely happy with the type of technical books that are being written out there and I want to make my humble contribution to the world of software development. The actual; blunt honest and selfish reasons for attempting to write a technical book; dear reader; are however; very different. They are:

1. I want to write a book on the craft of building stuff; programming and coding better primarily because that is what I am interested in learning.
2. I am a loud learner --- what that means is that I like to make a lot of noise when I learn something new.
3. I have seen that I learn the most when share what I am learning with others and teach them what I just picked up.

Put simply; I learn best; when I learn like a teacher.

It's Teaching Time.

For the first couple of years of my career I happen to teach students who were taking their Bachelors in Information Technology. There were quite a few things I learnt and picked up during those days; ranging from giving presentations all the way to basic concepts used in software development and IT.

Most of it was quite valuable.

The first few months however; were not very present.

Here I was; fresh out of high school; picked after of multiple rounds of interviews; as I wondered what my first assignment was going to be.

It was to teach programming and IT lessons to a bunch of students doing their Bachelors in computer science.

Soon I found myself walking into classrooms with my huge ego when every once in a while; a student would just get on the white-board correct me or just prove me out right wrong; as I watched my ego float and sink to the ground.

After it happened a few times; though; I started turning shameless and started learning from my students.

That is when; dear reader; things got interesting and my growth chart; in terms of what I was learning; started shooting up.  That; dear reader; is also when I was able to keep a class full of students fully involved and connected with the topic. That is when we started having something that was close to 'fun'.

If there was one thing that part of my life taught me it was that the only way to teach something to anyone is by brining yourself on the same level ground as your students and walking the same learning path with them.

Put simply; I  realized that I teach best; when I teach like a student.

You Are Invited.

If you find the whole idea of learning like a teacher and teaching like a student confusing; all I can say is; like the rest of the software development world today it is supposed-to-be-confusing; in a very good way.  Michel Lopp describes this confusion much more articulately than me when nudging managers to write code in his book Managing Humans. He explains:

The simple fact is that well-defined roles in software development are fading.

User interface guys are doing what can only be called development in JavaScript and CSS. Developers are learning more about interaction design.

Everybody is talking to everybody else and they’re learning from each other’s mistakes, stealing each other’s code, and there is no reason that a manager shouldn’t be participating in this massive global cross-pollination information cluster-f@ck.

Michael's invitation of joining the massive global cross-pollination information cluster-f@ck is not just limited to nudging young and budding managers  to write code. Take the same idea further and it extends rather well to how the world in general and web in particular is shaping up.

While my early teaching days were painful and merciless on my ego; as I struggled to turn from a teacher into a student; the web today makes it possible for every single one of us to do that much more easily; and this dear reader; is precisely what I intend to do with these series of posts.

With my first book slowly starting to reach an end I will indulge in free-flying and writing about anything that is on my mind; but then every every once in a while; you might end up seeing articles here on how to build stuff better.

You might connect to some of these articles and find them useful if you are a developer; or a manager who was once passionate about development and still wants to remain technical; even if you do not code actively. The other possibility is that you might hate them; find that I am overly simplifying things and adding too much spice to serious technical topics. There might even be times where you might discover that I am talking about things I have no clue about.

As you read these articles; which might show up on this blog every other week or so; please do remember that this is me; teaching as I learn and learning as I teach.

Long story short; I am going to indulge in the act of doing some bathroom singing in a live concert again and you; dear reader; are invited to listen in.

This might be a yet another golden opportunity to come watch me make a fool of myself.

Wish me luck.

By the way; if you find me talking about something that is blatantly wrong; feel free to walk up to the white board; or use the comment field; shatter my ego and tell me how wrong I am. Enlighten me. I will thank you for it. Honest.

For those of you who might have noticed; on 18th October 2009; Twitter; posted a short and simple message on their status website. The message read:

'We are currently investigating a problem whereby some Twitter clients in widely scattered network locations are unable to connect to twitter.com'.

Put simply; twitter was down; yet another time.

When the problem was resolved and twitter came back up again; the same message that announced twitter's going down was updated to reflect the fact that the problem had been fixed. The update read:

'Network should be back to normal now. We are investigating the cause of the outage and will update this with more information when we know more.'

If you are an avid Twitter user; this probably does not come out as news which surprises you anymore.

When twitter goes down; we; the faithful twitter users; wait for twitter to come back up; the world moves on; the sky continues to be blue; the birds keep chirping and once twitter is back up again; we get back to using it.

I love twitter. Don't get me wrong; dear reader. The point of this post; is not to pick on twitter's downtime.

We have enough of you out there doing that already.

As far as Twitter's downtime is concerned; my stand on it; is simple - When they go down I wait for them to come back up and when they are up; I get back at using their service. Yes I love twitter; but then; having said that; my world does not revolve around twitter and their going down once in a while does not upset me majorly like it upsets most passionate twitter users.

 Bertrand Meyer; on the other hand; has a different perspective on Twitter or any other public website going down. He explains:

Software disasters continue; they attract attention when they arise, and inevitably some kind of announcement is made that the problem is being corrected, or that a committee will study the causes; almost as inevitably, that is the last we hear of it.

In the latest issue of Risks alone, you can find several examples.

In the past months, breakdowns at Skype, Google and Twitter made headlines; we all learned about the failures, but have you seen precise analyses of what actually happened?

Bertrand compares software development to a disciplined and much more structured industry like the aviation industry and talks about learning 'learning by accidents'. He explains:

Airplanes today are incomparably safer than 20, 30, 50 years ago: 0.05 deaths per billion kilometers. That’s not by accident.

Rather, it’s by accidents. What has turned air travel from a game of chance into one of the safest modes of traveling is the relentless study of crashes and other mishaps. In the US the National Transportation Safety Board has investigated more than 110,000 accidents since it began its operations in 1967.

Any accident must, by law, be investigated thoroughly; airplanes themselves carry the famous “black boxes” whose only purpose is to provide the evidence in the case of a catastrophe. It is through this systematic and obligatory process of dissecting unsafe flights that the industry has made almost all flights safe.

Now consider software. No week passes without the announcement of some debacle due to “computers” — meaning, in most cases, bad software. The indispensable Risks forum and many pages around the Web collect software errors; several books have been devoted to the topic.

A few accidents have been investigated thoroughly; two examples are Nancy Leveson’s milestone study of the Therac-25 patient-killing medical device, and Gilles Kahn’s analysis of the Ariane 5 crash (which Jean-Marc Jézéquel and I used as a basis for our 1997 article).

Both studies improved our understanding of software engineering. But these are exceptions. Most of what we have elsewhere is made of hearsay and partial information, and plain urban legends (like the endlessly repeated story about the Venus probe that supposedly failed because a period was typed instead of a comma — most likely a canard).

Bertrand; in his post; goes so far as suggesting that we start lobbying for Software Incident Full Disclosure Law. He explains:

Progress in software engineering will come from many sources. Research is critical, including on topics which today appear exotic. But if anyone is looking for one practical, low-tech idea that has an iron-clad guarantee of improving software engineering, here it is: pass a law that requires extensive professional analysis of any large software failure.

The details are not so hard to refine. The initiative would probably have to start at the national level; any industrialized country could be the pioneer. (Or what about Europe as whole?) The law would have to define what constitutes a “large” failure; for example it could be any failure that may be software-related and has resulted in loss either of human life or of property beyond a certain threshold, say $50 million.

In the latter case, to avoid accusations of government meddling in private matters, the law could initially be limited to cases involving public money; when it has shown its value, it could then be extended to private failures as well.

Even with some limitations, such a law would have a tremendous effect. Only with a thorough investigation of software projects gone wrong can we help the majority of projects to go right.

We can no longer afford to let the IT industry get away with covering up its failures. Lobbying for a Software Incident Full Disclosure Law is the single most important step we can take today to make the world’s software better.

If you have been reading the blog so far you probably know my take on rules and laws. I am a firm believer of flocking free and yet flocking responsibly. Besides my very own personal disliking for rules; government intervention in Google or Twitter seems to defeat the whole user-driven-democratization of the internet.

The internet; dear reader; has a government and unlike most government out there; this one works.

Remember; the users who decide whether they want their account on twitter or friend-feed?

I think we; as users; are fully capable; of voting a site up by giving it our time and attention or voting a site down by not-giving-a-damn-about-it.

The model works.

It is why nobody uses MSN or why users picked Google over Yahoo and why AltaVista was sent to gather dust in utter silence.

For projects involving lives and public money; sure; but for a private organization offering a free service like Google or Twitter; I would rather prefer to be on the camp that lobbies 'against' the Incident Full Disclosure 'Law' rather than the side that lobbies 'for' it.

Having said that; the gist of what Bertrand says is pristine and pure: Talk about your failures. Investigate the root cause and share this information out.

Take the guys at 37Signals for example. These are guys who genuinely and truly believe in 'Publicizing Your Screwups'. Their famous getting-real book describes the idea rather articulately:

If something goes wrong, tell people. Even if they never saw it in the first place.

For example, Basecamp was down once for a few hours in the middle of the night. 99% of our customers never knew, but we still posted an "unexpected downtime" notice to our Everything Basecamp blog. We thought our customers deserved to know.

Here's a sample of what we post when something goes wrong: "We apologize for the downtime this morning — we had some database issues which caused major slowdowns and downtimes for some people. We've fixed the problem and are taking steps to make sure this doesn't happen again...Thanks for your patience and, once again, we're sorry for the downtime."

Be as open, honest, and transparent as possible. Don't keep secrets or hide behind spin. An informed customer is your best customer.

Even for someone as open; transparent and open as 37Signals; they seem to stop at 'we-had-some-database-issues'. I wonder if someone at 37Signals considers these questions every time their service is down:

1. Can we explain what this 'database issue' was?
2. Do the users deserve to know what the issue was and we did or are doing towards preventing the same problem for surfacing again?
3. Is the root cause and the fix worth sharing; maybe on a separate technical blog?

Put simply; does the screw-up being advertised; as minor as it was; create knowledge that the development community in general can benefit from? 

If yes; why not share that knowledge out to the rest of the software development world as well?

If there was a blog where a project-path developer talked about his screw-ups and gave his insights on the fixes or what he learnt from the screw-ups; I would be the first regular reader there.

If folks at twitter talked about what takes twitter down and how they resolve the issues; I would love to learn from the issues and challenges they face.

If someone at Google talked about how an invalid configuration file that pretty much puts the entire internet to a stop was pushed into their production servers; and what they did to avoid the issue in the future; I would shut-the-f@#ck-up; listen; and learn from their mistakes.

Would you not like to learn from the largest and most remarkable mistakes out there too?

Oh; and while we are at it; what was your biggest screw-up?

Did you share what it taught you by posting it and lessons learnt from it; live; dear reader?

Discuss.

Filters To Keep Whiners Out.

One of my primary job roles at Multiplitaxion Inc; was to interview every single candidate that would get hired into the organization. This meant that if you were thinking of joining Multiplitaxion Inc and got through the technical rounds; I would eventually end up interviewing you.

Irrespective of whether you were a developer; senior developer; architect; manager; creative-user-interface-programmer; IT professional or a database administrator; chances were that you would go through at-least one round of my interview before you were hired at Multiplitaxion Inc.

Your first couple of rounds would be highly technical with the best people we had in the specific area for which you were interviewing. I was supposed to be more of a last minute check to see that you had the overall right attitude and culture to be joining the organization. Put simply; I was being used pretty much like a filter which was supposed to keep the junk from getting into the organization.

Now; if you were a candidate; you would probably be thinking that after having gone through two or three rounds of technical interviews your chances of getting rejected in my interview; at-least for technical reasons; were a bare minimum.

Newsflash!

During my stay at Multiplitaxion Inc; I think I may have rejected more than ninety-percent of the candidates that came to me after having cleared one or more technical rounds. My reason for rejecting them:

Lack of technical competence.

With no intentions of insulting; or undermining the intelligence of candidates who interviewed with us; here are examples of questions programmers interviwing with me have marvelously failed at answering:

1. Solve the famous Fizz-Buzz questions.
2. Write a program that prints out numbers from hundred-to-one; leave out multiples of five while printing out the numbers.
3. Give me one example of a project where you had to write your own interface and why did you need an interface.
4. How do you assign 2nd of January 2009 to a Date-Time variable Y.
5. And (believe it or not) How do you assign five to an integer variable Y.

I have had DBA's who have failed at answering questions on the lines of:

1. I have an employee table with a joining-date column which is of Date-Time type. Get me the names of the employees who joined in the year 2009.
2. I have an employee table with a joining-date column which is of Date-Time type. Get me the names of the employees who joined in 2nd January 2009.
3. I have an employee table with a joining-date column which is of Date-Time type. Get me the names of the employees sorted alphabetically.

During my stay at Multiplitaxion Inc; I interviewed IT professionals who had no clue as to what a subnet mask is; and managers who looked at you with completely blank eyes when you uttered the word 'sprint'. I've seen candidates fail at every single litmus-test-question that is out there.

Most of these are individuals; were employed in really-big body shops. To be fair to them; quite a few of them also had years of experience and top-notch-educational qualifications behind them.

At some point the folks in the recruiting department and I myself had concerns around these shocking rates at which I was rejecting candidates.

Were our builders failing that desperately at taking their first couple of technical rounds?

Was I being overly critical of the candidates?

Where were we going wrong; was it at the first couple of technical rounds; or was it at my round; we sat there and wondered for days.

Three Things Your Filters Should Know.

The mystery literally cleared itself out when we decided that we were going to let me sit through the first couple of technical rounds and then if needed let those engineers conducting the first couple of rounds sit through my round as I interviewed the same candidate.

Jack; who was one of our best builders around; started his interview of a candidate; who for the purposes of this post; we shall refer to as Fred; with questions and discussions around difference between abstract classes and interfaces. The answer was flawlessly correct. Then as he meandered from one question to another; the answers came in all right.

Somewhere during the course of the interview a sinister thought crossed my mind. Like all my interviews; I handed Fred my laptop and asked him to show me a real life abstract class implementation or example. What I saw in return was two angry young eyes staring at me in utter disbelief. The guy literally took minutes to figure believe that he had been given a laptop and had been asked to write some code.

From that point on; things went down-hill.

The interview ended with Fred taking over thirty minutes to write a reverse loop that would print hundred to one; skipping all multiples of five in between.

We dear reader; had hit a home run; with a simple realization.

The fundamental issue with Jack's opening question - difference between an abstract class and an interface - and his overall interviewing style - was that it worked under the assumption that anyone who was capable of answering harder questions on object orientation knew what for-loops were; had worked with for-loops and had done some basic programming in his life.

Sadly enough; as far as the state our software development goes that is a slightly unrealistic assumption to make.

We; the collective we that represents the software development world out there; have spent years raising army of whiners who know exactly what to read; how to clear interviews and how to say things that impress folks high up in the pecking order. Put them on the spot with an IDE and a laptop.

Watch them fumble with icons on the toolbar; clueless about short-cuts on the IDE. Watch them fail as they attempt to write the simplest of programs out there; and take hours doing that.

There were three things that interviewing experience at Multiplitaxion Inc; taught me:

1. Just because someone has a great resume and an impressive background; does not mean that the person is not a complete whiner. 
2. Make no assumptions about what the person knows. For all you know; he might know nothing. 
3. If you want to hire a singer; get him on a stage and ask him to sing. If you want to hire a programmer get him a laptop and ask him to write some code.

Months later as I scribbled the fizz-buzz question in front of a senior programmer; and asked him to quickly solve it so that we can move on to the harder questions; he quite literally retaliated with the objection: 'If I can solve this will it tell you that I am capable of doing my job?' --- The answer to this question as it turns out was rather simple and spontaneous: 'No; but your not being able to solve it will tell me you are incapable of doing your job'.

The next time you conduct interview for your organization; unless your organization is looking for whiners; try to keep one dedicated person in your organization who acts as a filter. When picking a filter; go get someone who makes no assumption and is not afraid or does not get intimidated when looking into the eye of a senior technical architect with nine years of experience and asking him to crack a for-loop.

I wish you good luck.

@BuildersAtWorkBookNotice