Saturday, November 25, 2006

The Fanatic Pace of Web Exchange

When I wrote my first blog almost 2 years ago, I was seeing myself as one of the early adopters of upcoming web tools and stuff. I was definitely not religious in continuouly writing about topics though many crossed my minds but today, when I look back at the nature of web information publishing, the scale of blogging, multi media publishing like mytube, etc, it is mind boggling. Also, all of this is being accepted with open arms by the new generation. Aagh., I am no longer the latest generation. Yes, I am 33 years old and trying to run at a break neck speed to catch these phenoms but definitely loosing inch every week if not every day. Its true there shall be tools and technologies that would eventually fade out of masses and remain prevalent in their loyal followers but it must be said, that the world of web continues to expand exponentially. There would be lot of people that this is not true collaboration but it is definitely the mixing bowl of ideas and at the intersection of all these varied ideas/schools of thought/streams of knowledge lies the next innovation. Do surf and explore these blogs, etc and not only look for that great idea but see if you can create something out of the fusion of these. So happy surfing,blogging and web collaboration

Saturday, October 14, 2006

Winning the FCW Rising Star Award

I was recently recognized by the Federal Computer Week with the rising star award. The award was a recognition to my contribution to the design of the next generation Medicaid Management Information System. Even though I feel proud of the fact that this endeavor resulted in a fundamental shift in architecture of solutions offered by the industry, there is yet that need to execute these hugely critical systems more efficiently and effectively. The implementations continue to be held captive to misaligned incentives between the State Goverment and the Vendor. I think we ( my organization CNSI) continue to make small but yet inherently strategic shifts in making implementation less rough and turbulent. At the same time we need to learn not only from other software implementations in different line of business (which are more fluid and dynamic in nature such as ERP implemenations in supply chain) but look for true cross pollination of ideas by exploring totally different industry lines such as ship building and /or home building. The exploration continues....

Sunday, August 20, 2006

Simplicity and Demystifying Technology

I was not only amazed at discovering the simple but uniquely powerful concept of Barefoot College. It is a college and a social research center in one of the poorest villages Tilonia, Rajasthan India. The endeavor started almost 30 years ago; creates self sufficiency among the rural folks; where villagers with primary education are working with computers, maintaining solar panels etc This is truly achieving simplicity; demystifying technology. Even though, I was proud of this fact but at the same time it created a deep sense of hollowness in me and my work. Is my work really valuable? Am I paying my dues to the society? Even though, my work may not value up to the mark of social contribution I would ensure I do a tad bit to contribute back to this society.
What do you think?

Monday, April 17, 2006

Maine's Medicaid Mistakes : A Balanced Perspective

This is in reference to an article in CIO titled "Maine's Medicaid Mistakes". The article continues to dig in the past without providing a guidance and assumming the reader to take their own prespective of the events. However it surprised me the overzealousness of the author to identify shortcomings of the State government to execute a project with a detailed chronological trail of events without acknowledging the good work being done to adapt to the precarious situation. The author identifies implementing unproven technology as one of the lessons learned, however mentions the use of J2EE systems later in the article as "the Ferrari of software code, which some of the largest corporations are now using to run their global operations".
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?

Let’s discuss what are your options if there are some constraints which are preventing you from using agile methodology or simply if your customer does not want to use Agile methodology.
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

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?

We are still debating in most projects whether to use Agile or use traditional approach.
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

The Annual Davos Meet continues to act as the greatest trendsetter in terms of laying new directions and establishing new paradigms in the world economic trends. Every year the visit is limited in invitation to the Who's Who's of the world. The Top CEO's like Charles Prince of Citigroup, Edward J. Zander of Motorola, Stephen A. Schwarzman of Blackstone Group, Henry A. McKinnell of Pfizer, Sir Martin Sorrell of WPP, Arun Sarin of Vodafone, David J. Stern of the NBA, Kai-Uwe Ricke of Deutche Telekom are there to name a few. But the strange aspect of this meet, which creates the unique yet powerful air to this summit is that, all participants are by invitations only. So, don’t feel cheated if your company CEO, COO is not on the list. I guess, they are not deemed special by the WEF selection board. But what made me write this BLOG is a comment on the WEF Blog titled "The elephants in the room" by Dan Bilefsky. The elephants being mentioned are India and China. The thing that peeved me off was the comment that the WEF forum shall discuss reforms/ideas to address the messy democracy of India. It fails to impress me that how could you point the democracy of India in that derogatory nature. I think it is high team people realize democracy is "by the people" and you got to appreciate and respect the settings of any democracy. Every country cannot be run in the US mode, which claims healthy public opinion, issue based elections, healthy infrastructure for entrepreneurship and capitalism as the only form of valid democracy. India chooses to establish its own path to success not only producing healthy entrepreneurs in the process (India has one of the most successful small business sector in the world) but also excelling with 7-8% GDP growth in the post liberalization world. Just because the developed countries feel that they are being beaten at their own game by the locals entrepreneurs does not warrant system changes. Play the game by the Rules of the Game. Home team has a distinct advantage. It is not that Indian system cannot improve and it may take some of the ideas from America, but I hate to see immature comments and use of terms such as messy democracy by people who have little to no knowledge about the rules of the game in India. India and Indians would continue to succeed with their hardworking attitude and strong moral and ethical backbone. I wish all the participants good luck at this year WEF Forum