Monday, February 19, 2007
Race for 2008 Presidency: Spanish Language, does anyone Care?
PS. I am not a Spanish so it is not a personal agenda of mine.
Sunday, February 18, 2007
Dump the Golden Rule: " Treat people the way you want to be treated"
Wednesday, February 14, 2007
Winter Storm and Remote Working
Saturday, February 10, 2007
Synopsis of a MMIS RFP
Please design and build me a MMIS system. I am not quite sure what I need, so let’s get started. My system should be aligned with all the MITA business processes even though I am not sure of what they are?. Just make sure the designs are such that the MITA processes can be easily adopted as they mature in their details. When you bring the blueprints to me, I’ll make the final decision about what I want. Also, bring me the cost breakdowns for each configuration so I can arbitrarily pick one at a later time.
The requirements go on..
As you design, also keep in mind that I want to keep yearly maintenance costs as low as possible. This should mean the incorporation of automated workflow like single click magic buttons and autonomic computing using industry intelligence standards (If you choose not to use industry artificial intelligence standards and products, be prepared to explain you decision). Please take care that modern design practices and the latest techniques are used in development of the system, as I want it to be a showplace for the most up-to-date ideas and methods. To assure that you are building the correct system for our entire state, you will need to contact each of our sister agencies and their managers and team leads. My sister agency X has very strong feelings about how the system should be designed, since the agency uses the system once every year for some strange reasons. Make sure you weigh all these options carefully and make recommendations. However, I retain the right to overrule any recommendation you make. Please don’t bother me with small details right now. Your job is to develop the overall plans for the system and get the big picture.
Also, do not worry at this time about time and the resources to build the system itself. Your first priority is to develop detailed plans and specifications. Once I approve these plans, however, I would expect the system to be up and running within 18 months.
And to top it all...
You must be thrilled to be working on such an interesting project! To be able to use the latest techniques and technologies and to be given such freedom in your designs is something that can’t happen very often and its great for your company's future market.
Does that sound familiar to your State MMIS RFP and requirements or a similar state IT project....
Note: Any references are purely coincidental and any resemblance purely unintentional.
Corporate Stress and the Certified Asshole Test!!!
Close on the heels to further force the issue on the control phobia and its associated corporate management perils I need to mention the recent book title 'The No Asshole Rule' by Bob-Sutton. I took a small test (ARSE) and came out close to a certified 'asshole'. For example if you answer this question 'True' then you are pretty much certified : Do You feel surrounded by incompetent idiots – and you can’t help letting them know the truth every now and then? ....
Anyway, I hope we become more sane and respectful of our human surroundings. It's a slow transition for me and I do take two steps forward and one back but I guess I am getting there!!! Where do you Stand?
Friday, January 26, 2007
Experience vs Youth
Sunday, January 21, 2007
Super Bowl: Colts Vs. Chicago Bears.. Finally Happened....
Not that I am a fan of Mannings but I definitely align with Tony Dungy personality. His calm demenaor and maturity is admirable and the victory well deserved. The Super Bowl is more interesting with two black coaches going head to head for the first time. Both of them are also close friends. Anyway, it would be something to watch two weeks from now. Also more because there would not be any Patriots!!!
Sunday, January 14, 2007
Is your company the best Company to Work For?
Saturday, November 25, 2006
The Fanatic Pace of Web Exchange
Saturday, October 14, 2006
Winning the FCW Rising Star Award
Sunday, August 20, 2006
Simplicity and Demystifying Technology
What do you think?
Monday, April 17, 2006
Maine's Medicaid Mistakes : A Balanced Perspective
We need to all recognize that the Medicaid market is dominated by a set of vendors who have exploited the states by repackaging 20 years old solution for 35-75 million dollars and yet have failed in some of those implementations. State of Maine acted as pioneers and did suffer as pioneers and early adopters typically do but at the same time need to be credited for giving the industry a new technology paradigm. Even the existing giants recognize this paradigm shift and in-fact one of these vendors is engaged with a State to implement a similar technology platform solution.
Sunday, March 26, 2006
Agile / Traditional approach- Why not hybrid?
Well, why not use hybrid of Agile and Water fall approach.
Tie your deliverables as required by your customers to water fall steps. Let’s look at the following steps
Requirements Gathering
Designing
Coding
Testing
Go ahead and create requirements and design document and submit it to your customer for sign off.
Take your coding and testing steps and see if you can use some of part of Agile methodology in these steps. Try doing following in 2-4 week iterations:
Create stories from your requirements document
Assign points to your stories
Prioritize your stories
Develop and unit test your stories
Perform automated acceptance tests and deploy
Deploying every 2 week gives your Business Analysts a chance to validate and verify your software. Any resulting issues can be fixed early and will be less expensive to fix. Deploying every 2-week gives your team a short goal which your team can try to achieve and once the team’s goal is achieved, the team will get a sense of achievement and hence this will boost team’s moral. The team will get confident each time an iteration is successful. Not only that, by deploying every 2 week you can measure the development velocity of your team and hence will have more insight in to when the whole software can be delivered. You can take necessary steps if you feel that by this development velocity delivery of the software will be delayed.
Another thing which I want to highlight here is that Agile is less document oriented. No big requirements document, no big design documents, just enough documentation which you feel is necessary. For example, some times we create very detailed design documents explaining how the screens will look, which database tables will be used, what will be the pseudo code , what will be the sql query etc.
Instead of going in so much detail why not a screen design and few words about its functionality. In fact I would prefer to draw the screens with my hand and update the screen when the developer has developed it. Believe me you would save a lot of time and probably be able to code your screen in the time you will be writing your detailed design document. Another reason not to write design documents in so much detail is that no one can be 100% sure about the sql, the database tables and code logic and no one can guarantee that these won’t change. We must welcome change and if we don’t we will fall in our own trap where in the end we will realize that we are running out of time and then these very detailed design documents are left untouched and now suddenly your code and the supportive documents are not in sync. Otherwise also if we know the things will change then why write it. Let coding take its own course, let the development happen with bare minimum documents and in the end produce your documents from your code / software and not the other way around.
All of you who have looked in to RUP and if ever tried to produce those documents will probably realize the pain of doing so much documentation. Sometimes we forget our main goal. Our main goal is to produce working software and not lot of unnecessary documentation just to comply with a methodology. If just by writing few words can convey a software function then please do not write hundreds of lines just to convey the same function in detail. I have seen low level design documents with various sections inside those (For example, Screen Design, Description, Constraints , Database tables, Sql queries, interacting units.) Lets make it simple a screen design ( hand crafted) and just enough detail about its functionality.
Another thing if your customer is not requiring you to submit these low level documents then why make these so much great.
My suggestion lets make our life simple by making things simple, by reducing variables, by not over engineering anything , by being open minded and by welcoming the change. Let’s not make a methodology our religion (be it RUP or Agile or any other) and then keep believe in it for the rest of our life.
Agile or Some other Methodology. Are we still thinking?
I find at least two reasons as to why its difficult in moving from traditional water fall / other approaches to Agile (1) our customers are unaware of how agile can help them build something they actually want.
(2) Some of us have made traditional software development approach as our software development religion. We feel threatened by the fact that what ever we have learned in our schools and during our past experiences of developing software applications using traditional approach is suddenly not the right approach.
In traditional approach the design won’t start till the requirements is finished. Coding won’t start till design is finished and the testing won’t start till you are done coding. The reason which was given was that you must gather all and correct requirements before you design because if a requirement is wrong then everything from design to test is essentially a waste. I guess in doing that we missed one major thing and that is human factor. First of all we should stop the over use of the word “Requirement”, and try to find out what are the preferences of our customers. Preferences change more frequently than requirements. (An ideal software solution would be one where there are no requirements but only preferences.)
Let me ask you this, if you plan to build a custom home for your self, can you write each and every detail of your house in a piece of paper, give it to builder and then come back when the house is completely build. Do you think that whatever you were imagining while writing your so called requirements is exactly what you got? You might be getting something close to what you were thinking but not exactly what you want and sometimes it could be totally different then what you have thought. That’s where the difference lies; there is a difference between what you think you want and what you actually want.
Now instead of building the whole house and then showing it to you, if the builder shows you every week or so what he has build so far and what he will be building in next week and each time asks you if you are satisfied? Now let’s say you are not satisfied with what ever was built last week or so and you want the builder to redo or change something. If the change is simple builder would probably do it for free. But lets say doing that change would cost some extra $ . Now you will have three choices (1) Not to do the change (2) Pay extra $ (3) Trade in some other feature of your house. (E.g. may be not to build the deck and instead do the change which is more important to you). The outcome would be totally different if the builder used this approach. At least there won’t be any surprises when the builder finally delivers you the house. Similarly if there are no surprises when the software is put to production then you have a satisfied customer and hence a successful project.
Water fall or other approaches works fine if there is no change in the requirements. No change means you were able to document exactly whatever your customer was thinking (not saying) when you were documenting the requirement. Another issue is that sometimes we don’t know exactly what we want until we see it. Take the example of buying a car. How do you decide that you need a particular car? Well, simply put, you will actually look at a car and if you like it, you will go ahead verify other specifications and buy it. You requirement is that you need a car but which particular car buy is your preference.
We all have seen that most of the time when software is delivered it does not meet our customer’s needs and preferences and then we start blaming our poor requirements gathering, wrong software design and may be bad technology selection. But I guess the blame goes to the fact that we were not ready to accept that fact that requirements could be poorly documented. Human beings to some extent are afraid of change, simply because changes are unpredictable and so we do not welcome changes easily. I guess time has come to solve this software problem and instead of resisting change why not welcome it.
Traditional approach resists change but Agile welcomes change. Agile software development methodology eliminates element of surprise by releasing software in short iteration (2-4 weeks). In each iteration you plan, design, code, test and then release your software. Every 2 week your customers get a chance to look at your software. With each iteration, they will have more insight in to what they will be getting in the end. They are welcome to change their preferences and even after 2-week, if what ever you have developed, is a waste then let it be. It’s far better and more productive than keep working on developing software for a year and then realize that more than 50% of the software is waste. At least we all know that changes done in early stages of software development are less costly compared to changes done in later stages of software development.
In the end I would say that I am not sure whether Agile will work for real-time and satellite/rocket software’s where whole system must be designed and tested before it can be put to use but I assure this approach works for rest of the application software.
Tuesday, January 24, 2006
World Economic Forum 2006
Sunday, December 25, 2005
Yet Another Reason to be in Augusta, Maine
Monday, December 12, 2005
CNSI Annual OffSite Meeting Year 2005: Team Building ... Jeopardy
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
Dialog Box, a bad user interface design element-Part 2( Alternative to a dialog)
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
List-->
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.