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.

Reading Code...Software Archeology - 1

Finally things have come to an end..and there is some relief of completing this particular project.
This project had some history (of-course not a good one) of being slow, complex, no-documentation, open bugs etc. My luck, I landed in this one. But there is always some scope to learn..be a new project or old project.

Background:
This project was a IBM WAS portal application (one big portlet) built using legacy struts1.1 framework and accessing a set of remotely deployed ejb services. The ejb services project (was configured with 6 datasources) acted as a service provider and the portal project as the consumer of services.

Size wise, the portal app is having 6 very big struts 1.1 action classes (where all the UI logic resides), 11 packages & about 20 KLOC. When I say very big, I mean very big about 5KLOC in each action class.

The goals of this project was to de-portalize i.e. move away from the portal run time - i.e. to save some money on portal licenses & merge the complex ejb services project with this one. This is primarily to strip of ejb layer so that performance is improved and all its services are local. Everything is at one place and so it is more maintainable.
btw, earlier I wanted to use the word - re-architecting but found out that there is no existing architecture in the current project to do that. So instead used another jargon - de-portalizing.. :)

But what this has all got to do with the Topic of this blog..Reading Code...Software Archeology.

You might have guessed based on the above background where I'm heading to..