Code archaeology

 

 

There is no love, no tenderness, no emotion, no trust and no God in a piece of code. You can search, you can dig and you can wail at the injustice of it all but the only thing you are going to find are mistakes, abandoned paths, and lines upon lines of code written by people who are not here and all that they have felt, experienced during the creation of the code you are reading is forever lost, forgotten, not important.

But it is important. Recently I’ve done a lot of code archaeology, reading and analyzing solutions (some which are more then seven years old) discovering how such system are built and how are they organized with the goal of identifying pieces of code which can be transferred into the new ports of those system which are going to be built.

By reading that code I’ve found a story. A story of ideas not reached, of pressures and short cuts taken, of principles and practices which were a standard of the time that code come came from but now I know them only from my books and my own early work.

I was lucky and got to talk to the people who worked on those systems, and got to ask my questions. Why such a decision was made, why this and why not that. Is this used and why not. And I got a story of humans. People working and feeling their work end expressing them selves trough code.

The end result of each code archaeology activity was a new architecture document document the found architecture, all the technical decisions and patterns found within without judgment, written just like it is.

While doing it I found the following principles helpful:

• Do not judge
• Identify design pattern and name them
• Identity individual sub architectures and follow them separately
• Sketch

Do not judge is in my opinion the most important rule, principle and state of mind while doing code archaeology. The basic principle of the activity is to see and read what is built. The design patterns, architecture and coding style may well be something which is archaic, non modern and not pretty but it may not have been like that when it was built A web from application written in Visual Basic for .NET 1.0 is a child of its times and it is not reasonable to apply todays software development criteria to such an old system. Secondly I never met a developer who when faced for the first time with a system written and developed by someone else who didn’t start cursing and wailing about the poor quality and decisions made by the previous developers.

We developers are an opionanted bunch who would rather spend days and week arguing about what about the proper placing of business classes and their proper naming rather of accepting the current situation and getting some work done. This is actually good since is brings us to question everything and to advance as a industry as a whole

But when doing code archaeology, when reading and analyzing someone else's work this attitude will block us from seeing and understanding the software we are working with and finding it inner beauty.

The most important contribution to the modern practice of software development was the definition and introduction of Design patterns as a vocabulary and definition language which transcends all languages and software types. Thus when doing software archaeology it is most important to identify patterns of code use, name them accordingly and document their use. This practice makes the activity of analyzing and communicating the results of a software code archeology that much easier.

Any non trivial software project is actually composed of many individual sub architectures which together bring the solution to bear thus as an individual developer sees his work trough the integration of a group of classes thus a software architect sees a software system as an interaction between multiple sub architectures.

Not only it makes easy to document a complex software solution, it is the only easy way to analyze it. Modern software is complex. It has multiple moving parts which interact with each other trough time and space. A human mind can fathom only a limited set of the reality it is immersed into it at any given moment of time. Thus the only logical solution to comprehensively analyze any software system is to follow to exclusion of everything else each sub architecture boundary within is self separately from every other architecture.

Then, and only then, after each sub architecture was analyzed to its full extent. The next step is to analyze the interaction between various architecture, the same as we watch the interaction of several classes.

In the end software archeology is about understanding, documenting and the future. As archaeologist catalogue, analyze and document their findings for other to use, thus a software archeologists end product is document describing her finds. The best tool at the disposal of software archaeologist is the ability to visualize graphically old the processes, integrations and logical modules of all the key ideas being documented.