Wednesday, February 11, 2004

Analysis! The core of IT work?

Today I thought I will speak to you about something close to my heart (and wallet). I am of course referring to my industry, the fast-track, remedy of all economies, the IT industry.
I am essentially a coder, though I haven't coded in a while. For a long time, like many others around me, I was of the view that a software project was all about coding fast, coding smart and coding correctly. However as the title suggests this view has changed over time. Now I feel that Analysis along with Requirement Capture is the most important thing in a project.
Face it, coding expertise has almost become a de-facto requirement to work in the industry and more often than not you will find efficient programmers here. However where we, including myself, goof up is in the region of requirement capture and analysis.
The advantages of a correct analysis are numerous, and most of them are directly connected to the bottom line. Proper and swift analysis bring forth early on the estimated time that the work will take as well as expected risks. This results in better management and buffering for the project. Bad analysis is of course obviously costly as the project goes on a completely different track. However good analysis is also not useful if not done on time. The result of a late analysis is that one is forced to accept the terms of one's clients as one does not have any facts to oppose these terms. This puts the project onto a sweat-shop situation. I myself have been guilty of it and I expect every programmer will make or already has made this mistake.
The problem is the basic mentality of a programmer of not asking for a review or checking an assumption till he/she is sure that he/she has crossed all t's and dotted all the i's. I have realized that this mentality is very harmful for the project. It is better to ask silly question around the early quarter of a project's life-cycle rather than come up with a deep one just days before release. This is not to say that questions should not be asked. It just means that one has to start thinking in the manner that all analysis that may need an input from the customer has to be done and completed as early as possible. This requires complete understanding of both the goal of the project and about the code to be worked on or created for attaining this goal. This is of course not doable all the time but like all good habits keeping this in mind at all times will make one much more professional in today's hectic work space.

Does all of the above make sense; it does to me and if I have failed to put my thought across succinctly then please forgive my communication skills and try to catch my drift. Or as a good friend of mine always says "Sur ko Pakad"!!!:D