The term Software Archeology has been used in various forms since early 2001.
The concept of Software Archeology is an approach or methodology that helps
individual team members or entire teams to understand exactly what they have
in the code they're going to be working on. The approach is also very useful
when deconstructing an existing piece of software to find patterns of design
and development that could be "harvested" in future developments.
The great thing about Software Archeology is that it doesn't only pertain to
Java but can be used with any software language. This article will focus
specifically on Java but the approach can be applied to almost any kind of
development project. In today's market where the Java language is very mature
and most new Java projects aren't from scratch, but focused more on
extensions or maintenance, where the end goal is to make ... (more)
I've been programming since around 1982, first using an Apple in high school
and then finally getting my first computer, the Timex Sinclair 1000 (2k of
ROM and 2k of RAM), that same year. Both computers came with a form of the
BASIC programming language and it was the start of my lifelong pursuit of
trying to understand computers.
A few months ago, one of my good friends called and asked if I had a
PowerPoint presentation on the history of programming. When I checked my
extensive list of presentations, I noticed that I didn't have one, so that
led me on a journey to create a pre... (more)
It would seem only logical that after 9/11, one of the most horrific days in
American history, corporations large and small would be ready for unforeseen
catastrophic events. However, by one recent estimate, less than 38% have put
a complete disaster recovery plan in place - the policies, processes,
procedures, and architecture to deal with unforeseen events. In the wake of
Hurricanes Katrina and Rita, IT managers are again forced to reassess how
well prepared they and their organizations are to manage through and recover
from natural or man-made disasters.
Understanding the str... (more)
Some walls are necessary. We use brick-and-mortar walls to support buildings
and firewalls to protect our computers from attack. But not all walls are
good. Consider the Berlin Wall, a wall of segregation. It divided a country
and its citizens, but has subsequently been brought down by people working
together because upon re-evaluation the Wall did more harm than good. These
thoughts led me to think about the walls that developers, QA managers, and
database professionals have erected over the years to segregate themselves.
Is it time to re-evaluate our own walls?
Most organizati... (more)