Reading Code...Software Archeology - 2

In the almost a decade of IT experience I can safely conclude that I have read more code than have written.
This is true for many of us. In college we spend most of the time writing code and the moment we are out in the industry , we join a project team and put  in a situation where the majority of the time we spend in reading (others) code.
This is always true at-least in Indian market where the engineers work on the outsource project.

Few other reasons:
1. Most of the companies have a big agenda of "Re-use".  They always emphasize and encourage teams to create a librabry re-usable components/assets. Often they track this by metrics on how much your team has shared and how you have reduced cost by using the already available components.
2. There are umpteen number of opensource libraries. Most of them lack documentation. The only to make it work is to open the source and digest it.
3. 80% of the projects that get outsourced are maintenance and enhancement which lack up to-date documentation.
4. Legacy projects
etc

Look at this way,we almost spend about 60-80% of our time in the industry reading code and 15-35% writing code and remaining on other activities but almost all the tools, processes, standards, best practices that are available on the web are for writing and creating new systems but very minimal to read & understand existing code.

What is Software Archeology?

I will leave the veterans and experts of the industry to shed more light on this:
Digging code: Software archaeology - Good overview
Grady Booch on Software Archeology
Listen to Dave Thomas on SE Radio
Article on Java Dev Journal

In my next post, I will share my experiences of diagnosing and understanding a complex Java EE app using some of the tools that I stumbled upon on the web.