Sunday, December 25, 2005
Monday, December 12, 2005
Jeopardy remained the highlight of this year’s managers meeting. Hold there! It is not the CNSI Jeopardy buzzer contest game that I am talking about, but I am referring to the jeopardy of drinking too much and then falling from dance floor and spending the rest of the trip on two shots per day dosage. I also wish I could refer to the jeopardy of what eCAMS acronym stands for but I would prefer to acquaint you with the perils of gambling and the persistent effort to loose money as if it was being funded by Bank of Jaytee like some of our famous projects are! I wish I could refer to the jeopardy of who is older, Jaytee Kanwal (last clocked at 44++) or Reet Singh (leading with 44+++) but I am talking about the risk of carrying 60 pounds of luggage on a three day cruise and having to move your two-pieces in other people's luggage . Also it is no less of an insurance risk of having 50+ year old people running up and down in 80 F and scorching sun.
Well there was more than the jeopardy game that was played as a team building exercise. We had the beach Olympics which however appeared more of a beer guzzling challenge, scream your way to victory and 'blow it' competition than.. . Anyway, I cannot get away from referencing the fine gentleman who appeared to had spend more time in the gym than .... and could walk away with a job of a life guard or a modeler for special extra short, extra... swim trunks and add to his list of diverse work experiences (Taco bell fryer etc).
At the end, I cannot close this entry of the blog without referring to the "Finds of 2005" for CNSI. First, Bhanu (pronounced Banu), who represents West Virginia equally well as she does Chennai, not only surprised everyone with her drinking capacity but by her ability of being spontaneous, and a playful teaser . I think we can all see a healthy competition developing for a coveted title and position in CNSI upper echelons. Second was CK Kumar ( Head of CNSI India Operations) who amazed not only by his ability to perform a table top dance with a calendar girl but by his ability to constantly stream out with comments and one liners, though they made sense only to him most of the time.
This was the summary highlight of the meeting but more vivid and detailed blogs shall follow and I hope to get some good contribution from my fellow team CNSI members. After all this off site meeting was dedicated to Team Building Right!
Monday, October 24, 2005
In part-I, I wrote about how dialog boxes can make your application look infested with bugs. In order to solve this, as a designer your aim should be to minimize dialog boxes as much as you can and if a dialog box is really a need then think about making it a modeless dialog box.
Let us assume you have a web application where you want to create a web page to display a list of items. Consider its design; you need a list page and an
My suggestion is let’s try to be innovative and let’s design for the user and not for the application.
Now regarding the above dialog issue, we can add input fields, which we were displaying in the dialog, at the top of the list page and provide
Headers--> First Name Last Name Email Address
Inputs--> Field1 Field2 Field3
For editing you can either provider edit image/button in each row or a EDIT HTML link.
In the list above we achieved the same functionality as of a dialog box and much more. Much more? Well using this approach you can easily provide copy row functionality also. Consider the list below; a user can enter values in Field1, Field2 and Field3 for First Name, Last Name and Email Address and press
Hope this helps. I will be back soon with more user interface design issues.
Friday, October 14, 2005
Monday, September 26, 2005
Wednesday, September 21, 2005
In the book 'I AM OK, YOU ARE OK', the author highlights the very fact that every individual makeup is made up of three coexisting layers (adult, parent, child). Believe it or not everyone has that child in him that leads him to enjoy the trivial, live the moment. The very fact that in every conversation that we engage in, there is either the adult or the parent or the child interfacing is intriguing. The appreciation of these subliminal interactions can ensure improved handling of the situation. Anyway, I love the child in me, it gives me the creative spark, fills me with the energy to do things unconditionally and gives the excitement in mundane things. As someone said
"Just Be Yourself, because those who matter, don't mind
And those Who Mind, Don't Matter"
Do you agree? Should I care? :)
Sunday, September 18, 2005
There are so many of these but lets take one at a time and my random pick is dialog box.
There are so many things the way we design our user interfaces, which we can improve on and we should improve on. I have seen some applications, which we use on a daily basis improving on it but some still do it the old way. Most annoying feature of some of these applications is the modal dialog box. So let’s find out what is bad about these dialog boxes.
As we all know dialog boxes are classified as (1) Modal and (2) Modeless. Modal dialog box is that, which require a user to respond to it before doing any other action on the application which produced it. On the other hand a modeless dialog allows a user to perform other actions also, on the same application, while it is active.
Dialog boxes are useful when we need to get some input from a user or if we need to give a response back to a user. Dialog boxes become more helpful when a user is viewing a list of items and he/she wants to add another item. Using dialog box in this case lets user add another item, while viewing the list.
Now the real question, if a dialog box is so useful then what is wrong with it?
Well, out of the two types, modal dialog box is really the most annoying.
Consider “Font” dialog in MS Word. It is modal in nature and when it is active, it won’t allow you to do any other action on the word document you are working on. Consider its use now. This dialog box is used to change the “Font" properties of the selected text. So let’s say you select some text, open this dialog box to change font and then realize that you need to select some more text. The only option you have is to close this dialog and then select more text and then open it again. Now think if this dialog is modeless (just like “Find and Replace” dialog in MS Word), in that case you don’t need to close it to select more text. A small annoying issue is solved. (To our rescue, MS word has a font tool bar also to perform similar action, which most of us use.).
Now can we live without these dialog boxes? I would say minimize dialog boxes in your applications, especially, if it’s a web application. All those pop-up blockers on user’s machine can make your web application look infested with bugs.
There are some other alternative designs to dialog boxes also, and I will try to write something about that in my next blog, till then bye.
Tuesday, August 30, 2005
However, to the credit of the office planners, the project appears to be getting over on time unlike some of our IT projects which every time we look into it, we figure out that we have 6 more months to finish. Am I looking North East? Arghh! Back to the shuffle, oops, I mean the reshuffle.
Space is premium ladies and gentleman and individual offices are what people would fight for as if there was no tomorrow. Cubes are considered a step down. Sending emails, escalating to everyone (can you escalate to everyone, I need to figure that one out yet), making presentations to justify the need for the office are the flavor of the week. Hey come on we have to work in the environment for long extended periods, weekends too. (This project was an exception. No work was done during the weekends even though it meant outages in the regular work days.) So Brethern, all I can say is that the fight is justified! Damn! I have an office too and gosh it feels on top of the world. Close the doors and you are at home. The office planners worked to satisfy all kinds of forces for the office space, brainstormed ideas ( as if there were many) , discussed for long hours in meetings ( actually same thing repeated n times ). But time was spend like crazy ( for there was no other work to be done) and out came the guiding principles. Can those be shared? No, because for they are guiding principles, we are not supposed to follow them, just guide along them to walk into the exception world. Further they are baked fresh every day.
Finally the D day came and phase I of the project got completed on time! Infact ahead of time. Pandemonium!! We were supposed to move on Friday. OK! No! Wait we are supposed to move on Wednesday, since we cut down the networks, telephones from the old to the new already. Yikes!
Anwway, we all welcomed the randomeness since 'In Chaos lies Creativity", and we all eagerly wait for the next phase with great anticipation. So till next time welcome the random order and enjoy the reshuffle across the border !!!
Tuesday, August 02, 2005
The purpose of testing can be to show that the software works or it can be to show that the software does not work or there can be another level where the purpose is not to prove anything but to produce higher quality software. When we say quality, a lot more gets added to the whole process. The testing simply does not become a procedure to find bugs but something where one set of tests try to fail it and another set tries to improve it( increase in usability/"easy to use" is one such improvement).
Black box testing, white box testing, bottom up approach, top down approach etc. has always been there. To my understanding the goal is still the same , making sure (1) what we built is what was expected by the user and (2)Another level, where the software exceeded user's expectations and software is really solving his problem and not creating a new problems of its own kind.
Today morning while driving I heard this analysis on radio about automakers. Their big challenge is that they design their cars based on user requirements or who would be driving the car etc. But the issue is , as they were saying, most of the time a user doesn’t know what he/she wants till they actually see it. This is what happens to us also when our system goes to production. We can always argue use agile/RUP/CMM etc. to avoid this but still we always find this issue.
There is another issue and that is our test cases. Most of the test cases are written either to satisfy the requirement or to satisfy the design. This is not a bad thing (although I have read some articles which say the word “requirement” is bad. Another topic of discussion!).
I would divide testing in to two levels (1) Business Process Testing. (2) Code level testing.
Arvider has already posted his views on "Business Process Testing". But there is another level " Code level testing" where you go down to the code level, making sure you test each method in the code(Method coverage), Making sure each statement gets executed at least once (statement coverage), Branch coverage etc…. This is where GACC, RACC comes in to picture.
Now you can always say that , that would be a lot. Well you do not need to achieve 100% of Test Coverage and also in order to do this you do not need to change what ever you are doing but you need to look at your Test Cases and produce smart test cases. How you produce smart Test Cases? I will try to write something about it soon.
Sunday, July 10, 2005
But anyway, I think one of the fundamental reasons for high customer dissatisfaction with software systems is the lack of coherence with the operational processes. The reason being that the traditional software testing approach is bottom up starting with unit testing and graduating to integration testing and system testing. As a result the software is tested and verified for the way it was built and/or designed to built.Howevever when put to use, there are signficant operational gaps which make the system of little use and reduces its acceptance by the end user community. This has to change!! The wave is of business processes driven application and system design and testing needs to take on this paradigm shift heads on. This paradigm shift can be absorbed and addressed by imbibing and adopting the BPET philosophy!
First of all this philisophy is geared towards testing the software the way it is going to be used. How? You guessed it by mimicing business processes. So this approach starts with understanding the key business processes that support the organization and map them to the system identifying the ownership and roles of the system and its various components that support it. The rest of the plan is to define and develop test cases that verify these processes execution and the success and failure of the system to support the actions.
But two fundemental changes do exist with the traditional approach to testing. One is that the actors in this case (testers) are not traditional software testers but subject matter experts, operational staff who understand the business and have significant domain knowledge. The second but higly controversial, I assume since it causes radical mindset change is the defect priortization in this philosophy. A bug that crashes the application shall get a medium rating if it has minor operational risk.The situation that resulted in a bug is an exception and it is unlikely to occur or there is a reasonable workaround or avoidance strategy. At the same time a result that is not even technically an error – say, a degradation in performance during regular hours may be a showstopper since it means lack of customer response by customer help desk which means the 1000 calls being addressed every hour are not getting addressed. I think this is paradigm shift for both the business stakeholders and the software developers but it is the right way to execute the test strategy. After all it doesn’t matter whether the software is perfect or not as long as it meets the business process needs. BPET is the new mantra Amen!!!
I shall be further elaborating this area in my future blog updates!!!
Monday, July 04, 2005
The Genius Factory: The Curious History of the Nobel Prize Sperm Bank
Well, Twenty fours ago, millionaire Robert K. Graham began a most remarkable project: the Repository for Germinal Choice, a sperm bank for Nobel Prize winners. I guess more driven by the need to help preserve the genetic geniuses in the next generation than altruism or social engineering. This was to help reverse the genetic decay Graham saw all around him by preserving and multiplying the best genes of his generation. By the time Graham's repository closed in 1999, his genius sperm had been responsible for more than 200 children.
Want to know who these 200 children are? What are they doing? Interesting!!! Think about it ...
Here we are on the verge of what are called designer babies with modified genes this story puts insight into what happened when using Genetic Engineering 101 :"Using the most advanced technology of the time a sperm bank with top minds"