I have a beef to pick with United and their kiosk check-in development team. For some reason, they have decided that international travelers must scan their passport before allowing to proceed to check in.

A typical transaction goes something like this:

“Please swipe your credit card.”

I swipe my credit card.

“Please choose your language.”

I pick English.

“Please scan your passport.”

Ok great, there is no clue to where the scanner is. Of course its not on the kiosk itself. Its tucked away on the side.

After searching for a few minutes I find it. I put my passport face down and press down. Ok pretty clever to use a press down technique to start a scan, I admit.

I already know my passport will not scan. It is simply not built to be scanned.

The next screen drives me crazy. Either United does not have good interaction designers on board or maybe does not even have them, but their kiosk developers are breaking every rule of good usability.

Once my passport fails to be scanned by the machine, it brings me back to the same screen over and over again.

“Passport could not be scanned. If you would like to try again, press continue and scan again”.

I would expect to see at least one other recourse than the small exit button on the top right corner.

You know the first question the agent asks when directing you to the kiosk? “Do you have a scannable passport?” If only, the kiosk started off like with the same question!

Aaah. Programmers !! Think of alternative situations.

This entry was written by Amit, posted on March 23, 2006 at 12:06 am, filed under Uncategorized. Leave a comment or view the discussion at the permalink.

Following the extreme programming principles, our project holds the daily standup meetings. I have been part of many agile projects, and in some shape or form we hold a daily meeting, where every member gets a chance to appraise the team of where things stand. Seems like a good idea, right? However, somehow I have always had an uneasy feeling about these meetings.

Some people tend to hog these meetings. They start off on a topic that might be relevant or not so relevant, but they hog the time, while rest of the team sits around waiting for this person to finish the never ending rant.

Sometimes the moderator will cut the person off and remind him or her to take it “offline”. In my experience, half of the time, these “offline” meetings never happen. The person is too pissed off that his or her point is not being given the merit it deserves or they run out of steam laboring over a point once and do not care to belabor over it again.

So the meeting chugs along. Who is benefiting from these updates?

If the team is co-located, there is a lot redundancy in these meetings. If the team is not co-located there may be lot of surprises in these meeting with very little time to react or mull over the new information.

Some managers like to use these daily meeting to set the agenda for the day. Seems weird to me. We may call the location “war room”, however, lets face it, it is far from being a battle zone. A battlefield is fluid and constantly shifting, a week long programming assignment is usually far less dramatic.

Christopher Hawkins wrote an excellent piece on rules governing meetings. I particularily like his point of no new information being presented in the meeting. Why are meetings used to present new information. There is not enough time to get meaningful response from every participant on the information.

I have not been in a single meeting where I have not noticed atleast one participant getting bored, distracted or just tuning out. Sometimes people are bold enough to leave the meeting that is not useful to them.

We need a better way to communicate whats going on without a stand up. By the way, no one stands in these meeting. Everyone is really comfortable in their chairs. Standing up seems quite childish and who will enforce such a rule among adults?

It seems simple to me. People who are working together on related things should not have to gather round in standup meeting to figure out what’s going on. If its only for the benefit of management that standup meetings take place, I say don’t wait till next standup to nix them.

As a manager, I need to have my hand on the pulse of the team without the need for a daily brief or update. Now if I was the president and I simply have too much to handle, yes, please provide me with a daily brief.

Meetings are not a necessary evil. They are just evil.

This entry was written by Amit, posted on March 22, 2006 at 11:45 pm, filed under Uncategorized. Leave a comment or view the discussion at the permalink.

Bug tracking software have to do a few things good:

Step 2. Make it easy to enter a bug

Easy, right? Lets think about the process of entering bugs. What information do you want to enter to make a good bug description, now that you have managed to crash the program or discovered where the program sucks. You could choose from a plethora of information.

Error information

Screenshots
( I have not seen a single program which lets you capture this information within the bug tracking software, except as attachments. Attachments do not tell the story in a sequence.)

Logs
(same as above. The bug tracking software makes no effort to learn about the crashed program. Chances are if someone already has entered a bug for the software, the bug tracking software can learn where to look for logs, what logs are important and what else the program can attach “just in case”)

That sequence of whacky actions you did that managed to crash the program.

Step 1. Search previous bugs information.

I purposely put Step 2 before Step 1. Most of the times you run into a bug, you don’t immediately get the feeling that hey someone before already ran into this problem and maybe I should search our greate bug tracking software to make sure it not already in there. Once you collect some information on the bug, it might cross your mind to search for previous such bugs.

Now folks, most programs suck here. Can’t search text let alone search attachments, or any other field that might make sense. Forget any intelligent matching of language. After all, people write differently.

Some bug tracking software that reside in my mind’s hall of shame (these are just the one’s that I have used):

1. Mercury Quality Center
2. Any Siebel based Bug tracker
3. Compuware TrackRecord

Feel free to enlighten me to the world of better software management.

This entry was written by Amit, posted on January 18, 2006 at 11:16 pm, filed under Uncategorized. Leave a comment or view the discussion at the permalink.

Yes I mean it. Put your developers in the Quality Assurance role. Atleast once in their lifetime every developer should spend time exclusively in the Quality Assurance role. You know what happens? Your regular QA folks get better at figuring out problems due to the close interaction. The developer’s attitude get better towards the frustrations QA guys feel when dealing with bugs that keep reappearing or annoyances built into the software. Result? The developer’s code gets better.

Your developers may kick and scream. The good ones are going to make use of the opportunity and make the code better. They are going to make the quality assurance team better.

Don’t think about it. Just try it.

This entry was written by Amit, posted on at 11:11 pm, filed under Uncategorized. Leave a comment or view the discussion at the permalink.

I enjoy wandering into conference rooms. Because in conference rooms, people leave stuff on the whiteboard. Ideas, thoughts, discussions are often not erased at the end of the session.

This habit makes interesting reading for the post discussion observer. Especially if the discussion involved top management. Now that’s a sure way to feed the grapevine. If you want to start a rumor, get some executives in a conference room, scribble on the whiteboard and leave it there for all wanderers to read.

“Year end target: Reduce existing staff by 30% and add 50% staff offshore”(an actual line on a whiteboard somewhere). Just imagine leaving such an incendiary line on the whiteboard. Sit back and watch the morale plummet or even worse, watch some people leave in a what they think is a preemptive move. In the end, there was no such move by the organization.

Here is another quote I picked up recently from a left over whiteboard, “Crack the whip”. Ostensibly, it was listed a strategy to avoid failure. Frankly, it conjured images of a World War II Japanese prison officer intent on making the allies prisoners of war completing the bridge over river Kwaii.

What are the software developers to make of such a strategy?

I think people write on the whiteboard due to a few different motivations. The obvious one is that they are thinking as they are writing in a discussion. Ideas are flowing, different people are speaking and someone must consolidate these points on the board.

When there is primarily one dominant person in the discussion, it is usually to enunciate, display the thoughts, and underscore the spoken word.

In any case, all useful whiteboard scribble needs to be transferred to the computer or a notified or I threaten to make a collection of them and publish a book filled with leftover whiteboard scribble.

This entry was written by Amit, posted on December 29, 2005 at 1:58 pm, filed under Uncategorized. Leave a comment or view the discussion at the permalink.

What is the average time software teams last without an existing member leaving or a new one being added?
What is the average percentage of teams remaining same from start to end in a given project. I will be very surprised if the number is in double digits.

Which brings me to the next question. How long does it take for a new member to come up to speed in a team. Adding people to a late project only makes it later as we are told again and again. If adding new people to a team is the reality that we must face, why is there no focus on techniques to make newer people in the team productive faster ?

Having documentation is better than not having it, however, it is not the sole panacea of reducing new member ramp up times.

The problem is two fold. The new member is trying his/her best to come up to speed. This introduces friction for the rest of the team members and slow them down. If the new member is not asking questions, he/she is not learning. This scenario is inversely proportional to the team moving forward.

So careful project managers will add team members with the knowledge that overall productivity will suffer. They are aware of the productivity loss and are hoping for long term productivity gain at the expense of the schedule.
Recently I joined a team in the middle of the project. The project was on full throttle, and the week I joined, most team members were busy fighting fires. As I shunted from meeting to meeting, I kept thinking how I could be productive . Getting off the ground seemed lofty. Acronyms kept flying. I was struggling to keep up. I thought about making a list of every acronym and abbreviation heard in the meetings and then prodding someone after the meeting to learn about each and every one of them. Somehow, I just couldn’t. It seemed like not the best place to start.

So I wanted to make a list of things a team can do to make the transition for a new member a healthy and fun experience.

Here is that partial list of things that help ease the transition:

• Diagrams – Much better when combined with brief text. This might include high level architecture, requirements, and designs.
• Deployment topology – New members will not automatically know where to go looking for things. Give them server names, user its, passwords etc.
• Methodology overview – Ask the new member about their experience and give them an overview of the methodology in use in the current project.
• Key contact list – Tell the new member who the key contacts are in the different areas. The go to people in each area.
• Admin issues – Get them out of the way. Make the new member feel at home. Tell them how to get around, what admin issues they need to be aware of. Time sheets, status reports and any relevant access issues.
• Software Tools in use – Have a handy list of software tools and packages in use. Give it to the new member. Ask them to get themselves familiar with the tools in use if they already aren’t versed in them.
• New Member Experiences – Make each new member write down their experience in terms of what was missing or what took them the longest to grasp and how did they do it ultimately. This will be invaluable for future members.
• Required Reading List – Each project must have a required reading list. A project without mandatory reading list simply means that there has not been enough thought put into research. Keep a required reading list and update it frequently.

This entry was written by Amit, posted on at 1:54 pm, filed under Uncategorized. Leave a comment or view the discussion at the permalink.

Onsite Designer: I think we have Class A, B and C with so and so relationships and methods. This is what they should do. Ok great, I have a design I will send it to you offshore folks and you can code it up.

Offshore Programmer: Ok. Sure. It sounds great.

And so ends the design briefing conversation. Team of offshore developers receive the design and start implementing it. Halfway through coding, a design anamoly pops up. Offshore developer A discusses it with offshore developer B. “How is this going to work? I don’t understand why the design has so and so relationship laid out. This doesn’t look like its going to work.”

Its 10 AM in Shanghai(or Bangalore, or Moscow).

Offshore developers continue their discussions and come to a possible work-around. What do they do now?

1. Send out an email to the onsite designer explaining everything and do nothing further for the day.
2. Wake up the designer this very moment and have a telephone discussion.
3. Make the proposed change, send out an email explaining the rationale and keep working through the code.
4. Code up the design as stated with the obvious bug in it.

Here is what typically might happen, depending on the type of offshore organization:

1. Send out an email to the onsite designer explaining everything and do nothing further for the day: An outsourced project to a CMM level x company. Developers do nothing till they have all the changes outlined and documented on a few dead trees.

2. Wake up the designer this very moment and have a telephone discussion: This scenario will not happen. Ok, will happen very rarely. Offshore programmers do not call their counterparts at home. Even if the outsourced company has onsite people who maybe called, they will not call the clients at home either.

3. Make the proposed change, send out an email explaining the rationale and keep working through the code: Offshore branch of the parent company. Everyone belongs to the same organization with offshore developers having some flexibility in terms of what changes they can make. This is bound to piss-off the onsite designer, who will try hard to protect his/her turf. Ok maybe its an organization with peace loving people, who are working together to build a great product. Still, the very notion of separation of design versus coding activities will be a constant source of conflict.

4. Code up the design as stated with the obvious bug in it: An outsourced project being done by a team of relatively inexperienced team who are developing in a culture that does not foster taking initiatives. They do what they are told. Period.

This entry was written by Amit, posted on October 28, 2005 at 12:15 pm, filed under Uncategorized. Leave a comment or view the discussion at the permalink.

I recently read Robert Glass’s post on design as cognitive process. It got me thinking about how I do design in my head. I must clarify that by the term design I mean a small design and not the BDUF.

In his article, Robert mentions four basic steps that form the essence of design. I will try to relate those four steps as they relate to my process of design.

Step 1: Constructing a mental model of the proposed solution.

The design palette in my head is certainly not a whiteboard. However, I do use the physical whiteboard a lot( or a design card or simply a scrap paper) to sketch out initial ideas. This is most common when I do not know a prior solution to the problem at hand. There is not much “whiteboarding” going on inside the brain. Robert Glass refers to a “mental model” of the problem. For me, this is outside visible on a whiteboard or paper.

Step 2: Mental execution of the model

Now comes the meaty part. This is the stage I call thinking in code. The brain projects a text editor up onto its projection surface. I imagine pieces of code ( usually in some neutral C like syntax) written up in the text editor. Immediately the questions start flying inside my head. At this point, the diagram that I drew up, is mentally subjected to validation. The design could either prove viable or can crumble after this exercise.

In other words, my brain is not running an animation of a diagram with messages flowing back and forth between boxes. I am actually writing code in my head, imagining interfaces, thinking of exception scenarios, trying to come up with gotchas.

During this cognitive process, I am constantly aware that I could be missing or overlooking some important detail and the levies of the design are going to be broken by the tiny streaming details.

Step 3: Find the problem areas and enhance the mental model

At this stage, I go back to the whiteboard and try to repeat the step 1 and 2 in order to fix the problem areas. However, often I find myself going to step 4 soon after step 3.

Step 4: Evolve to a team model

In a team setting, this would be followed by a design discussion with the peers, where inevitably the team will manage to poke holes in the proposed solution. At this point, the design in hand could be kept aside to look for alternative ideas.

This entry was written by Amit, posted on October 21, 2005 at 11:48 am, filed under Uncategorized. Leave a comment or view the discussion at the permalink.

Broken Perspective 

This entry was written by Amit, posted on October 19, 2005 at 1:36 pm, filed under Uncategorized. Leave a comment or view the discussion at the permalink.

I like the concept of automatically updating software applications. However, they way it is done in most applications annoys me.

Case in point, Adobe Acrobat Reader. I click on a PDF file and up comes Acrobat. Somehow while its getting ready to perform its “acrobatics” it deems it necessary to see if my software is up to date. All of a sudden, it becomes very important for me to pay attention to the latest available updates and patches. Never mind the document I was so eager to read.

Alan Cooper said each dialog box is a room and there should a good reason to take the user away to a different room.

So I was on my way to a room to read a document but suddenly this friend of mine, acrobat, pulled me away, hurried me into this other room and started showing me all this cool stuff that he thinks I should download right now.

Ok, not interested right now? No problems. ‘Cancel’ and it will let me go where I was going originally.

Until the next time I want to read a PDF document.

Moral of the story: Checking for updates may be fine upon launching the software, however, confronting the user upon launch is certainly rude.

There are times when the software “punishes” the user by not allowing them to proceed unless they update the software right away. Users of MSN or Yahoo Messengers have experienced this on more than one occasion.

Its like going to a party and being greeted at the door with “we cannot allow you to proceed unless you go home and change your clothes. What you have on does not work anymore.”

Wow! What happened here? No one had even forewarned me this was coming. I cannot play unless I “upgrade”. Never mind, what I set out to do originally, it is not important right now.

Hey Mr. developer, how about letting me know in advance a day or two? Also why not upgrade me when I am shutting down, preferrably in silent mode. I don’t like the sentry at the gate asking me to upgrade.

If there is a critical bug that inadvertently slipped into the program and I must upgrade in order to protect myself from the all things evil, then prehaps I would not mind if you upgraded me, without presenting me with an elaborate Yes, No, Cancel choice and Then told me about it later in an unobtrusive manner.

You can even ink this understanding between us, in writing in that beautiful piece of “agreement” that I accepted before you let me install your application.

Here is a partial list of software programs I know that offend with automatic upgrade suggestions and occasional forced commands:

1. Adobe Acrobat Reader
2. MSN Messenger
3. Yahoo Messenger
4. Azureus BitTorrent client
5. Winamp
6. Konfabulator (used to before yahoo bought it)
7. Dell Updates (Dell’s version of Windows Update Balloon, only bigger and more annoying)
8. iTunes
9. QuickTime
10. iPod Updater Software
11. RealPlayer
12. Norton AntiVirus
13. McAfee AntiVirus

And here is a partial list of software that do not have sentries guarding their launch(I am not saying their mechanism is ideal)

1. Mozilla Firefox
2. Grisoft AVG AntiVirus
3. Windows Media Player
4. Microsoft Windows
5. Any Microsoft Office product
6. Calculator

In the same vein, there are some who would argue, that automatic updates without users explicit permission upon launch are purely evil and big-brotherly (see The Risk of Programs that Update Automatically).

If a software company wants to steal information from you, it is likely that by you simply choosing to acknowledge an update is not going to prevent this.

So it seems that we need a better way to be able to update installed software, make it less obtrusive, keeping users informed of exactly what is being updated here and why it became necessary.

This entry was written by Amit, posted on at 11:14 am, filed under Uncategorized. Leave a comment or view the discussion at the permalink.