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 strategic goals and requirements for surviving a
catastrophic event is one thing, but actually having a set of guidelines in
place for handling the tactical issues involved is quite another. Ultimately,
the goal is to recover and restart business operations quickly and
efficiently. But successf... (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)
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 artic... (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)