Software archaeology and anthropology

Most developers enjoy working on greenfield projects, because we can have a larger influence on big, early decisions that shape the technical direction and culture of a product.

But realistically, most work is done with existing software.

It’s in everyone’s interest to get a new team member ‘up to speed’. If they’re lucky, there will be some kind of onboarding process that has been developed over time.

READMEs, wikis, buddy systems, checklists, 7/30/60/90 day goals, and even full training courses are typical ways of approaching this problem.

These can all help in their way, but when it comes to actually contributing, a new team member inevitably ends up on a journey of discovery through the ups and downs of the code base.

This is difficult enough as an individual contributor, but if you’re coming into a project as a leader… oof.

If you search for software archaeology techniques, they focus heavily on systematic approaches to understanding code, including static analysis, reverse engineering and code walk-throughs.

These are useful where there is a poor record of change (version control systems) and decision-making (architectural documentation).

But for me, by far the most valuable way of gathering information about a code base is to talk to the people that worked on it.

Have them take you through the history of the work, the key decisions that were made, the background behind seemingly odd choices and the company culture. Understand which approaches were taken at different stages of a product’s life, and the wider context of the trends in web development at the time.

As a starting point for understanding code, being aware of the context and history of decision-making and the hidden social dynamics of the people that worked and still work on it are far more useful than looking at git history or file structure.

We humans love stories, and you’ll notice that long-serving staff tell old stories about how a product was developed with reference to the people involved. They’ll rarely talk about the code in itself in isolation.

Ultimately, you’re trying to immerse yourself in the development culture around the project, both now and in the past, with the aim of building empathy with the existing team.

More software anthropology than software archaeology, if you like.

Here’s an exercise:

Is there someone on your team who has been working on the product longer than you? If so, ask them to tell you their favourite story about something that happened before you arrived.

All the best,

– Jim

P.S. Happy GDPR day, everyone! You made it! Anyone who’s been working on GDPR compliance is likely to have some fun stories (or cautionary tales) to tell in the future. But for now, enjoy the weekend.