Archeology in programming

Let’s talk about archeology. It feels like discovering the truth is scientifical but is it? And what does it have to do with programming?

Logic

Logic plays with 2 directions: up and down. Guess or conclude. Induce or deduce. Facts come from deducing (or measured observations). Archeology is mixing both approaches. However, there is a trap. Deducing from prior potentially wrong guesses can bring another guess that may be mistaken for a “fact”. And this is done A LOT in archeology (and in general). That approach is fine when it’s temporary. It’s called speculation. However, media and general lack of calm in public turns all deductions into “facts”. And the snowball goes.

Programming is no different though. Software engineers have to perform the guesswork and take the leap very often, just to find out the assumptions were wrong. However, we need it.

Sometimes we need to take two steps back to make a good one forward.

Information

I feel thirsty when I hear that archeologists have found something new that is staggering. I want to sigh, moist my throat and then speak up how silly kind of a “science” it is. Too many times I’ve read the article and I’ve seen that 90% of the content are assumptions based on virtually nothing.

Yes, having a thesis that can be challenged is good. It allows to test a given approach and potentially call it a theory, or abandon it. Theory brings a strong foundation to build stuff on it. However, because we are not machines and there’s an overload of overall information, the society seems to not weigh each piece of information they are basing on.

We end up building informational fortresses on sand.

Digging when programming

Not every information coming from archeologists is a fact. Fact is deduced from a set of theories, thus needing evidence. Whatever I see in media seems to be a guess. Even if it’s logically deduced, it’s very often deduced from either an axiom or a simple guess (not even a well-thought thesis). We can’t find skeletons older than XYZ years? “Probably” no one was there before us.

Thankfully, in programming, it’s a bit easier. Well, I thought so.

Digging into code repisitory I often end up in commit history. However, not this time. Large project, 20+ years of development. Loss of huge amount of history because the repository was moved between different systems, seemingly a couple times already.

And we end up in the guessing game either way.

Step by step please

Before I start working on some feature (let’s say, a screen), I’d like to know if it’s worth it. I overview its current state. Then I can decide what can come next.

Current state of code is not only what’s in the current revision of a file. It’s much more than the bytes written on a disk (or in cloud).

It’s the abstract concept full of ideas: some implementation is not finished, we can find “TODO” comments, and some in design patterns that are not even fully used! There is also some bits of documentation or someone was supposed to write it but didn’t make it in the end. Or it was lost. Everything around the code itself is important. The code is only a projection of higher thinking, most often only some portion of it. The “good enough” portion.

So why dig?

Let’s take a step back. Why would I even look into history of a repository?

I’d love to work on facts only. No guesses. However, sometimes any thesis is good. While programming, we need to make decisions to build upon the future. Tons of tiny decisions that are going to be less or more looked up by someone who’s in the same position as we are in this moment.

So why dig?

• maybe the author is still available and I can ask her/him directly
• maybe there were more authors and I’m trying to identify who to follow (what pattern)
• maybe somebody have already tried an approach that I have in my mind?
• maybe there was no skill issue but a missing library/functionality issue?
• maybe this bug was known and/or intentional before the current state?
• maybe the bug was always there which is a serious security concern? (and needs e.g. emailing all your clients)

I want to ask people about details to save time. It’s great if any knowledgable people still stick around. In other cases, we need to look deeper.

When code is talking different patterns, I want to establish which to follow. The post was abandoned so now I am in charge of taking the direction. But I want to honor prior decisions first because maybe there is some wisdom to it.

Learn about the past first, then take action. Potentially refactoring the whole thing which is a tough and costly decision. Good arguments would be a pleasure to have, and the past may just give them to you.

What do we find?

What we look for versus what we find is also an interesting observation. Just like in archeology. I dig deep, finding the unexpected.

I can sometimes learn the structural/organizational changes just by looking at the code history. Sometimes I can see the lack of ownership from the start, or lose of ownership over time. I can even see the hints of why someone might’ve been laid off. I see the performance of engineers, I see the attention to details, and I see the care for the future folks like me.

I can feel somebody’s talking to me from 7 years ago. I see the message, I hear you. I understand this wasn’t easy and you were under pressure. Thank you for taking the simplest approach. Thank you for leaving a comment about this crash. Thank you for your dedication, Sir/Madam.

Not everyone is perfect, neither everyone has the same skill set or the attention to detail. It may have all started great but then a junior came in, or a hot deadline approached. It’s really useful to draw a line between the last quick fixes and the original idea. It helps identifying the need for a cleanup or a total refactor. It can tell us what is a bug or until which point it was still a consistent feature.

I find me, you finds you

In the end, it’s all the same soil. I sometimes end up watching my own code. I can reflect from that as well. I can see how different the younger me was from the current me. Life is a lesson to everyone. But it’s a lesson mostly to ourselves.

Coding is not archeology. However, a long lasting project development needs archeological thinking in my opinion. If we care for the future, let’s make sure we still have the foundation we wanted in the first place, or if we want it to begone. Let’s make sure we have people who want the same, and can do it. It’s not easily measurable by any means. It’s a delicate issue of quality, perceived as the final product.

We draw the idea, plan, develop, and circle back to the drawing board. It’s crucial to adapt accordingly at any phase. It’s crucial to understand not just the “idea” but also who is “we”.