Khan Engineering

Khan Engineering

We're the engineers behind Khan Academy. We're building a free, world-class education for anyone, anywhere.

Subscribe

Latest posts

Using static analysis in Python, JavaScript and more to make your system safer

Kevin Dangoor on July 26

Kotlin on the server at Khan Academy

Colin Fuller on June 28

The Original Serverless Architecture is Still Here

Kevin Dangoor on May 31

What do software architects at Khan Academy do?

Kevin Dangoor on May 14

New data pipeline management platform at Khan Academy

Ragini Gupta on April 30

Untangling our Python Code

Carter J. Bastian on April 16

Slicker: A Tool for Moving Things in Python

Ben Kraft on April 2

The Great Python Refactor of 2017 And Also 2018

Craig Silverstein on March 19

Working Remotely

Scott Grant on Oct 2, 2017

Tips for giving your first code reviews

Hannah Blumberg on Sep 18, 2017

Let's Reduce! A Gentle Introduction to Javascript's Reduce Method

Josh Comeau on Jul 10, 2017

Creating Query Components with Apollo

Brian Genisio on Jun 12, 2017

Migrating to a Mobile Monorepo for React Native

Jared Forsyth on May 29, 2017

Memcached-Backed Content Infrastructure

Ben Kraft on May 15, 2017

Profiling App Engine Memcached

Ben Kraft on May 1, 2017

App Engine Flex Language Shootout

Amos Latteier on Apr 17, 2017

What's New in OSS at Khan Academy

Brian Genisio on Apr 3, 2017

Automating App Store Screenshots

Bryan Clark on Mar 27, 2017

It's Okay to Break Things: Reflections on Khan Academy's Healthy Hackathon

Kimerie Green on Mar 6, 2017

Interning at Khan Academy: from student to intern

Shadaj Laddad on Dec 12, 2016

Prototyping with Framer

Nick Breen on Oct 3, 2016

Evolving our content infrastructure

William Chargin on Sep 19, 2016

Building a Really, Really Small Android App

Charlie Marsh on Aug 22, 2016

A Case for Time Tracking: Data Driven Time-Management

Oliver Northwood on Aug 8, 2016

Time Management at Khan Academy

Several Authors on Jul 25, 2016

Hackathons Can Be Healthy

Tom Yedwab on Jul 11, 2016

Ensuring transaction-safety in Google App Engine

Craig Silverstein on Jun 27, 2016

The User Write Lock: an Alternative to Transactions for Google App Engine

Craig Silverstein on Jun 20, 2016

Khan Academy's Engineering Principles

Ben Kamens on Jun 6, 2016

Minimizing the length of regular expressions, in practice

Craig Silverstein on May 23, 2016

Introducing SwiftTweaks

Bryan Clark on May 9, 2016

The Autonomous Dumbledore

Evy Kassirer on Apr 25, 2016

Engineering career development at Khan Academy

Ben Eater on Apr 11, 2016

Inline CSS at Khan Academy: Aphrodite

Jamie Wong on Mar 29, 2016

Starting Android at Khan Academy

Ben Komalo on Feb 29, 2016

Automating Highly Similar Translations

Kevin Barabash on Feb 15, 2016

The weekly snippet-server: open-sourced

Craig Silverstein on Feb 1, 2016

Stories from our latest intern class

2015 Interns on Dec 21, 2015

Kanbanning the LearnStorm Dev Process

Kevin Dangoor on Dec 7, 2015

Forgo JS packaging? Not so fast

Craig Silverstein on Nov 23, 2015

Switching to Slack

Benjamin Pollack on Nov 9, 2015

Receiving feedback as an intern at Khan Academy

David Wang on Oct 26, 2015

Schrödinger's deploys no more: how we update translations

Chelsea Voss on Oct 12, 2015

i18nize-templates: Internationalization After the Fact

Craig Silverstein on Sep 28, 2015

Making thumbnails fast

William Chargin on Sep 14, 2015

Copy-pasting more than just text

Sam Lau on Aug 31, 2015

No cheating allowed!!

Phillip Lemons on Aug 17, 2015

Fun with slope fields, css and react

Marcos Ojeda on Aug 5, 2015

Khan Academy: a new employee's primer

Riley Shaw on Jul 20, 2015

How wooden puzzles can destroy dev teams

John Sullivan on Jul 6, 2015

Babel in Khan Academy's i18n Toolchain

Kevin Barabash on Jun 22, 2015

tota11y - an accessibility visualization toolkit

Jordan Scales on Jun 8, 2015

Meta

What do software architects at Khan Academy do?

by Kevin Dangoor on May 14

“Architect” is a new role in Khan Academy’s engineering team this year, and my colleague, John, and I have stepped into this role. John has been with Khan for seven years now, mostly focused on frontend development. I’ve just reached three years here, having spent time in frontend development and engineering management. There are many possible paths to this role, and I’ve seen quite a few definitions of it, so I thought I’d share our view of being an architect.

The role of an architect

The Wikipedia article about software architects leads with this:

A software architect is a software expert who makes high-level design choices and dictates technical standards, including software coding standards, tools, and platforms.

My view is a subtle shift from that one: an architect acts as a sort of product manager for the system in which software is built. This “system” consists of the coding standards, tools, platforms, and even processes used by the engineers on the team to build features for their users. Architects look for ways in which the system can better serve the engineers.

The Wikipedia definition describes the architect as “making” the design choices and “dictating” the standards. For me, that evokes images of an architect handing a scroll to a messenger who then walks among the engineers declaring, “On this, the 14th of May, 2018, we hereby decree that all files shall use four spaces for indentation.”

As a product manager for the system, I look out for ways to make things better and then work with the engineers and engineering management to make the changes come to fruition. It’s a lot more collaboration than it is dictation.

That’s enough vague, high-level talk. Let’s talk about things that actually consume time in my day.

We guide architecture change

Though I was joking about the Great Indentation Decree of May 2018, we do need coding standards to help engineers make sense of our system. If you’ve ever been part of a protracted technical argument, you know that these can sometimes be draining and not a productive use of time.

At Khan Academy, we’ve adopted DACI as a decision-making framework. DACI stands for Driver, Approver(s), Contributors, Informed and specifies the roles involved in making a decision. The architects and other engineering leaders act as the “approvers” on architecture changes. You could interpret that as “the architects make the decision,” which makes this process sound like the “dictating change” approach from Wikipedia, but that’s not how DACI works.

In DACI, the Driver makes sure that the change has the right contributors involved and the Approvers “own” the decision, ensuring that concerns have been accounted for. Are there potential security implications to the change? If so, we’ll make sure our security lead is a contributor.

The Driver and Contributors together work out the details of the change and, ideally, the actual decision is self-evident by the end of their work. As the approvers in those cases, architects and other engineering leaders make sure that all of the questions have been resolved.

In the cases in which there are two choices, we have to pick one, and the differences between the two are minor, the approver will indeed make the choice. This wasn’t necessary in the vast majority of cases we’ve seen so far.

Every architecture change we make goes into a decision log so that future-us can understand why our system works the way it does, making it easier to understand when it should change again.

This process is intentionally designed to be lightweight, so that we can move quickly and efficiently. A simple, uncontroversial change can be written up and approved in a day.

What kinds of changes have we made this way? A few recent examples:

  • We’ve adopted rules for how we would deprecate public API endpoints
  • We’ve created standards for React components that we use site-wide
  • We have a second language (Kotlin) that is an acceptable choice for building services

Being a part of all of these changes helps architects maintain a broad view of work that’s happening in our system, which helps us guide further changes to it.

Architects help our guilds

Khan Academy’s teams are built around product areas, so we’ve established guilds that look out for our technology across the product areas. We have four guilds currently: web frontend, backend, mobile, and data engineering.

Guilds have the ability to influence how a portion of our development time is used, for things like breaking apart our Python code or creating a wholly new set of UI components. John and I help organize the guild work for the frontend and backend guilds, respectively.

Communication

Architects spend a lot of time on communication tasks to help everyone stay in sync about the current state of our system and how it’s evolving. Architecture diagrams, roadmaps, project plans, this blog, a newsletter of relevant technology stories, and meetings are all pieces of what we do as architects.

The newsletter (see below) helps ensure that everyone in engineering has seen some stories about how technology that affects us is changing.

Signal Boost newsletter

The diagrams, which we’re creating in part following the C4 model, are a useful tool for communicating about our system. I’ve been working on a proposal for a change to our system and I was able to take pieces out of our diagrams and create new ones that made the step-by-step progression in the proposal much clearer.

Sample c4 architecture diagram

Code

Architects are programmers and John and I both exercise those skills as part of the job.

Managers and architects

Architects aren’t typically people managers, and that is the case for both John and me. When it comes to our development process and how projects are going, our managers take the lead. Technical leadership within engineering is shared by architects and managers, with managers taking more responsibility for delivery of the product (the “what”) and architects focusing more on the state of the architecture (the “how”).

I spend time each week talking with an engineer on the team to find out how things are working for them. That helps me get a view across the organization of how the system is working, and a cross-cutting perspective I can share with managers when there are things we can improve.

PMs for the system

I’m fond of the “product manager for the system” definition of software architect. The users of the system are our software engineers, QA, and others who are ultimately working to deliver features for learners, teachers and coaches who use Khan Academy, and we want to help that system deliver better and faster.

Thanks to Marta Kosarchyn, David Flanagan, Scott Grant, and John Resig for their feedback on this post.