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.

Team Contributions.

In an insanely huge meeting room; at a client who for the purposes of this post I shall refer to as Multiplitaxion Inc; a 'Yearly Status' meeting begins. As an external consultant who has been around for more than six months and has given more than one successful implementations; I am also invited to the meeting.

I look from one end of the table to another; my brain doing some serious soul searching and asking some rather philosophical questions to myself:

1. Why am I here?
2. Why are we all here?
3. What are we trying to achieve?

A vice-president opens the meeting with pep-talk on how team-work is essential for overall synergy and growth of the organization. He then talks about how personal contributions are nothing compared to team contributions and how we are all a big happy family.

I cringe.

Three of us have been working for sixteen hours a day for the last one month.

We are; probably the selected few who have shipped anything; in the last six months.

Something tells me I should talk.

Challenge the concept of team contributions being something larger and divine than our very own personal contributions.

Then I realize; I am not even a permanent employee of this organization.

I keep my gob shut. It is a short temporary hibernation or more of an End-Of-Yes-But-Discussion-Hash-Tag applied mentally.

My eyes reflect clear and open disagreement.

I look from one end of the table to another; looking into the eyes of the team members I've been working with; they are rolling their eyes in disagreement too.

The rolling pair of eyes tell me one thing: right here; in this meeting room of professionals there is a small tribe of selfish individuals who build stuff.

I feel happy.

It tells me that this room has a selected few who; thank god; are not working for the best interest of the organization. Just their very own personal selfish interest of being involved in genuinely successful implementation.

I feel safe.

Individual Contributions

I'm going to spare you the pain of having to go through a thousand words and over a dozen examples pulled out of history; that prove one thing: Almost any innovation worth its salt has been an idea and implementation that emerged out of one single mind.

Remember the Google's proprietary ranking algorithm that set them apart from a dozen other search engines out there? We call it 'Page' rank. Not because it ranks the pages but because it was the brain child of Larry Page.

Linux? Linus Torvalds.

You name a successful website; service or application out there and chances are; that if you look deep down into it's history you will find the single mind that conceived and executed the idea till the point where other builders started joining in.

What Drives Builders To Start Stuff.

Anyone who tells you that he is working for the best interest of the organization; is probably a whiner of the first order.

Anyone who tells you that he is sacrificing his own interests and is building stuff for the team or is doing so to make the world a better place is also a whiner of the first order who knows nothing about building stuff.

Any manager who tells you that teams comes before individuals and gives you a pep-talk on how the-we-comes-before-me is not a manager. Just a whiner who lugged on to the we-wagon and kept taking credit for stuff other builders around him were busy building. Someone who could neither master the art of build nor contribute through genuine story-telling about the product.

Veteran blogger; Jeff Atwood; usually ships one magnificent gem of a post every weekday. Now; if you have never owned a blog; try owning one; and try writing anything meaningful just once a week. I can tell you first hand how hard it is. If you wonder why Jeff spends countless hours writing; it is not to change the world or to help the human race move forward. He explains:

We may kid ourselves into thinking we're writing out of some sense of public good, or to create connections, or contribute some small bit of knowledge to the world. But let's face it. Most of us blog because we're raving egomaniacs. We not only love to hear ourselves talk, we're incredibly eager to hear other people talk about us, and the more the better. I think Dale Carnegie put it best.

Nothing is sweeter to someone's ears than their own name.

So it should come as no surprise that I have an automatic Google ego search set up for my name. Nothing special about that. It is considered neighborly to have your ear to the ground (within reason), and to politely comment on relevant articles mentioning you and your "stuff". All very standard, banal, ego-fluffing stuff.

Ask any genuine builder out there why he does what he does and you will get his reasons: 'because I love doing it'; 'because it is fun'; 'because it makes me happy'; the reasons will continue. Long story short; most genuine builders are aware that they build stuff for their very own selfish reasons.

Most ideas that survive as a platform start as a personal problem.

The story invariably begins like this: someone with an eye for spotting problems has a problem in his real life; spots it; figures out an answer to the problem and starts working on it; for a very long time.

Half way through other builders join in; create what marketing guys and traditional managers like to call synergy and you have a remarkable product that ultimately ends up making small or big dents in the universe.

But Then Why Would Other Builders Join In?

I can almost see a young and budding manager knitting his brows already. 'Great! Now you are suggesting that team work means nothing. That we all focus on individual contributions and forget the whole idea of contributing towards a team' - he says.

Yes; Mr. Manager. That is precisely what I am suggesting.

As someone who has himself makes contributions as patches to open source projects out there; I can tell you that I do not do it for the good of mankind or some other noble agenda of that sort.

I do it purely because I want the patch in the project SVN so that I do not have to worry about making the change every time I upgrade the version of the framework.

The folks who receive the patches are happy to apply them because it makes their product stable gets more people to use their product and gets them more popularity and in some cases an ego-boost.

None of us are working for the divine-goal-of-the-team.

None of us are giving or taking a truckload of crap about keeping 'the-we-before-the-me'.

We have common selfish interest which are aligned; which bring us together.

The teamwork; helping each other or even the so-called-management-buzz-word called synergy results out of these commonly aligned and totally selfish interests.

In fact; these are precisely the cases where the teamwork is the highest; where people from completely different countries, cultures, time-zones and people who do not even know each other; come together and make things work.

Now here is the funny part - you don't hear words like synergy and we-is-more-important-than-me in these environments.

When builders see amazing stuff being made; they will join in. They will join in because they want to be in the flow; they want to be a part of something huge that eventually leaves a mark on lives of people; they want to learn something new; they want to find and create meaning out of their very own lives; they enjoy being a part of it or for countless other reasons all of which are totally selfish.

Make no mistakes about it.

Lets Stop It. Now. Seriously.

Lets work on a project shall we?

Hypothetically; that is.

For reasons that are purely selfish; I will give in complete individual contribution to get my module up and running in time. I will bend over my back to help you integrate with it. As a matter of fact; I will even go out of my way to help you with your module; purely because; one: it makes me feel good about doing that; two: because it establishes me as a really smart person in the team and three: because I don't want a failure against my name.

I expect you do the same; for similarly selfish reasons.

If our interests are aligned; we win.

If they are not; we fail.

It is really that simple.

Can we please stop talking about team-work, synergy and exchanging truck load of crap regarding how the we-is-more-important-than-the-me or how the team-comes-before-individuals. It's boring; hugely artificial and not even funny.

If you run a team; may I suggest; dear reader; that instead of giving your team long winded lectures and speeches on how the-we-is-more-important-than-me; give them a platform where every person in your team can genuinely and truly contribute individually.

Build an environment where they get credit and recognition for their individual contributions.

Find folks who have interests that do not align with yours and get them on projects where their interests have a higher chance of aligning with yours.

Do that and all the pep-talk on teamwork and synergy that you always gave in your meetings; will not even be necessary.

Recognize the important of individual contribution and all of those organization-changing ideas that you had about team work and 'synergy' will start turning into reality; faster than you can think.

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.

Climbers.

You are a young, budding and really smart graduate fresh out of college.

You have landed with your first job.

Ambitious; full of dreams and a relentless desire to grow and climb the corporate ladder rather quickly .

More sooner than later you will be faced with a hugely important decision of picking the growth path you want to take.

A choice.

The sky will fall; and you will find yourself exercising frequent skips; playing the blame game; or hinting to your manager how every single f@#kup that happened was not your fault.

You might also find yourself casually hinting to your manager whose fault it was.

When the yearly reviews happen; you would have jumped ahead of all your colleagues; your manager has developed a reputation of your being an alpha-geek who never fu@#ksup and you would have earned your promotion.

You; are a climber.

Choosing to be a climber is a perfectly legitimate career choice; except of-course that there is just one minor hiccup associated with it.

Empathy.

You give none of it; you get none of it.

Yearning desire to indulge in the act of 'climbing' probably creates more asshole than any of the other reasons.

Brief Digression and a quick history lesson.

The battle of Gaugamela is taught in practically every history class that talks about Alexander. An example of amazing planning and war techniques; what only a few history books will tell you; is that this war was also a classic lesson in managing intelligent human beings; growing as a leader and winning wars.

After a fierce battle; execution of an amazing war plan; Alexander is practically minutes away from slaying his arch enemy; the Persian King Darius III; when Parmenion; a general in the army; sends out a distress signal.

The choices Alexander is faced with are fairly simple:

Continue his advance; slay Darius; win the battle or Turn around; move to help Parmenion and let Darius escape.

Alexander chooses his men over victory.

He helps Parmenion; lets Darius escape and eventually wins the battle.

Historians around the world will tell you that what Alexander really won in Gaugamela; more than the battle; was respect and trust of his army; which eventually won him multiple other battles that followed.

The Builders Path.

If you are in any remote way associated with software development; like it or not; the sky will fall; and when it does; I don't care how amazing your work culture or your work environment is; someone high up in the pecking order is doing to ask the question that ultimately destroys projects around the globe:

"Who was responsible for the fu@#ckup?"

When the sky falls; you are left with pretty much two simple choices: you can take the climb path or you take the build path.

The build path happens to be slightly less glamorous.

You find yourself sitting in front of your colleagues monitor; helping them out with threading issues.

You find yourself trying to talk about the problem rather than answering irrelevant questions like who was responsible for it.

You find yourself giving cover fire to your team and every once in a while you find yourself in a heated argument with your manager; which to be honest; is not the best way to get a promotion.

But then; you and your team scores and when the promotion comes and you have a fancy sounding designation on your business card; you know you at-least you didn't 'climb' ruthlessly all the way up to it.

If software development is a war; build stuff that is remarkable; and when given a choice; pick your men over victories.

Successful projects will follow pretty much magically.

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.

Your Political Virginity.

I don't care how lucky you are. I don't care how amazing your work culture is. If you; dear reader; have not taken a few punches of office-politics; at-least once in your life; you haven't learnt enough. 

You think that the bully who made you do all the work in the school project and took all the credit for it; when you were in school; was an asshole?

You have no idea what your first political experience at an organization is going to be like.

You; are still a political virgin.

Days move on and then one seemingly beautiful morning; you find yourself in a hostile political environment of a really-shitty-client-and-his-organization.

That's when it hits you; really hard.

Smack on your face.

It is at this point that you lose it --- your political virginity.

If you survive the blow and find yourself reading this; pat yourself on your back.

You are now a 'manager'; for better or for worse depends on the survival approach you picked.

Survival.

For me; my first exposure to the stupidest form office politics was at a client; where I was stationed for a period of three months. For the purposes of this post; dear reader; this small client of mine comprising of around a fifty odd people; shall be called Multiplitaxion Inc.

Multiplitaxion Inc, had a team of three genuine builders who were not just surviving but thriving and getting things done.

I called them the three musketeers.

Three young programmers who were; what Steve Yegge would refer to as --- done and getting things smart.

Fun loving guys; who were good at what they did.

What I found most amusing when I met this team; however; was that they had not just survived the politically hostile environment at Multiplitaxion Inc; for months; but had actually thrived in it.

When I joined their team; they were under the management-microscope.

The mere act of joining the team meant that I would be under this microscope too.

Management Microscope.

Did you push the release on time or were you late by a day?

Did you follow the organizational process and send an internal daily report to your manager?

Did you remember to spell-check your daily status report?

When you are under a management microscope everything you say or do can and will be used against you.

I can give you a thousand reasons about why you might find yourself under the management microscope; but each one of those thousand reasons eventually boils down to this:

Someone up there in the pecking order of your organization does not like you.

You make them feel insecure.

Our microscope at Multiplitaxion Inc; extended all the way; office timings; documentation; discipline; formal attire; you name it and we were being monitored and criticized for it.

The funniest part however; was that none of these three individuals answered any emails pertaining to random irrelevant criticism.

I on the other hand; had an irresistible itch; of providing equally long-winded responses and explanations.

Before I sent out my responses; however; I asked why they did not; and learnt about 'fouls' and 'goals'.

Fouls And Goals.

One of them pointed at a recent email which complained about how we didn't spell-check our status report; smiled and said - 'This right here; is a foul'.

Like all good things; the idea was stupid simple.

Every random criticism being thrown at the team was referred to as a foul.

If there was one fact everyone in this really small team understood it was this:

You do not win soccer matches by fighting over fouls. You win them by scoring goals.

A week before the project ended; we scored.

As a response to a month old email that complained about an internal status report not being spell-checked; one of the three responded with the latest status repot which showed that we were a week ahead of schedule and were done with the project. The report also mentioned that we had a formal sign-off on User Acceptance Testing from the QA department and the business users.

Then; he signed off the email with the words which were on the the lines of:

"This one is spell-checked. Special thanks to you for your continuous support and encouragement during the course of the project".

During the course of the project there were over scores of emails that none of us responded to.

When the project ended I was glad we did not.

This team; dear reader; did not need a manager to sedate the monkeys - we had survived the stupidity of office politics; and we; dear reader had picked the survival path of scoring instead of haggling over fouls and learning the art of whining.

Would I go back to work for this client again?

Absolutely not.

Something tells me none of us from that team would.

Having said that; what this client of mine, taught me was invaluable.

If you happen to be my manager in future; and if you send me an email; telling me how critical it is to use 'Verdana' font in the internal status report; that only you are going to read; please do not expect a response. You dear; manager; just scored a foul.

I am sorry for not responding but I will try my best to respond when I am done with scoring a goal.

Honest. I will.

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.

My Gripes With Technical Writing.

My previous blog was all about technical writing. As a young and budding developer; some of the posts out there were aimed at talking about the latest cutting edge technology; flexing my engineering mussel and getting more traffic out of Google.

As I wrote the posts however; I realized that; unless you are talking about the products you are yourself involved in; technical writing is harder than any other forms of writing.

Unless you genuinely believe in the craft of story-telling; the life-cycle of writing a technical post pretty much goes like this: You take a topic; you dissect it; you understand everything there is too understand about it and then you try to pass that understanding over to your readers. It was almost like taking a traditional approach to teaching.

After a while; I realized that there was one word that describes this entire process: Boring.

Don't get me wrong; dear reader. The mere act of writing code or reading it isn't boring. It gets you in the flow and does amazing things to your life. Having said that; the very process of writing about code; or reading about it; is in fact very boring; and there are multiple reasons; dear reader; why this is the case.

I'm going to make a humble attempt at touching some of these reasons and try to figure out why most technical articles or books out there are unable to keep my attention span end-to-end.

Ready?

Let's get started with my gripes on technical writing.

Technical Writing is Based On Facts.

Let's face it; the way most technical writers of today write; Dependency Injection is basically --- dependency injection. That's where most technical writers of today start and stop. Take the Wikipedia definition of dependency injection; for instance. Here is how it goes:

Dependency injection (DI) in computer programming refers to the process of supplying an external dependency to a software component. It is a specific form of inversion of control where the concern being inverted is the process of obtaining the needed dependency. The term was first coined by Martin Fowler to more clearly describe the mechanism.

The very first sentence is a turn off. By the time you near the end of the article; you can hear yourself snoring out loud.

It isn't Wikipedia's fault though.

What Wikipedia is doing; dear reader; is capturing facts and presenting them to you. This is what most other technical writers writing technical books seem to be doing. Most of them; seem to base their books or their writing around facts; and the inherent problem with this approach; dear reader; is that facts; are boring.

Lack Of Spice And Information Surrounding The Content.

Pick a few basic books on neuroscience and they will tell you a great deal about how our brain stores and interacts with information. Neuroscientists; around the world; up-till the recent times believed that information in the human brain is stored in a central location and that lesser the information the easier it is to commit and recall.

Recent opinions however; seem to suggest that information in the human brain is basically stored all over the place; and the human brain uses the 'context' to get you a faster recall. Long story short; dear reader; spice and some amount of irrelevant information; connected with the fact is just as important as the fact itself.

I first understood the importance of this brain-rule during my French-classes.

To illustrate my point; dear reader - I am going to teach you some French.

Ready?

The French word for 'who' is 'qui' - I want you to commit this to your memory - get on with your life and do a recall a couple of months later.

Now; if you are like most of us; chances are that a couple of months later; as you move on with your life you are going to forget this piece of information all-together.

Now; do this - turn the literal fact - "who in English equals qui in French" - into a tiny little sentence with some useless information and some context.

Put simply; just try and remember the English sentence - 'who has the key'.

Now; given that the pronunciation of key and qui are exactly the same; months later; when I ask you the French translation of 'who' - chances are; that you will not just remember the French translation; but you might actually have a faster recall.

Ok; back to technical books on programming. The problem with most technical books today; is that they lack this additional spice and information that is supposed to make it easier for people to remember the facts that the book is presenting.

When it comes to technical writing and reading about code; less is not more. In fact; neuroscientists around the world will tell you that when it comes to storing information about a fact; the more random connected information you have about the fact; the higher your chances of remembering that fact are.

Now; look around. Take a look at all the technical books you have. Also take a look at all the technical blogs that you can find online. How many of them give you this additional information connected with the facts they present? How many of them provide you with additional; hugely interesting information that helps you commit and recall the stuff; faster?

Thought so.

This Thing Is Supposed Be Fun.

I've known some amazing fun loving authors and have had the pleasure with observing them or even remotely working with them. These are seriously fun loving guys who can take a concept and drill it into your head by the time you are done with your lunch with them.

However; when they indulge in the act of technical writing; you somehow seem to get a sense that you are reading a completely different individual all together. Pick their books and you will realize that the sense of humor is gone; the jokes are gone; the funny analogies are gone.

What remains is a me-too book or a me-too programming blog on C# or Ruby On Rails that other C# or Ruby On Rails programmers go to.

Over years; our technical writers and authors around the world seem to have nurtured the thought that a technical book ought to be something 'serious' and 'professional' and therefore it is completely inappropriate to go out and experiment when you are writing a technical book or a technical blog-post. That dear reader; makes most technical books and blogs out there nothing more than material that you reference when you are stuck with a problem.

When was the last time you picked up a book on Design Patterns and had 'fun' reading it?

When was the last time you giggled while reading a book on C# programming?

When was the last time you had a deep realization that triggered a chain of thoughts while reading the explanation behind a code-snippet?

Technical Writing Lacks Persona.

Every book; be it a novel; or book about software development; reflects the author's personality. Most technical books out there however; don't.

We have seen the use of F-word; in books and blogs that are connected to software development.

We have seen management books use words like Asshole.

We have seen books on organizations and entrepreneurship which move and inspire.

The idea is not just to grab the attention of readers with purple-cow words; but to leave a little bit of your daily-persona into the book when you are writing it.

While it is true that no-one cares about you or your product; it is also true that there is a little bit of you in everything that you do and that little-bit-of-you makes everything you do different. Most technical writers however; seem to miss out on putting in a little bit of their personality into their technical writing.

We are Taking It Way Too Seriously.

There are over two hundred blogs that I subscribe too. The ones I love the most are blogs where authors take chances; post something that is wrong; learn from their comments and then go out there and change with time.

While the whole idea that authorship does not mean authority seems like a well known fact in blogs that do not talk about code; the ones that do; still seem to be a little hesitant at being opinionated; passing on their own thoughts and insights about the code they are explaining and making blatant mistakes while they do that.

As a matter of fact; most authors seem to take the easy-safe-boring way out; which is to eliminate this information all together.

As authors and programmers are we taking what we write or read; way too seriously?

Are we missing out on all the fun connected with making mistakes and learning from these mistakes?

After all; there is something to be said about learning with a mind of a child.

As I slowly start nearing the end of my first book and as I find more time to fly-free; every 'once-in-a-while'; I plan on working on an article or two that touches code; programming techniques and even design approaches; to see if I can add a little bit of myself to my technical writing.

The idea; dear reader; is to introduce you to my very own personal code persona that has it's very own approach to dissecting and trying to understand code; programming techniques; and information pertaining to improving your programming skills that is freely available out there.

Maybe; I'll make a fool of myself; maybe the articles will not be 'technical enough' for a few hardcore programmers out there. Maybe they may not fetch me all the Google traffic that my older blog used to fetch me; but I am going to go ahead and give it an honest shot anyways.

If you are a programmer at heart; you should too.

Go add a little bit of spice; fun and yourself to every seriously technical post that you are about to publish on your blog.

I dare you.

Small aside: If there is a book or technical blog out there that you know of; which goes deep into programming; code and design in a way that is fun; if you know a book or a technical blog that has an interesting persona of its own; I would love to read it. If its a blog I would love to subscribe to it. Go ahead; drop me a comment; or send me an email.