Skip to main content

Development Phasing

Previously our SDK development followed a very waterfall-like approach for the design and implementation of new APIs with a time-consuming design process that spanned across multiple languages and platforms in parallel. This typically meant that:

  • Design gaps and "gotchas" would be discovered by individual engineers at different times, resulting in increased development cost and time and overruns.
  • APIs would diverge between companion SDKs, resulting in parity differences which would be difficult for customers to consume, or for internal writing teams to document.
  • APIs would not be "Language-First", resulting in all SDKs feeling out of place by users of those languages.

To address these concerns, our new approach for SDK development is as follows:

  1. An initial spike will be performed to identify requirements and limitations, and to design a very rough outline of a proposed API, which can be reviewed by the SDK development team and its stakeholders.
  2. A single platform / language "trailblazer" will be chosen to develop the initial version of the feature, end-to-end. Any gaps or "gotchas" discovered in this process will be communicated to other SDK developers. The resulting implementation will be reviewed by other SDK developers to provide design insights, and to iterate on the API to ensure it aligns architecturally with other languages.
  3. Development begins on additional languages/platforms based on the new and revised design.
  4. Incremental lessons learned from the development in the new platforms will be rolled into the design for the first SDK, to ensure alignment with any architectural changes made.