Editor's note: What are the best practices in moving data to the clouds?
Learn more here!
I've been writing software for a long time.
When I was 14, I taught an HP programmable calculator to tell time by flashing
hours, minutes and seconds repeatedly. It used a loop of null operations to
take up the time between each second. Slight changes in room temperature would
cause it to speed up or slow down the rate at which it performed these loops,
ultimately making it a poor timepiece.
But I was hooked -- I have loved programming since those days. That was almost
three decades ago and since then, I've been writing some kind of software almost
every day or managing those who do. For the last decade, I've been running a
company that creates and sells software.
In all that time, there has been a recurring theme in our industry that keeps
raising its head over and over again: reusing already battle-tested software
is preferable to writing new software. How can we do a better job of reusing
legacy software?
Reusability -- The Holy Grail
That same wonderful HP company that got me started on this path (and is now
one of my customers) put out a great book in 1992 with the obtuse title, "Practical
Software Metrics for Project Management and Process Improvement." I know
it sounds like a snoozer, but it's not. Although this book is more than 18 years
old, it could have been written this year, because the concepts are still relevant.
Among the research are these two nuggets of wisdom:
1.Projects created primarily from reused software experience only about 1/3
the defect density of those that are new.
2.Projects created primarily from reused software take about 1/4 the time and
resources of those that are new.
There are many other nuggets. It's a great book.
Enter Service-Oriented Architecture (SOA) -- the next wave of reusability.
Whenever "the next big thing" is announced, CIOs are understandably
skeptical. At a recent IBM SOA conference that I attended in Dallas, one CIO
of a Fortune 500 firm said to me, "Is there really a standard here or is
this like the OSF where all the Unix vendors bickered endlessly, producing little
agreement while Microsoft chortled in the background? SAP says they have thousands
of companies participating, IBM says they have 300 ISVs and thousands of 'assets'
-- are they counting the same things? Are they in agreement over definitions?
I don't think so."
-1-