software archaeology by globant
TRANSCRIPT
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