Explicitly Yours!

Kislay Verma
3 min readNov 10, 2018

I shared this note internally in Myntra in 2015 when I was working on some particular feature of their Order Management System (OMS). Sharing it now with internal details redacted.

I broke OMS yesterday. Didn’t think I would, but still did. And I am mad as hell about it.

tl;dr — Always be explicit about the inputs when exposing APIs, Relying implicitly on the caller or some other global condition is a horrible horrible idea.

OMS is a large project. We maintain the entire life cycle for Myntra’s orders, and shit ain’t easy. The challenge, however, is not in building the individual sub-parts, but in building the flow.

There are two ways to approach this. One is to build tightly coupled parts which only make sense as a whole. This approach chooses maintainability to the detriment of flexibility and reuse. Essentially, the whole can be implemented as a single piece (in the logical extreme, a sequence of method calls invoked from one place). The internal parts rely heavily on where they are located in the workflow and each part sets the context for its successors.

The other approach is to build an overall scaffolding and reusable pieces which can be plugged in as needed. This approach makes the reverse trade-off. While writing a component, we never know what is happening around us and so we have to code in an isolated manner. This means tremendous flexibility, but may mean that the overall flow isn’t optimized (Read from DB too many times, write to DB too many times to manage state…

--

--