Do fundo do mar... Sea bottom
Thursday, November 04, 2004
Digging code: Software archaeology
______________________________________________________________________________________
Builder.com
Simon Sharwood
At first glance, business software developers have little in common with Indiana Jones. But the emerging field of software archaeology applies some of the same skills, if not the dashing adventure
In 1900, a Greek sponge diver found the wreck of a 2000-year-old ship near the island of Antikythera. The sunken ship yielded up the usual ancient booty, but among the loot was something unusual: a corroded lump of metal with a large wheel on its front. Decades later, gamma-ray examinations showed that the artifact contained bronze gears and wheels.
Science historians now call the device the Antikythera Mechanism, and science historians agree that it is the earliest known computing machine. To this day, however, despite many tests, simulations and reconstructions, no one knows exactly what the Antikythera mechanism actually computed. While the favorite theory alleges that it calculated the position of the stars to aid navigation at sea, its designers and builders are long dead, ancient literature lacks a single mention of such devices and the only documentation it bears is an inscription suggesting the island of Rhodes as the place it was built.
This ancient riddle will seem familiar to many software developers confronted with the task of rebuilding applications. Like the Antikythera Mechanism, many applications were created years ago by unknown coders who left no documentation and can't be reached any more. Yet the mystery of their work can be as important to a business as the Antikythera Mechanism is to an archaeologist, as uncovering the business value encoded into an old application can tell a business a lot about its past and help shape its future.
The birth of software archaeology Because old code has such potential, developers around the world are starting to develop formal practices to conduct "software archaeology," the discipline of investigating and re-invigorating old applications so their structure can be fully appreciated and their code put back to work.
The need for software archaeology is not exclusively the domain of mainframes. "I did a 'dig' for a website moving from Windows DNA to .Net," recalls Davyd Norris, a Rational Technical Consultant at IBM. "They asked for a website critique. What we found was four different styles of web architecture.
We could almost see work by different consultants based on the way the HTML was put together," and detect which version of Microsoft's fast-evolving web tools had been deployed as the site evolved.
Early editions of Visual Basic and the languages used in the client-server boom of the early 1990s are another common source of "digs." Few who coded in those languages suspected their work would last long, resulting in little documentation. Software created by newer methodologies is another subject of software archaeology, with the legendary payroll application for automaker Chrysler that kick-started the Extreme Programming movement recently the target of software archaeology.
Short-lived platforms and architectures are another reason for archaeology: the skills required to code under Data General's DG-UX operating system and NUMA APIs are obsolete. Human nature chips in too: source code goes missing, documentation disappears, or programmers just code unintelligibly for no good reason.
Whatever the source of the problem program, the reasons for conducting software archaeology are prosaic: repairing an application for re-use or porting to a newer environment is generally faster, cheaper and less risky that starting an application from scratch.
"Often software archaeology gets done because a company sees that a program is working but needs to understand it better before they can web enable it," says Michael Hawkins, Asia-Pacific General Manager of professional services for Software AG. "I also had one project where the customer was redeveloping an old application into Java. The CIO came along half way through, asked where the value was in doing that and they ended up doing archaeology instead."
This potential to save money and speed development makes software archeology a good business opportunity for practitioners, as Peter Taylor can attest. Taylor, Director of Strategic Alliances for Australian company Quipoz, proudly points to growth to 23 people just 30 months after opening to provide what it calls "automated legacy system transformation," and already plans more hires.
"Customers need our services to reduce costs," Taylor says. "Licence and maintenance fees for mainframe applications and hardware are substantial. If we can get them off the mainframe we save our clients a lot of money," a message that has quickly won the company clients in the banking and finance, industrial and insurance sectors in Australia, New Zealand and the UK...
See the link for the rest of the article...
Builder.com
Simon Sharwood
At first glance, business software developers have little in common with Indiana Jones. But the emerging field of software archaeology applies some of the same skills, if not the dashing adventure
In 1900, a Greek sponge diver found the wreck of a 2000-year-old ship near the island of Antikythera. The sunken ship yielded up the usual ancient booty, but among the loot was something unusual: a corroded lump of metal with a large wheel on its front. Decades later, gamma-ray examinations showed that the artifact contained bronze gears and wheels.
Science historians now call the device the Antikythera Mechanism, and science historians agree that it is the earliest known computing machine. To this day, however, despite many tests, simulations and reconstructions, no one knows exactly what the Antikythera mechanism actually computed. While the favorite theory alleges that it calculated the position of the stars to aid navigation at sea, its designers and builders are long dead, ancient literature lacks a single mention of such devices and the only documentation it bears is an inscription suggesting the island of Rhodes as the place it was built.
This ancient riddle will seem familiar to many software developers confronted with the task of rebuilding applications. Like the Antikythera Mechanism, many applications were created years ago by unknown coders who left no documentation and can't be reached any more. Yet the mystery of their work can be as important to a business as the Antikythera Mechanism is to an archaeologist, as uncovering the business value encoded into an old application can tell a business a lot about its past and help shape its future.
The birth of software archaeology Because old code has such potential, developers around the world are starting to develop formal practices to conduct "software archaeology," the discipline of investigating and re-invigorating old applications so their structure can be fully appreciated and their code put back to work.
The need for software archaeology is not exclusively the domain of mainframes. "I did a 'dig' for a website moving from Windows DNA to .Net," recalls Davyd Norris, a Rational Technical Consultant at IBM. "They asked for a website critique. What we found was four different styles of web architecture.
We could almost see work by different consultants based on the way the HTML was put together," and detect which version of Microsoft's fast-evolving web tools had been deployed as the site evolved.
Early editions of Visual Basic and the languages used in the client-server boom of the early 1990s are another common source of "digs." Few who coded in those languages suspected their work would last long, resulting in little documentation. Software created by newer methodologies is another subject of software archaeology, with the legendary payroll application for automaker Chrysler that kick-started the Extreme Programming movement recently the target of software archaeology.
Short-lived platforms and architectures are another reason for archaeology: the skills required to code under Data General's DG-UX operating system and NUMA APIs are obsolete. Human nature chips in too: source code goes missing, documentation disappears, or programmers just code unintelligibly for no good reason.
Whatever the source of the problem program, the reasons for conducting software archaeology are prosaic: repairing an application for re-use or porting to a newer environment is generally faster, cheaper and less risky that starting an application from scratch.
"Often software archaeology gets done because a company sees that a program is working but needs to understand it better before they can web enable it," says Michael Hawkins, Asia-Pacific General Manager of professional services for Software AG. "I also had one project where the customer was redeveloping an old application into Java. The CIO came along half way through, asked where the value was in doing that and they ended up doing archaeology instead."
This potential to save money and speed development makes software archeology a good business opportunity for practitioners, as Peter Taylor can attest. Taylor, Director of Strategic Alliances for Australian company Quipoz, proudly points to growth to 23 people just 30 months after opening to provide what it calls "automated legacy system transformation," and already plans more hires.
"Customers need our services to reduce costs," Taylor says. "Licence and maintenance fees for mainframe applications and hardware are substantial. If we can get them off the mainframe we save our clients a lot of money," a message that has quickly won the company clients in the banking and finance, industrial and insurance sectors in Australia, New Zealand and the UK...
See the link for the rest of the article...
