Writing code, reading code and software archeology

The name of this blog, Once More into the Code, is a modification of the opening line from William Shakespeare's King Henry V, Act 1 Scene 1 that starts "Once more unto the breach, dear friends, once more; or close the wall up with our English dead."   As developers we are constantly diving into new projects, exploring old projects, and deeply engaged inside our current projects.  Forty years ago this month, I wrote my first program as a college freshman at Cal Poly San Luis Obispo.  That program was the classic prime number generator program, written in Fortran, and was punched on cards and submitted to the college's IBM 360 model 40 main frame computer.  Back then, we would deposit the cards in a tray, glue our noses to the glass window to see when our jobs would be run, and wait for the cards and printout to know whether we had a successful execution.

We have come a long way in the past 40 years, and it is still exciting to create programs today.  Software engineers are intimately connected to the rise of the modern software economy.  Some developers love to be at the forefront of today's technology advances, others prefer to do their job and go home to other things.  We are part of a wonderful software engineering social network.  We love talking with other developers, sharing ideas and best practices.  Do you hang out on "answer" sites like Stack Overflow looking for solutions to problems or providing answers to improve your street credibility?  How many of you read SlashDot every day?  How many of you write at least 100 lines of code each day?

There isn't a day that goes by in which I don't read or write code.  Write code?  Sure, all programmers write code.  I also spend a lot of time reading code: my code, other's code, open source code, example code.  In college, we learned how to write code by learning the syntax and semantics of programming languages, reading code, and writing code.  A good book to check out if you're interested in this is Code Reading: The Open Source Perspective, by Diomidis Spinellis, Addison Wesley, 2003. ISBN 0-201-79940-5. Spenellis' book focuses on the reading and comprehension of existing code.

At OOPSLA 2001, Ward Cunningham, Andrew Hunt, Brian Marick, and Dave Thomas ran a workshop titled, "Software Archeology: Understanding Large Systems".  The workshop focused on gathering techniques and approaches that would allow programmers to come up to speed on a large software system that they have not seen before.  If you just inherited or joined a project that has 1 million lines of code, you can do a few things to learn as much about the software system as possible: view an architectural diagram, study the design characteristics, examine the source code, review the business logic, study the unit and system tests (if any), review the performance data, and assess the state (or lack of) documentation.

There are other sources of information and guidance regarding Software Archeology including:

Where do I usually spend my time?  I am in the code.  I am always in the code.  I might create some forms, reports, database connection strings, and other artifacts, but right now I am "Once more into the code".  Do you read code?  How have you quickly picked up someone else's code?  Submit a comment below.

Programming is Life!

Recent news for developers:

David Intersimone (David I) is the Vice President of Developer Relations and Chief Evangelist for Embarcadero Technologies.  My company blog is at http://blogs.embarcadero.com/davidi

FREE Computerworld Insider Guide: Five IT certifications that won’t break you
Join the discussion
Be the first to comment on this article. Our Commenting Policies