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.
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.
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
6. Konfabulator (used to before yahoo bought it)
7. Dell Updates (Dell’s version of Windows Update Balloon, only bigger and more annoying)
10. iPod Updater Software
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
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.
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
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.
In spirit of PowerPoint, this article consists of some bullet points: