software archaeology software archaeology or software archeology is the study of poorly documented or undocumented legacy software implementations as part of software maintenance techniques a workshop on software archaeology at the 2001 oopsla objectoriented programming systems languages applications conference identified the following software archaeology techniques some of which are specific to objectoriented programming scripting languages to build static reports and for filtering diagnostic output ongoing documentation in html pages or wikis synoptic signature analysis statistical analysis and software visualization tools reverseengineering tools operatingsystemlevel tracing via truss or strace search engines and tools to search for keywords in source files ide file browsing unit testing frameworks such as junit and cppunit api documentation generation using tools such as javadoc and doxygen debuggers more generally andy hunt and dave thomas note the importance of version control dependency management text indexing tools such as glimpse and swishe and like true archaeology software archaeology involves investigative work to understand the thought processes of ones predecessors network and temporal analysis techniques can reveal the patterns of collaborative activity by the developers of legacy software which in turn may shed light on the strengths and weaknesses of the software artifacts produced michael rozlog of embarcadero technologies has described software archaeology as a sixstep process which enables programmers to answer questions such as what have i just inherited and where are the scary sections of the code mitch rosenberg of infoventionsnet inc claims that the first law of software archaeology he calls it code or data archaeology is everything that is there is there for a reason and there are 3 possible reasons it used to need to be there but no longer does it never needed to be there and the person that wrote the code had no clue it still needs to be there and you have no clue the corollary to this law is that until you know which was the reason you should not modify the code or data software archaeology has continued to be a topic of discussion at more recent software engineering conferences the profession of programmerarchaeologist features prominently in vernor vinges a deepness in the sky software testing portal software architecture recovery code refactoring retrocomputing software brittleness software rot software entropy abandonware position papers oopsla 2001 workshop on software archeology understanding large systems writing code reading code and software archeology once more into the code blog at computerworld september 23 2009 how to apply software archeology to your development process presentation by michael rozlog march 13 2008 oopsla 2008 podcast with grady booch on software archaeology and related topics vtesoftware engineeringfields computer programming requirements engineering software deployment software design software maintenance software testing systems analysis formal methods concepts data modeling enterprise architecture functional specification modeling language orthogonality programming paradigm software software archaeology software architecture software configuration management software development methodology software development process software quality software quality assurance software verification and validation structured analysis orientations agile aspectoriented object orientation ontology service orientation sdlc modelsdevelopmental agile eup executable uml incremental model iterative model prototype model rad up scrum spiral model vmodel waterfall model xp other spice cmmi data model er model function model information model metamodeling object model systems model view model languages idef uml usl sysml softwareengineers victor basili kent beck grady booch fred brooks barry boehm peter chen danese cooper ward cunningham tom demarco edsger w dijkstra delores m etter martin fowler adele goldstine margaret hamilton c a r hoare lois haibt mary jean harrold grace hopper watts humphrey michael a jackson ivar jacobson alan kay nancy leveson stephen j mellor bertrand meyer david parnas trygve reenskaug winston w royce james rumbaugh mary shaw peri tarr elaine weyuker niklaus wirth edward yourdon related fields computer science computer engineering project management risk management systems engineering category commons 