Put your developers in the QA role

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 January 18, 2006 at 11:11 pm, filed under Uncategorized. Leave a comment or view the discussion at the permalink.

Crack the whip

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.

Non stable software teams and ramp up times

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.

Design to Code Disconnect

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.

Design as a Cognitive Process – Diagrams and Code

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.

Upgrading software without annoying users

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.

Java Mask (Nothing to do with Sun) 

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

The world is not enough.

For weeks I have been trying to write an article on a new software process. I think I will just save myself some trouble. The world does not need another software process. However, it could use some new ideas and fresh thoughts.

My basic idea stems from the dismal amount of actual user input used to improve the product in software development in general. The problem is simple, most software developers do not see their product in action enough.

Bottom line: the improvements doled out in general are dismal. This is true for any product. I for one, very rarely will buy version 1.0 of a product. It scares me. I refuse to be the guinea pig, since I know my experiences do not count in the big picture. Unless I plan to start a revolution against the product, no one is listening.

Back in the software company, group of managers, marketing experts and developers are huddled together trying to figure out what to do next. Maybe they even have some user representative (most likely someone on company’s payroll). But you know what, I am not there.

Neither are other hapless users like me.

The developers have no idea what I am going through. We are just not building software like that.

Lets take the example of the telephone. Decades of development must have gone into perfecting the instrument. How many people can transfer a call successfully upon first using a new instrument? I rest my case.

How do we fight back? Simply refusing to accept that our voice will not be heard.

Typically as a user, when I complain, I am not talking to the actual developer. I am talking to a customer support person. This person is probably as ignored in the organization as I am. Moreover, this person is dealing with a SEP (Someone else’s problem). Plus I am probably angry or frustrated(which is why I bothered to call). Now he has a vested interest in helping me, however, he is approaching this from point of view of solving a problem, getting through the call satisfactorily. That’s all.

For software producers, aiming to exceed customer expectations, is not a worthy goal, since via decades of software torture, we have set the bar really low.

For more amusing reading, please visit http://discuss.joelonsoftware.com/default.asp?joel.3.229139.16

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

How would you improve iPod’s interface?

Needless to say, I think iPod’s navigation system and user interface needs improvement. Don’t agree with me?

The entire navigation system is based on IDE tags. Why such heavy reliance on IDE tags? I haven’t figured out the answer. I can only guess: iTunes relys heavily on IDE tags as well.

Which brings up next question: Why are we forced to use iTunes? My guess at the answer: so we would be more likely to buy music from iTunes store.

So ideally for Apple, every iPod user would conform to their vision of the world of digital music: Buy your songs at iTunes Store, put them into your iPod and viola! life is great.

Well not so much. I already happened to own most of the music I want on my iPod, and most of it does not have IDE tags, because maybe CDDB never heard of a CD called “Flavors of India”, but I would still like to be able to listen to the songs in and be able to find them easily without having to go through and tag each song.

Genre must be the most useless piece of IDE tagging. I have not seen much agreement on what “genre” particular music belongs to. Hence, to me the concept of intelligent genre based playlists is pretty useless. Instead, I would like to create playlists based on artists, albums and at the same time take items off the playlist, all this without having to connect my iPod the computer.

Would it be that hard to provide an alternative means to browse music in iTunes and iPod such as simple directory based browsing with the ability to create new folders.

Of course a way to search for a song or artist would be great as well instead of relying just on the scroll wheel. People seem to be getting on fine using tiny phone keyboards for sending SMS, i am sure something better is achievable for the iPod for text input.

How about a real equalizer instead of forced presets only?

Its difficult to create multiple playlists dynamically while playing ( a problem not unique to iPod). If I download a new album to my iPod and while listening to it, I wish to add a song from the current album to my “Work out” playlist, I should be able to do so without a visit to my computer.

Why on earth will my iPod not let me “delete” songs? Were the designers just worried that my iPod was destined to be passed around among lots of hands and one of them could “accidentally” delete my song? iTunes does not prevent this, why does iPod?

Why not let me enqueue songs as I try to fend multiple requests from friends one after another? And if crossfades the queued songs, that would make it really rock.

Lastly, I would like to be able to manually switch off the backlight once its on.

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