Multiplitaxion Inc; a consultancy services organization I worked at years ago was an organization where Managers sat in ivory towers and gave strange; unclear instructions to engineers. Then when you started working; they would score a foul by emailing you about a completely disconnected topic; turning you from a programmer to a multi-tasking joker.

A classic example of unclear instructions happened at a project where we were building device drivers for a multi-functional device. This is when two young engineers fresh out of college were asked to --- 'map device codes to device names' halfway down the project.

What followed; as I watched in horror; was a long tale of errors and confusion; as these two young engineers; too scared to ask and get an intimidating response back from their managers; fumbled through the project document repository in an attempt to find the document that contained master device codes; device names and their mapping. Turns out; the repository had no such document.

After a couple of days of fumbling when the engineers asked for the device codes they were sent an email containing all the device codes that could exist in the system; leaving them to ask for all the device names and the mapping information between the two.

The entire cycle took three days of emailing back and forth after which they finally had everything they needed. It took more than five emails back and forth. One email had device codes; the other hand device names and three others had 'business logic' on how they could map device names to device codes.

My exposure to prickdom however; came when I needed additional specifications of the device and asked for the information I needed. Turns out; the manager was being bogged down with meetings and was too busy to respond to my email. What I got in response of the email I sent was an attachment. It was excel file containing device codes; names; the device specifications and the mapping between the three pieces of information.

As I scrolled through the email trail that had been forwarded to me; I learnt that the file had been sent by the client a couple of months ago.

A Gazillion questions filled my head as I glanced through the file:

1. Why did the manager not upload the file on the project repository and let everyone know?
2. Why did he not send the file to the two young and budding engineers when giving them their assignment?
3. Why did he actually take the pain to extract information out of the file; paste it in an email and send out only partial information over to the engineers; even when they explicitly asked for the information?

While this may sound like an extreme example of prickdom; I have seen managers around the world holding on to information and being highly reluctant to share it out; almost as if their job depends on what they know and what no-one else in the project team knows. Others spam the team with random information that the team does not need in the first place.

Joel Spolsky provides sound advice to young and budding managers when talking about the topic to human task switching. He explains:

On the individual level -- have you ever noticed that you can assign one job to one person, and they'll do a great job, but if you assign two jobs to that person, they won't really get anything done? They'll either do one job well and neglect the other, or they'll do both jobs so slowly you feel like slugs have more zip. That's because programming tasks take so long to task switch. I feel like when I have two programming projects on my plate at once, the task switch time is something like 6 hours. In an 8-hour day, that means multitasking reduces my productivity to 2 hours per day. Pretty dismal.

As it turns out, if you give somebody two things to work on, you should be grateful if they "starve" one task and only work on one, because they're going to get more stuff done and finish the average task sooner. In fact, the real lesson from all this is that you should never let people work on more than one thing at once. Make sure they know what it is. Good managers see their responsibility as removing obstacles so that people can focus on one thing and really get it done. When emergencies come up, think about whether you can handle it yourself before you delegate it to a programmer who is deeply submersed in a project.

At the end of the day it is not just about multitasking. If you call yourself a manager; a leader or whatever-it-is-that-you-call-yourself; it is your responsibility to see to it; that your fellow programmers have precise; compact and concise information to act on the tasks that you expect them to work on.

Do not start parallel threads of work; don't make them starve or look for information when it is readily available with you; and don't bombard them with more information than what is necessary.

If you are not comfortable leading from the front; the least you can do as a manager; dear reader; is get down from your ivory tower; develop a strong bonding with your team; show some empathy; stick around as a helper as they slog; and when they need information make the information available to them; without making them beg for it; or bogging them down with too much data or information that they do not need.

If you can just do that; you have probably taken your first step towards fearless project management without a lot of insecurity.

I wish you good luck on your way ahead.

Remember; if they are confused and lost as they develop; it probably is your fault.

Wikipedia defines Lorem ipsum in a website design proposal as - generally incomprehensible placeholder text allows viewers to focus on the visual elements, rather than the content.

Lipsum - the online Lorem Ipsum generator is bullish about the Lorem Ipsum history and future:

Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book.

It has survived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged.

It was popularized in the 1960s with the release of Letraset sheets containing Lorem Ipsum passages, and more recently with desktop publishing software like Aldus PageMaker including versions of Lorem Ipsum.

To be honest; Lipsum has a genuine reason to be bullish about Lorem Ipsum.

Graphic designers around the world have loved Lorem Ipsum for more then one generation.

Even today; I see countless graphic designers designing their site-layout using Lorem Ipsum; sending the designs out for review and then replacing them with real content as the project moves ahead.

Most graphic designers love Lorem Ipsum because it keeps them from having to work with those nasty business guys who are way too lazy to think about or give them genuine content upfront. Lorem Ipsum also shields the designers from those pesky programmers who make them fix their nasty HTMLs every time the designers try to work hand-in-hand with them.

The business folks love it because it allows them to walk up to a creative designer and say - 'I want a marketing website' - without having to worry about giving them any content or specifics before they start designing the website.

The programmers love it; because they can now develop their system without having to worry about synchronizing their development with the pretty-looking-screens.

Throw in a few stock photos; make pretty boxes; fill them up with Lorem Ipsum; and you are good to go. Life; for a designer; was never so beautiful before Lorem Ipsum showed up.

Put simply; at the end of the day; programmers love building ugly systems; graphic designers love building pretty boxes and business users love telling both programmers and graphic designers what they should do without feeling the need to take any real responsibility of the content or the message upfront. Lorem ipsum is a universal glue that makes this entire ecosystem function and makes all this possible. No wonder; we all love Lorem Ipsum.

Jason Fried at 37Signals however; has the courage to walk a different path and say no to Lorem Ipsum. He advices developers and designers to consider Lorem Ipsum their enemy; not their friend. He explains:

Lorem ipsum dolor has long been known as the designer’s best friend. We think it should be your enemy. Using lorem ipsum dolor reduces text-based content to a visual design element (a “shape” of text) instead of valuable information someone is going to have to enter and/or read.

We recommend that when you build out interfaces you use real and relevant words not “lorem ipsum” representative text. If your site or application requires data input, enter real and relevant words and type the text, don’t just paste it in from another source. If it’s a name, type a real name. If it’s a city, type a real city. If it’s a password, and it’s repeated twice, type it twice.

The goal here is to get as close to the real customer experience as possible. Don’t abstract yourself from the real experience. Every layer removed pushes you further and further away from the actual customer experience.

Ben Hunt in his book; Save the Pixel; explains the same thing from the perspective of a veteran experienced web designer. He explains:

Design the content, not the box it comes in.

Use your pixels on things that communicate meaning. It used to be very common for web designers to make just templates – attractive or jazzy  containers which would have “content” added at a later time.

This is a fundamentally wrong approach, because it doesn't fulfill the designer's mission - facilitating communication. If you find yourself decorating the package, rather than crafting real, meaningful content, stop & ask: “Are these pixels best used here?”

You want the visitor to focus on the navigation & content as that's where the signposts are that point to the goals.

When you are designing the layout of a website; it is easy for you to get consumed by just the layout and not even think about the content or what the design is trying to communicate in the first place. Ben describes this concept rather articulately in his book - Save The Pixel. In his book he explains:

Design isn't Art. It's not about creating beautiful or thought-provoking things for the sake of it. Design is a discipline – creating communication with a purpose.

So the next time you head out to a Lorem Ipsum generator; try spending some more time on your content or your system and try to figure out the message that your application or website is trying to convey using your design. If you don't have a strong message your pretty boxes will not mean a thing.

Now; go think of a concrete message and decent amount of content or the system before you even open Photoshop.

This dear reader; is your chance to designing something meaningful.

Don't build pretty boxes with Lorem ipsum. Let your design be a part of your communication; what you want to say and what it is that you stand for.

I wish you good luck.

Sam at CodeOder.com asks a rather interesting question; asking which is much like opening a can of worms.

Sam's question seems like a simple question raised by an inquisitive mind; but scratch the surface of the question and you will realize it is not just a controversial question; but a question that can end up defining your character and life-style as a software developer. Sam questions:

We hear vague descriptions about project size tossed about all the time: Ruby on Rails is better for small projects. Java is for large projects. Skip the framework for small projects, but I recommend using one for large projects. What factors go into determining the "size" of a project?

Reflect on the question dear reader; and chances are that you might realize the problem in attempting to answer the question. You probably know this already. If you do not; ask anyone who has spent even a couple of years programming and estimating projects and he will tell you that:

1. Simply counting LOC or number of lines tells you nothing about the project size. It is a ridiculous metric.
2. Complexity is not indicative of largeness but just bad design.
3. Large team size is not an indication of a large project but just an indication of bad management.

And so; if we as programmers; are going to take every metric out there and thrash it against the wall; how are we to then; dear reader; measure which project is large and needs special attention and which project is small and can be built easily?

As a young and budding engineer at Multiplitaxion Inc; years ago; I was a part of countless meetings where my ideas were turned down with stereotype remarks like - yes-we-know-it-worked-for-your-project-but-our-project-is-really-large.

Attending countless number of those meetings taught me that the difference between a large project and a small project can be described using this rather funny code snippet on the sun java forum:

'Large Project' usually does not mean or do a thing other than give you a warm and fuzzy feeling of being involved in something complex deep down inside; and that dear reader; is not such a good thing.

No; seriously; if there is one thing years of programming; software development; and software management has taught me; it is that if you are working on a 'large' project you are doing something wrong.

Now; stop drooling over how large your project is; how huge a team you have; and how many lines of code you have to write. Go ahead; break your next so-called-large project down into smaller components and start hiring kickass developers  who can design each component like there were neatly cut pieces of diamonds.

I wish you good luck.

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

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

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

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

That is exactly what makes TED so beautiful.

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

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

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

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

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

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

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

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

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

Word of advice; stop talking and ship.

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

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

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

I wish you good luck.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I wish you good luck.

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

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

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

Emails providing details about mundane; irrelevant facts like:

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

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

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

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

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

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

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

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

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

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

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

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

Facing a problem fixing that code you are working on?

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

I wish you good luck.

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

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

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

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

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

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

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

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

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

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

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

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

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

My Point?

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

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

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

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

I wish you good luck.

What Are You Spending On - Programmers  Or Infrastructure?

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

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

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

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

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

Ready?

Here we go.

Fact one - Infosys campus is huge and beautiful.

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

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

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

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

Fact two - Pillars Without A purpose.

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

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

The guide agrees.

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

Fact Three - Domes without a meaning.

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

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

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

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

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

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

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

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

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

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

And The Point.

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

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

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

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

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

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

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

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

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

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

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

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

I wish you good luck.