free html hit counter
Posted on: Sunday, 29 November 2009 by Rajiv Popat

As programmers we love the idea jumping up to build a new system at every given opportunity.

At Multiplitaxion Inc; I see a few young and budding managers attend a conference for a project management tool by a software development giant. They come back hugely serious; excited and amazed; much like babies who have found something new to explore and play with.

When I see them bubbling with excitement --- I cringe.

As programmers we have a tendency to get hugely excited about building something or putting a completely new system in place. Walk up to a programmer and tell him that you are having problems with people not applying for leaves in advance and chances are; he will tell you; you need a leave tracking system in place.

Tell a developer that you are trying to start a small library to encourage people to read books and chances are that he will tell you how badly you need a library tracking system.

To be honest; it is not just the excitement of building something new that gets the programmer within us excited. As geeks we love to also connect using familiar systems. The problem with having a whole lot of systems in your organization however; is that if you get make too many systems available to your builders and geeks; chances are that they will never connect and communicate at a human level.

Folks at 37Signals have interesting advice to give to people who are looking for a 'system' to track the feature requests. In their classic book; getting real; they explain why you should just forget your feature requests instead of trying to log them in a formal system:

Of course we don't fault people for making requests. We encourage it and we want to hear what they have to say. Most everything we add to our products starts out as a customer request. But, as we mentioned before, your first response should be a no. So what do you do with all these requests that pour in? Where do you store them? How do you manage them? You don't. Just read them and then throw them away.

Yup, read them, throw them away, and forget them. It sounds blasphemous but the ones that are important will keep bubbling up anyway. Those are the only ones you need to remember. Those are the truly essential ones.

Don't worry about tracking and saving each request that comes in. Let your customers be your memory. If it's really worth remembering, they'll remind you until you can't forget.

James Shore and Shane Warden come heavily on the simple idea of a bug tracking system in their book - the art of agile development. They explain:

Unless you're writing software by and for yourself, you will have to deal with at least one other person somewhere during the process. A grudging détente is not enough; you need to work together effectively. This means forming solid working relationships that are built on honesty, trust, cooperation, openness, and mutual respect.

You can’t force people to do this. The best your agile method can do is support these sorts of relationships. For example, one way to engender healthy interaction is to have people sit together and collaborate in pursuit of common goals.

It’s far easier, unfortunately, to craft your method in a way that discourages healthy relationships. An extreme example (sadly, one that actually happens) is forcing all developer communication with stakeholders to go through business analysts. As another example, a sure way to damage programmer / tester relationships is to require them to communicate solely through the bug-tracking system.

Ideally, your team will fix bugs as soon as they find them, before declaring a story "done done." Nobody’s perfect, though, and you will miss some bugs. Schedule these bugs with story cards, such as "Fix multiple-user editing bug." Schedule them as soon as possible to keep your code clean and reduce your need for bug-tracking software.

The point here; dear reader; is not to throw away all your systems of organization and turn into wild programmers who write random code. The point in fact; is all about is about letting go of access baggage and getting your basics facts right.

If you genuinely want your programmers to connect and communicate; first get rid of any excess 'systems' that you can possibly get rid of. Of course there will be some - like a version control system or the IDE in which you develop - that you cannot and should not get rid of; but reflect on and question the existence of every other system that you can see running in your organization.

Once you have done that; give your programmers opportunities to genuinely connected to each other verbally; their programming skills and their communication skills being the only two options left open to them and chances are; that they will use them both to the best of their abilities.

With no CYA systems in place and with free flow of information you will feel every ripple in your organizational pond and believe me dear reader; you will not need a fancy project management tool or an expensive bug tracker to find out what is going on. Honest.

posted on Sunday, 29 November 2009 22:41:31 UTC by Rajiv Popat  #    Comments [3] Trackback
Posted on: Friday, 27 November 2009 by Rajiv Popat

At work; as a labs project; Kaushik Das; who is one of our seriously talented developers has been working on studying the SQL Server Schema --- just for the fun of it. To turn this learning into practical implementation instead of just theory; we decided; to build a web based administration console which users can use manage SQL server instances that they have access to using a web based administration console. This; is how eFORCE SQL DB Administrator was born.

Put simply; the first version of SQLDBAdmin by Kaushik; in it's scope and basic philosophy is pretty much like any other web based administration console for SQL server; one common example being - Microsoft Web Data Administrator.

We do realize that this problem has been solved multiple times before; and we also realize that as of today SQL DB Admin happens to be a 'me too' product; but what we believe makes SQL DB Admin worth giving a try are the following facts:

  1. Looks and feels just like the SQL Server 2005 Database Management Studio - so there is very little learning-through-fiddling that needs to be done. 
  2. It is free and open source; which means you can not just download it but actually modify the source code for your implementations if needed.
  3. We will be working really hard to add new features to SQL DB Admin which might make it easy to do day-to-day administration tasks. Some examples include: scheduling a database backup, compressing a database, re-indexing a table. etc.

As of today you can grab a copy of the SQL DB Admin code base by visiting its codeplex site.

As a matter of fact; this is one of those projects that we just started for 'fun' and now that we have something that works; we are seriously looking at adding new features that give you; dear reader; reasons to download it and use it while comparing it with multiple other web based SQL server administrators that are out there.

If you; dear reader; have a task or a feature in mind that you or your database-administrators do regularly on SQL server administration front and you would like to perform the same tasks through a web based console; let us know about the feature and we will try out best to squeeze those features into the road map for SQL DB Administrator.

In the meantime; if you want to grab a copy of the latest code base and start using it in it's current beta stage; you can get a copy from the SQL DB Admin codeplex website.

We genuinely and sincerely hope that this product; makes your life; as a database administrator; developer or anyone who has to manage multiple remote databases behind the firewall; just a little more easier. We will continue to add new features to SQL DB administrator and then blog about those features when we add them into the product.

Wish us luck.

More open source goodness coming soon.

Stay tuned.

posted on Friday, 27 November 2009 20:44:36 UTC by Rajiv Popat  #    Comments [0] Trackback
Posted on: Thursday, 26 November 2009 by Rajiv Popat

Throughout my career; if there is one thing I have seen a lot in the software development world; it is; programmers who cannot program pretending and advertising that they are the alpha geeks of the millennium.

When I was a young and budding programmer; brimming with dreams and confidence; I walked the world of software development assuming only three kinds of people existed in the world of software development:

  1. Alpha-geeks who were kick-ass programmers making huge dents in the universe with their code.
  2. Passionate programmers who knew how much they sucked and were on the life-long path of learning how to become kick-ass programmers.
  3. Programmers who could not program but were busy pretending they were alpha-geeks.

Then; years later; while consulting for a client; who for the purposes of this post; we shall refer to as Multiplitaxion Inc; I met Jack; and I realized; that I was; dear reader; so very wrong; in my assumptions about people who exist in the software development world.

Jack was not a programmer.

In fact; he had done his major in philosophy.

When I first met Jack; the question that bothered me was simple: how the f@#k did Jack manage to join a software development firm?

In my first few weeks of working with him; I found my answer in the way Jack approached work; people and life. The guy was an interesting storyteller. He was almost a catalyst. To add to that; he was what I then started referring to as a --- 'contributor'.

During the first month of the project; Jack and spent a huge amount of time with me and the five person development team. He would read the requirements end to end and then talk about those requirements; so that we would not have to read them; he had valid questions on the flows we built; he engaged himself in usability testing; he tested the screens that we rolled out and pointed out valid bugs the official testing team was often not able to point out.

Our true surprise however; came when someone from the development team showed Jack how to write Ant scripts and we discovered that he was surprisingly good at it. Within a few days; we also had a build manager; taking up tasks which no developer wanted to take up.

Jack; dear reader;  was not writing a single line of code; but in a matter of three months; he had made himself very difficult to replace.

Steve Yegge brushes against the concept of a contributor in his post on a completely different topic; he explains:

Let's face it: there are a lot of professional programmers out there who realize they're not very good at it, and they still find ways to contribute.

If you're suddenly feeling out of your depth, and everyone appears to be running circles around you, what are your options? Well, you might discover you're good at project management, or people management, or UI design, or technical writing, or system administration, any number of other important things that "programmers" aren't necessarily any good at.

You'll start filling those niches (because there's always more work to do), and as soon as you find something you're good at, you'll probably migrate towards doing it full-time.

If you read between the lines; Steve's post might actually suggest that finding other ways to contribute when you discover that you are not a programmer; is not the best of things. You can actually hear a slight tone of sarcasm between the lines if you were to read them carefully. A few years ago; I would probably have agreed; but my experience with Jack; and a couple of other contributors I worked with after Jack; changed my opinion of this topic all together.

Yes; we don't need millions of non-programming contributors; but till date; I hold the opinion; that if you are a young and budding programmer; struggling with programming; not loving it; but you still feel passionately about being connected to the world of software development; you are much better off trying to morph into a contributor who contributes a host of things towards making the project a success and is a 'fun' guy to have on the project.

We do need a select few genuinely passionate 'contributors' around; much like we need good passionate programmers and at times; if you are genuinely passionate; we might not even care if you can write any code in the first place.

So stop trying to pretend you are the best programmer around; stop trying to climb in pecking order of your organization and desperately get promoted to the position of a manager; stop being a whiner; or a 501 programmer.

Find your niche and start making genuine contributions.

I wish you good luck.

posted on Thursday, 26 November 2009 10:53:03 UTC by Rajiv Popat  #    Comments [0] Trackback
Posted on: Sunday, 22 November 2009 by Rajiv Popat

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.

posted on Sunday, 22 November 2009 20:52:51 UTC by Rajiv Popat  #    Comments [0] Trackback
Posted on: Saturday, 21 November 2009 by Rajiv Popat

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.

posted on Saturday, 21 November 2009 17:57:57 UTC by Rajiv Popat  #    Comments [50] Trackback
Posted on: Thursday, 19 November 2009 by Rajiv Popat

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.

posted on Thursday, 19 November 2009 20:46:01 UTC by Rajiv Popat  #    Comments [2] Trackback
Posted on: Sunday, 15 November 2009 by Rajiv Popat

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.

posted on Sunday, 15 November 2009 21:38:29 UTC by Rajiv Popat  #    Comments [0] Trackback
Posted on: Saturday, 14 November 2009 by Rajiv Popat

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.

posted on Saturday, 14 November 2009 21:12:39 UTC by Rajiv Popat  #    Comments [2] Trackback
Posted on: Thursday, 12 November 2009 by Rajiv Popat

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

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

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

Emails providing details about mundane; irrelevant facts like:

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

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

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

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

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

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

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

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

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

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

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

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

Facing a problem fixing that code you are working on?

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

I wish you good luck.

posted on Thursday, 12 November 2009 23:01:14 UTC by Rajiv Popat  #    Comments [3] Trackback
Posted on: Sunday, 08 November 2009 by Rajiv Popat

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

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

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

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

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

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

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

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

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

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

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

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

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

My Point?

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

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

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

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

I wish you good luck.

posted on Sunday, 08 November 2009 23:53:08 UTC by Rajiv Popat  #    Comments [0] Trackback
Posted on: Saturday, 07 November 2009 by Rajiv Popat

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.

posted on Saturday, 07 November 2009 21:33:11 UTC by Rajiv Popat  #    Comments [0] Trackback
Posted on: Thursday, 05 November 2009 by Rajiv Popat

I write this from the Plush; huge and amazing campus of Infosys Bangalore where TED India 2009 is being hosted.

Before I even start with this post; let it be known that I love TED and have been watching TED videos for three years. Being at a TED is an experience any creative mind should indulge in and I would highly recommend TED to anyone who as I say - aspires to make small or big dents in the universe.

TED India; much like all other TEDs was an amazing experience.

I have been blown away with the hospitality; arrangements and the insightful talks.

But this post isn't about reporting TED events or doing a shameless plug for TED.

This series of posts; dear reader; is about 'entertaining' a few thoughts that whisked through my weirdly-different mind during the last two days spent at TED India. It is also about sharing, raising and discussing a few of my very own personal questions and perspectives that I carry back with me; besides the amazing things that I learnt from TED India speakers, fellows and participants.

May The Best Man Win.

If you happened to be at TED India one of the things that you would have found striking is the amount of conversations and talks around; India, Indian Culture, How India is different from the west, How Indian infrastructure is growing; how corruption in India works; how the Indian poor are being helped by Indian NGO's and how nothing in India is perfect but in spite of that things still 'work'.

The amount of discussions and content around the whole mechanics of how India works; what India is up to and how India is coming up; in TED-India were fascinating; but if I can be brutally honest here; they were also a little overwhelming.

Put simply; by about the evening of second day; as I saw almost every speaker and participant touch the topic of 'India' and how it works; I was starting to miss talks which touch universal problems like happiness; education; drawing inspiration and many more like it in a rather fascinating and engaging way . What was also happening by then; was that a few question were starting to find their way through my mind:

  1. Were the TED India speakers and even we (me included) as TED-India participants spending just way too much time on understanding the differences that are either going to pretty much automatically find a way to co-exist or are going to be wiped off in a matter of few years?
  2. Are we not rapidly moving towards a world where the best of efforts and products cross the dip; stand the test of time and eventually survive; irrespective of the country that they originate from?
  3. Are we not already in a world that is so mind-blowingly fair that just one rule stands - may the best man, woman, organization, thing or effort, win.

No seriously.

Before you knit your brows at the questions; and go on the defensive; consider this:

If you happen to be the best social worker out there; you will figure out a way to help those who most need your help; irrespective of the country that they belong to.

If you are the best architect; you will find a way to build the best of the buildings that people find fascinating.

If you are the best musician; you will find a way to touch people's heart with your music in a way that moves them.

If you are the best software developer; you dear reader; will find ways to build the most remarkable software out there.

So the next time you see me at a cafe; I do not care if it is in India or California; lets get together and talk about insights that makes you the best whatever-it-is-that-you-are. If you are not the best let us exchange ideas, thoughts and experiences about what can; as professionals; make us; the best at whatever-it-is-that-we-do.

Everything else; is just details.

May the best man, woman, organization, idea or product win.

Now; tell me what makes you the best? If you are not there yet; how are you working towards getting there? What have you learnt from your failures so far?

I will take what applies to me. As an educated man I will try my best to filter the inapplicable and entertain your thoughts without accepting them.

I do not care where you are from; where you are located or how amazingly different we are. Seriously.

Go ahead. Start the conversation.

I am listening.

Are you?

posted on Thursday, 05 November 2009 18:56:26 UTC by Rajiv Popat  #    Comments [0] Trackback
Posted on: Sunday, 01 November 2009 by Rajiv Popat

You Might Be A Spammer And You Might Not Even Know It. 

From Saving cost; increasing my IQ; getting a free degree; living a happy life to increasing my man-hood; the number of spam emails that I get on any given day is astonishing.

While I am hard-wired to ignore these emails; there is yet another kind of email that is also technically spam and that I also ignore.

This dear reader; is not the typical malicious spam sent with an intention of spoofing; identity theft or running a Trojan on your machine.

Instead; these email include a real organization and a real marketer trying desperately to market a product that he or she has set out to make you interested in through what I like to call 'brute force marketing'.

Examples include:

  1. Valid and Authentic Placement Agencies checking to see if you have openings in your organization and if you would like to interview their candidates. 
  2. Web conferencing companies trying to show you their solution and help you get; what they call; a higher 'ROI'.
  3. Training organizations wanting to check if you are interested in attending their next paid training session or workshop which will 'boost' your productivity.

Read between the lines and you willl sense both; the mediocrity of the product and the frustration of the person sending the emails.

For months I struggled with why anyone would indulge in the act of spending all this time and effort to spam your mailbox when it is a vastly known fact that we as computer users ignore most of the emails that we get.

For months I wondered how the idea of writing Trojans and spammers worked. Were there organizations that had developed this as a Niche? Were there whiteboard meetings; backlogs and scrums around the features to include in the next version of the cutting-edge-spammer these guys were writing?

No; seriously; this entire 'industry'; for lack of a better word; and its workings; were beyond my comprehension.

It was then that I happened to work with the client where I saw how it all begins.

This client of ours; who for the purposes of this post; we shall refer to as Multiplitaxion Inc; had a marketing department which undertook the task of sending out monthly mail blasts to what they called their 'potential clients'.

To give them credit for ethical conduct; the mail blasts were not malicious though. They contained simple HTML emails with harmless irrelevant stock-pictures of planets like Saturn or smiling people. The idea of these emails was to get the receiver of the email excited about the insurance product this client of mine worked on.

A little more investigation into the process told me how it typically works:

  1. There were people hired (usually outsourced from marketing firms based out of India) to search and collect email addresses on 'potential customers' from the web and multiple other sources.
  2. There were companies which sold database of email addresses. These database were purchased on a regular basis.
  3. People were added to the centralized CRM database without their express permission and is most cases even without their knowledge; albeit they were offered a small 'un-subscribe' link at the bottom of every email that went out to them.

Yes; this client of mine was one-hundred percent ethical; with no malicious intent and yet they had taken their first step to becoming what can otherwise very technically be called a --- 'spammer'.

As a fully ethical organization; which was working on a genuinely good product; why did the marketing teams of Multiplitaxion Inc; feel the need to do this?

My personal theory behind this is simple --- because the math associated with this thing was staggering. It was an expensive insurance product for the enterprise this client of mine owned. The product had just three huge paying clients; which was good enough to sustain the product development team and keep the product running.

On any given month they sent out around five thousand unsolicited emails. Assuming that just 1% of the recipient clicked on the email and then 10% of  that 1% came to their website and spent considerable time there; they would have 5 interested customers that they could track and follow up with.

Now if your marketing could turn just 20% of those into paying customers; you had one new customer - which basically translated to 25% more revenue coming out of the product.

It was huge.

Human beings; are driven by different motivations; and when the motivations are high; people tend  to lean towards what might be wrong without even realizing we are doing so. This is exactly what had happened here. Multiplitaxion Inc; was sending out spam-mails without even realizing it was 'spamming' people.

No-one in the marketing department; development team or the entire organization saw this as spam. Everyone just called it a 'mail-blasts' and we even had calls around how we can improve the email sending job so that we can track the people who were getting these emails and see what they were doing with these emails that we were spending so much time and effort to send.

That is when we started embedding GUIDs and JavaScript in our email to track who was clicking on them; who was deleting the emails without reading them and who was spending time on our website.

We never went beyond this point; but as we sat through some of those meetings; I as a developer; could almost see what the natural next-steps or set of 'features' could be to take our mail-blast program to the next level - introducing a small executable or active-x component (or should we say a Trojan) to see which other insurance products the recipient of the email was running?

I cringed at the very thought of it.

It freaked me out to even think how thin the line is between being a software developer who is building a great product and helping the marketing team get the word out and a spammer who is writing state of art tools for spamming people.

The only good thing; that I can say about that episode is that this client of mine; knew where to draw the line and stop. No-one even thought of or spoke about introducing executables or active-x controls for better tracking visitors.

Of-course; as we sat in that meeting room; none of us; even thought that; just by sending those emails out; we had taken the first step to becoming the spammers we all hated.

Now; pause a moment; dear reader.

Reflect.

Does your organization send out an email blast about any of your product or service?

Harmless HTML emails that go out to a few hundred or thousand readers?

Maybe; and I am just saying maybe; much like those placement agents checking in to see if you have openings; or the training institutes checking in to see if you would like to boost your productivity; your organization might be spamming people too; and you might not even realize it.

Just a little something to think about.

posted on Sunday, 01 November 2009 20:52:58 UTC by Rajiv Popat  #    Comments [0] Trackback