Software Development
Coding / Data / Digital access / Guest posts / Marketing

What does values-aligned software development look like?

Joe Woods, client application development lead, explains how owning its own stack enables the Fastmail team to build a successful product.

The Fastmail team at their Center City Philadelphia office. (Courtesy photo)

This guest post is sponsored by Fastmail. Fastmail is a Technical.ly Talent Pro client.

When I talk to other people who write JavaScript, they tend to have a lot of questions about exactly what I do every day.

I enjoy the questions I get when I talk about my work. I actually look forward to hearing those questions that start with “Why don’t you just use…” followed by the name of something cool. These conversations give me a chance to talk about the parts of designing applications that excite me the most.

Fastmail has built, or helped to build, a large proportion of the tools we use. We’ve gotten here from a mix of deliberate architectural decisions and, admittedly, a few historical accidents, too. Overture, an application framework written in JavaScript, started due to a lack of better options around 2010. It has since evolved into a framework that uses the design patterns we love while prioritizing speed.

Overture is tightly coupled with JMAP, the JSON Meta Application Protocol. JMAP Mail was designed in response to limitations with IMAP, a protocol for interacting with email messages. From the outset, JMAP has emphasized speed and developer ergonomics. We use JMAP in all of our APIs: not just the typical culprits that are Internet Engineering Task Force (IETF) standards. In addition to email, we also use JMAP for things like the management of masked email addresses, user preferences, and messages to our support team.

We want to be proud of the tools we use. Some frameworks are friendlier to developers, and they might have more documentation and more people working on them, but with those benefits come trade-offs that we aren’t comfortable making.

Take, for example, React. React is not slow, but it’s not Fastmail fast. In contrast, Overture emphasizes speed. It uses lazily computed properties by default. An Overture view which represents data will do exactly the amount of work that’s needed to render a page, with highly optimized paths to draw at ever-diminishing speeds. We also extend these optimizations to the process of how we design our application. For example, our data models, as code, end up looking surprisingly similar to the specifications that we write and commit to our code repository.

There are, of course, many jokes that can be made at the expense of the quickly changing nature of JavaScript development. However, Overture allows us to consider each new best practice as it emerges into the world of JavaScript and decide how they best fit into our systems. We practice iterative development, in stark contrast to the “burn it all down and start over again” tack that frontend developers might sometimes take. You can see the lineage of how Overture has been designed and developed — but we still use many of the design patterns that are visible in this commit to the repository from over 10 years ago.

Fastmail’s commitment to values-aligned development work

At Fastmail, our engineering principles are built on our values. Our use of Overture and JMAP are a reflection of our commitments to both our users and the internet as a whole. We take delight in the challenge of building something the right way in order to make the user experience better.

One of our company values is that we are good internet citizens. In alignment with this, we weave our work on open source software and our commitment to developing open standards into every stage of our process.

For example, we have automatic tooling to make sure that the code we write for Overture for Fastmail’s frontend application can be shared and used by the world. Similarly, Squire, the rich-text editor we’ve written for composition on Fastmail and Topicbox, is open source and used by places like ProtonMail, Tutanota, Zoho Mail, Superhuman and Google Earth.

On the other end of the stack, we are also the primary maintainers of the Cyrus mail server, which is open source software written in C; Fastmail CTO Ricardo Signes is on the Perl Steering Council; even the Slack bot we use to help us have fun and automate our work is open source!

Many Fastmailers engage with standards work through the IETF with JMAP being the primary, but not only, driver of this work.

Using open standards unlocks email’s potential

Email is one of the oldest technologies on the internet. However, working at Fastmail, using Overture and JMAP, I feel like I’m helping to shape the future of the internet and that my work is part of something bigger than a single proprietary email service.

Open source work takes time, and sometimes that means time not spent shipping public-facing features. It’s a lot less work when you don’t need to design and build your own tools. I think of this as building process and doing work upfront so that it pays off later. Working deliberately now allows us to move faster in the future. One of my favorite quotes of all time is from racing driver and performance coach Ross Bentley:

“Steer, shift, and use the pedals smoothly, and with finesse — not with blinding speed and brute force. The slower you move, the faster the car moves.”

I think the results of this are obvious — reflecting on the last handful of months, not only have we implemented custom swipes and scheduled message sending, but we’ve also made some exciting changes behind the scenes; one example being improvements to our automated, continuous-integration testing framework. We’re able to move this quickly because we have a shared understanding of our systems and a strong sense of how to design our application.

This is not to say that owning your own stack is right for everyone. I think, once you reach a certain level, you’ll start to notice the inefficiencies that surround you. Once this happens you may find yourself realizing that it’ll be faster and maybe even more fun to just build it yourself. Not every organization is going to have the expertise or the time to be able to go off and build things off the beaten path.

I would ask all of you, though, to know your values: Knowing the why behind the what will make architecture decisions nearly self-apparent. Knowing that everyone on the team shares those same values means that these conversations always start on a common ground with a shared goal. If you figure that out, the rest are just implementation details.

Learn more about Fastmail and explore jobs
Companies: Fastmail
Series: Digital Infrastructure Month 2022
Engagement

Join the conversation!

Find news, events, jobs and people who share your interests on Technical.ly's open community Slack

Trending

How venture capital is changing, and why it matters

What company leaders need to know about the CTA and required reporting

The ‘Amazon of science stores’ and 30 other vendors strut their stuff for Philly biotech

Why the DOJ chose New Jersey for the Apple antitrust lawsuit

Technically Media