Today’s technology is unfortunately tomorrow’s legacy system. For example, the
Web 2.0 revolution sees the current crop of web sites as legacy Web applications
comprised of multiple HTML pages; Web 2.0 envisions sites where a user interacts with a
single dynamic page—rendering a user experience that is more like traditional desktop
applications . Porting the current crop of legacy web sites to Web 2.0 will require
understanding the architecture and design of these legacy sites—again requiring reverse
engineering skills and tools.
At first glance, it may seem that the need for SRE can be lessened by simply
maintaining good documentation for all software that is written. While the presence of
that ideal would definitely decrease the need; it just has not become a reality. For
example, even a company that has brought software to market may no longer understand
it because the original designers and developers may have left, or components of the
software may have been acquired from a vendor who is no longer in business .
Going forward, the vision is to include SRE incrementally, as part of the normal
development, or “forward engineering” of software systems. At regular points during the
development cycle, code would be reversed to rediscover its design so that the
documentation can be updated. This would help avoid the typical situation where
detailed information about a software system such as its architecture, design constraints,
and trade-offs are found only in the memory of its developer .