Article summary
In my time at Atomic Object, I’ve worked on a range of projects. These projects have spanned domains like education, transportation, and health and wellness. Some were web apps, others native mobile apps, and still others cross-platform native apps. As I’ve gained experience onboarding into these various projects with their wildly different contexts and technical choices, I’ve begun thinking of each software project as its own language.
In this context, I don’t mean programming languages like Typescript, Swift, or Haskell. I actually mean human languages like English, Spanish, or Japanese. So, why is this the case, and what can we take away from this framing?
How Your Software Project is Like a Language
Learning a language is social.
Human languages are learned socially. Well, there are lots of competing theories about exactly how we learn our first languages. However, the point stands that languages are about communicating among people, and the learning process requires other people to communicate with.
Similarly, a software project is also about communication. A software project must translate the stakeholders’ and developers’ intent correctly to the computer running the code, but maybe more importantly, a codebase must communicate its intent and assumptions clearly to other developers. This isn’t a groundbreaking notion in software development. However, by framing the project as a language unto itself, we see the importance of learning via pairing. Essentially the “child” or new developer learns by working closely with the “adult” or already experienced developer. By pairing closely, the new dev can ask questions and make small mistakes, always readily corrected by the more experienced developer. The idea that a project represents a language for the team to learn cuts right to the heart of the power of AO’s Teach and Learn value.
Forgotten languages are hard to learn.
There is a corollary to the notion that projects are languages that are best “taught” socially: a project that no longer has any fluent speakers is far harder to learn. Languages become extinct when they no longer have any native speakers. In fact, the Hebrew language is the only example of an extinct language revived on a large scale in human history.
The situation in software isn’t quite so dire, since lots of old projects have been abandoned and revived over time. That doesn’t mean there isn’t something interesting to learn here, though. The reality is that when a project goes “extinct” and no longer has any active engagement, the project quickly starts becoming an archaeological artifact rather that a living tool for communication. The process of learning shifts away from being a social, communicative process, and towards something like interpreting ancient scrolls. Think learning ancient Egyptian via the Rosetta Stone as opposed to learning Spanish via immersion classes.
Similar languages are easier to learn.
Another similarity between software projects and languages is that certain families of languages are easier to learn once you already know one. A fluent speaker of Spanish has a huge leg up in learning French and Italian over someone fluent in English, and a German speaker is a long way toward speaking Dutch.
In the same way, projects with similarities along various axes are far easier for devs to onboard. The most obvious similarity is, of course, the programming language used to implement the project, but other considerations are important as well. A developer who is deeply familiar with the JVM via Java might have an advantage onboarding to a Clojure project. Someone with deep functional programming chops might move between an F# and a Haskell project easily. A developer who is familiar with the problems inherent to ERP systems will have more leverage from one project to the next, even in widely different domains.
Takeaways
So if we can frame software projects as languages, what insights can we derive? What next steps can we take to improve our craft with this analogy in mind?
Maintain team context.
Maintaining a team of developers who are actively engaging with the project is the best way to prevent a project from becoming an extinct language. When most people think about keeping a team engaged, the benefit that most readily comes to mind is that they can create new features or fix bugs more quickly since someone already has context. But, by viewing the project as a language, we see an additional superpower that ongoing engagement affords: more language arts teachers for new devs. Teams are always changing and evolving. Keeping a team engaged and speaking a project fluently ensures that new additions to that team have the most opportunity to establish their own fluency.
Maximize linguistic similarity between team and project.
Another takeaway ties back to the idea that similar languages are easier to learn once you already know one. If you have lots of developers who speak Spanish, it might not be the best idea to write a project in Arabic. How does that play out in the real world? When making technical decisions or team composition choices for a project, try to maximize similarity between the team’s existing fluencies and the direction of the project. Try to include a developer with native app experience on a native app project, chose a functional style when the team is already fluent in functional software design, and so on.
This isn’t to say that any given team should always make the same technical choices over and over languageagain. Knowing Italian doesn’t mean one shouldn’t learn another language, just that the other romance languages will be easier to learn. Similarly, we should always try to push ourselves and expand our expertise into new areas, but by maximizing the linguistic similarity between past and current projects, we can deliver more value to our clients while we do so.