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.

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.

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.

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.

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.

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.

Programmer Tip: Differentiating Between Toys And Wisdom.

Have you seen a young and budding programmer flex his engineering mussels?

No; seriously.

If you get a chance to overhear two young and budding engineers bump into each other at a cafeteria or a grocery; chances are that all you will hear is a conversation which revolves around the famous which-technologies-are-you-working-on-now-a-days-question.

Observe.

There is a huge possibility that the discussion will continue forever as both these engineers try to impress each other with the cutting-edge technology they are working on in their latest project. 

You Don't work on Windows Communication Foundation yet?

Seriously?

Don't tell either one of these engineers.

If you do they might look at you like you belong to another planet.

Every now and then I personally witness the minds of more than one young and budding programmer explode when they hear that I am not working on any project that uses Microsoft Windows Workflow Foundation.

As developers we like to drool over the latest technology that Microsoft, Google or 37Signal throws our way. We crave to put it on our resumes and we get a huge technical-ego-boost out of using it in our real-life projects.

Rarely do we realize that all we are doing is tinkering around; consuming API's; tweaking configuration or should we just say --- playing around with new programming toys that are made available to us; year after year.

Now go grab the same two programmers you were overhearing at the grocery and ask them what Inversion of control is; what dependency injection is; or what liskov substitution principal is and watch them stare at you like you just dropped a stinking rat on the table.

Chances are that most of them will fail at even the fundamentals of object orientation.

Look hard; and chances are that you might even find programmers who cannot program working on some seriously cutting edge technologies out there.

If you are one lucky son-of-a-gun who landed in an organization that works on the latest technologies out there; and you have been busy slamming your fingers on the keyboard; writing code on some of the latest technologies out there and living in a technical-paradise; it is time to take a pause and reflect. 

When was the last time you studied closures as a language feature instead of just focusing on lambda expressions as a cool new C# feature?

When was the last time you picked a book on object orientation or the craft of writing better code and decided to browse through it?

When was the last time you kept some time aside for investigating how big your functions should be; what you should call them; or how you can get better at the craft of working with best invention in history computer science?

While it is OK to go grab the latest-beta-version of windows on your box; play around with ubuntu; and have fun exploring Windows Presentation Foundation; are you; dear reader; also giving in serious and conscious effort at understanding programming languages or reflecting on object orientation?

Are you  browsing through the code-base of open source projects out there and seeing how they lay out code; how they design their applications or approaches they take to solve generic problems.

As far as the world of software development is concerned; if playing with toys is important; developing wisdom and deeper insights about the craft of writing good code is equally important.

Do you actively track; realize and differentiate your playing-with-toy time from your wisdom-development time?

How much time do you spend on a weekly basis to get better at the craft of writing better code or developing deeper insights?

What are the tools you use to develop the craft; pick up deeper insights and grow wiser every day; dear reader?

Discuss.

The Requirements Were Not Well Defined.

As a part of my job role; I conduct interviews.

Tons of them.

If you read this blog; you probably know that one of my favorite interview questions is - talk about one colossal failure that you were associated with in your professional life.

The idea is simple: If you have not failed even once; you have not taken chances with your professional life. You have played it safe and you have avoided building remarkable stuff by resting the realms of mediocrity.

Put simply; you are what we call a 501 programmer.

Every once in a while however; I will find a developer sitting on the other side of the table; who; when asked this question; knits his brows; look up at the ceiling; pretends that he is trying to think of a failure really hard and then comes up with a random project name.

Ask him what was wrong with the project and watch him give random excuses with full blown jargon meant to point a finger at someone other than him.

The most common one of them all: 'Requirements were not well defined by the customer'.

Requirements were not well defined by the customer along with lack-of-process continues to remain the biggest and the most convenient excuses for most failures or fu@#kups that we as programmers are involved in.

After all these years of software development; we continue to work with customers who just cannot seem to be able to 'define requirements' for a simple payroll processing system.

Doesn't something about the whole requirements-were-not-well-defined arrangement thing sound terribly strange or fishy every time you hear it?

They Didn't Tell Me What To Build.

If you are a non-programmer; who is not associated with the world of software development; you are probably knitting your brows right now as you read thing and wondering - 'But Pops; if your clients want you to help them with their problem; how can they not tell you what their problem is?'.

To be honest here; the problem usually isn't about the client not telling you what the problem is. The problem is that over years of BDUF development; we as developers seemed to have changed our definition of requirements from a 'definition of the problem that the client has' to 'instructions on the bare minimum that I need to do to make this project successful'.

More often than not; when a young and budding programmer; who has seen his whining seniors do this; tells you that his project failed because the requirements were not well defined; what he is basically telling you; is that his client did not give him a step by step list of the bare minimum task-items that he needs to do to get the project successfully completed.

Seth Godin in one of his recent posts; describes the problem much more articulately than I will ever be able to describe it. He explains:

"What do you need me to do?"

This is a question that defines the person asking it. It is very different from, "here's what you might need..."

If you ask people for the next task on the list, if you allow them to define the thing they are buying from you, you have abdicated responsibility.

Your work product becomes dependent on the insight and guts of the person giving you an assignment. This is especially dangerous for consultants and freelancers, because the answer might be, "nothing." Or it might be a paying gig that's profitable in the short run but a career deadener over time.

Far better to reach a level of confidence and skill that you can describe solutions rather than ask for tasks.

The guys at 37Signals take this concept to the next level. They believe in showing some tough love to their clients by not letting the clients dictate exactly what they want from a product. In their classic book; getting real; they explain:

As a software development company, you have to act as a filter. Not everything everyone suggests is the right answer. We consider all requests but the customer is not always right. There will be times when you just have to piss some people off. C'est la vie.

Related to this, it's critical that you as a development company love your product. And you won't love your product if it's filled with a bunch of stuff you don't agree with.

That's yet another justification for vetoing customer requests that you don't believe are necessary.

Steve Yegge even ventures out so far as suggesting that business requirements are Bullshit:

I learned a lot about the Fine Art of Building Shit that Nobody Wants back at Geoworks, when in 1993-1994 I was the Geoworks-side Engineering Project Lead for the HP OmniGo 100 and 110 palmtop organizer products. Both of them launched successfully, and nobody wanted either of them.

People spend a lot of time looking at why startups fail, and why projects fail. Requirements gathering is a different beast, though: it's a product failure. It happens during the project lifecycle, usually pretty early on, but it's the first step towards product failure, even if the project is a complete success.

Self-professed experts will tell you that requirements gathering is the most critical part of the project, because if you get it wrong, then all the rest of your work goes towards building the wrong thing. This is sooooort of true, in a skewed way, but it's not the complete picture.

The problem with this view is that requirements gathering basically never works. How many times have you seen a focus group gather requirements from customers, then the product team builds the product, and you show it to your customers and they sing: "Joy! This is exactly what we wanted! You understood me perfectly! I'll buy 500 of them immediately!" And the sun shines and the grass greens and birds chirp and end-credit music plays.

That never happens. What really happens is this: the focus group asks a bunch of questions; the customers have no frigging clue what they want, and they say contradictory things and change the subject all the time, and the focus group argues a lot about what the customers really meant. Then the product team says "we can't build this, not on our budget", and a negotiation process happens during which the product mutates in various unpleasant ways. Then, assuming the project doesn't fail, they show a demo to the original customers, who say: "This is utterly lame. Yuck!" Heck, even if you build exactly what the customer asked for, they'll say: "uh, yeah, I asked for that, but now that I see it, I clearly wanted something else."

If there is one thing that is common between advice coming from Seth Godin; 37Signals and Steve Yegge; it is; that you cannot be letting the customer define your requirements. The first step to building a successful product; is living the life of your costumers; feeling their pain and understanding their problems really well; before you even think of building a product for them.

It Is Just A Lame Excuse. Seriously.

Requirements that are not 'well defined' are a convenient excuse for all your failures. As programmers we are so used to blaming the process and the requirement and then believing our own lie; that we rarely look back to reflect on the real cause of our failures; reflect on them; and learn from them. We don't even feel the need to practice the craft of building good software.

Next time you think back on one of your failed projects; if you find yourself blaming the customer or your business-analyst for requirements that are not well defined; stop; and reflect on how you could have understood your customer's pain and given them a genuine solution for the problem.

Saying that the requirements-were-not-defined basically puts you in the same bucket as thousands of other outsourced bodies-with-their-brains-switched-off working out of Indian body shops; and that; dear reader; is something no genuine programmer worth his salt should strive to become.

Next time you are working on a product; either build something which solves a problem you yourself have; or live the life of your client; connect to them; take time to understand their problem; feel their pain and add a little bit of yourself to the solution you give them.

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.