Click to edit Master subtitle style

Software Archaeology

Application Maintenance Problematic

• Highly Coupled with people, no one else can maintain this

• Excessive learning curve cost

• Poor documentation, Black Box, nobody knows what’s inside

• New Vendor: “this application is a mess, we should do it all again”

• I don’t like the development team but I cannot change without paying a high cost

Application Maintenance Problematic

• All soft development theories and practices are made for new developments

• New developments and application maintenance have very different paradigms

• Using the same people, practices and believes for app maintenance that for new developments

• That’s why, good developers and architects usually feel unmotivated with app maintenance projects

• Software Development usually takes practices from another professions (architects, engineers, analyst, etc)

Evidences

• In the eye of the beholder

• Depends what you are looking for

• Remains of working activities

• Only exists when the archeology discovers them. Without this, they are nothing

Focusing

Behavioral Archaeology

In particular this focused on observing and understanding what

people actually did, while refraining from considering

people’s thoughts and intentions in explaining that

behavior”.

Archaeology Dictionary. The Concise Oxford Dictionary of

Archaeology

“An approach to the study of

archaeological materials formulated by

Michael B. Schiffer in the mid 1970’s

that privileged the analysis of human

behavior and individual actions, especially

in terms of the making, using, and

disposal of material culture.

Behavioral Archaeology

• Systemic

Context: Building

process.

• Archaeological

Context:

Systematic

context results

Evidences

Software Archaeology

• Based on physical evidences, the remain of the

systemic context

• The only asset of the company is the developed software

• We only care for what currently exists, and the plans

for the future

• Project history can be used as a guide, as a support,

but that’s it.

Software Archaeology Goal

• Study the archeological context (evidences) to continue with the systemic context as soon as possible

Making the lifecycle in order to last as much as possible, avoiding refuse and reducing discard

Ethnocentrism

Tendency to interpret or evaluate other cultures in terms

of one's own. Generally considered a human universal, it is

evident in the widespread practice of labeling outsiders as

"savages" or "barbarians" simply because their societies differ

from those of the dominant culture.

(...)Any policy, research, and

action on the part of

individuals or institutions that

promote (intentionally or

unintentionally) the believed

superiority of one group,

profession, or set of ideals

over another can be

considered ethnocentric .

Britannica Concise Encyclopedia

Software Development Ethnocentrism• Thousands of truths, changing constantly

• Each Architect has his own toolkit of truths

• Business Validations must be on the business layer

• Persistence should be made using an ORM

• Stored Procedures are the only way of storing data in a safely way

• An enterprise architecture must be built under SOA

• And coders …

• “This code sucks! How could you write a stored procedure with hundred line of code?”

• “This logic is unintelligible, all code should be written following object oriented programing”

• “Why do not write a simple IF, instead of four classes for the same problem?”

Software Development Ethnocentrism

• If you face the problem with your truths, thinking that the other is

wrong, you will not be able to see the real problem. That is

Ethnocentrism.

Software Archaeologist

• Nobody is 100% agnostic

• Software Archaeologist understands the problem FROM the culture being studied, not from his beliefs.

• Managing concepts, not truths or implementations

• Adjusting the concept (persistence, validations, UI, etc) to the existing implementation, and working FROM there

• He Understands the culture and quickly adapts to it

• Looking for the continuous improvement, but being rational with the problem and the business, and NOT from his belief of what is wrong and what is right.

Software Archaeologist Process

Archeological Field Survey

• The architect looks for artifacts where he thinks they should be

• If they are not, or they are in a different way, he has a hard time to get adjusted, besides saying it’s wrong

Software Archeologist goes to the

field with his beliefs and his

assumptions, but he is open mind to

find out the concepts where ever they

are, using the scientific method

Archeological Field Survey

• First contact with the scenario

• Survey of evidences

• According to timing and application size, complete tour or sampling method

• The objective is to understand and learn the application culture

Settlement map: General concepts (verticals) and specific concepts (horizontals) map, with their high level implementations

Excavation

• Get deeper into code and functionalities

• Only in places we assume it would be some activity soon

• Complete knowledge of systemic context (implementation)

• Artifacts Map: artifacts and features associations and relationships, stratigraphic vision

Physical methodology of excavation

1. Work from the known to the unknown

2. Work from the top to the bottom

3. In archaeology, we use our eyes

4. If in doubt, bash it out

Analysis

• Study the results of survey and excavation

• Study new requirements and application plan and forecast

• Crossing results

• Development plan together with the recommended approach to follow

Development

• Based on Archaeologist analysis

• All developers involved into application culture

• Continuity of the systemic context, like the

original team, but following the continuous

improvement

Using all common development best practices (code review, QA, QC, etc)

Aproachs - Maintenance

• In most cases

• Every corrective or evaluative change

• New features, new modules

• Usually have some healthy discard

• Shoring techniques (unit tests, CI, testing automation, etc)

Aproachs – Advance Age

• Functional, non functional or

strategic requirements not

supported by application base

architecture

• Need new tools, new concepts

implementations

• Technology evolution, software

reengineering and even platform

change

Like in the AOE game, investment and research activities are needed

Aproachs – Advance Age

• Currently, in most of these cases, the decision taken is to discard the software and build a new one from scratch

• All investment is lost, all knowledge is wasted, time to market becomes unreachable

• Software Archaeology do not throw anything!

• Everything is reusable, even when migrating from different technologies, all original source code (evidence) has an enormous value

• Don’t think again what you have already discovered

Aproachs – Discard and rebuild

• Almost Never

• It’s like losing a whole culture

• Only when business needs a

100% brand new product

• The business has changed

• The product was originally thought

wrong

Even in this case, we could reuse some particular artifacts from original

software

So, what is Software Archaeology?

• Innovated practice, 100% developed by Globant , for application maintenance solutions

• Methodology, tools, processes, cultural change and technology innovation

• Focuses on the rational and efficient use of software assets

• Minimizing discard, promoting reuse

So, what is Software Archaeology?

• Ready to take any application, in any status, in any moment, without a long, hard or expensive transition

• Minimizes learning curve

• No absolute truths, looking for ROI in every single decision

• Specialized and motivated professionals focused on this type of problems