At Geojit in 2004, changing requirements kept sending me back to rebuild interfaces. I began wondering whether the next change could happen without another rebuild.

Repeated interface revisions give way to a configuration sheet connected to a reusable interface system.
If you’ve already decoded the illustration, you know where this is going. Here’s how I got there.

Every new request meant another rebuild.

One of the people whose requirements I handled was investor Porinju Veliyath, through Equity Intelligence. I would make a change. Another request would arrive. Then something else would change.

Requirements evolve once people see what they’ve asked for. That wasn’t unusual. But repeatedly making these changes was consuming time I needed for everything else.

The obvious solution was to get faster at making them. I started wondering whether I could stop making them.

What if the interface could change without rebuilding it?

I designed and implemented an approach that separated interface configuration from execution. XML described parts of what needed to appear. ActionScript interpreted that information and generated the interface.

Before
  1. New request
  2. Edit interface code
  3. Rebuild the interface
After
  1. New request
  2. Edit configuration
  3. Existing system generates the interface
The shift: describe what changes, let the existing system handle how it appears.

A change could become a configuration edit.

For the parts I made configurable, I could change what appeared by editing the XML, with the existing ActionScript generating the interface. Increasingly, the next revision meant a configuration edit rather than another rebuild.

This wasn’t a grand platform play. I was a young designer-programmer trying to claw back some time before the next revision cycle.

The same question followed me into leadership.

Years later at FYERS, designers were recreating familiar interface elements. Developers were translating those designs into patterns we had already implemented.

The technology and my role had changed. The question hadn’t: why are intelligent people repeatedly solving something we’ve already solved?

That thinking contributed to evolving the FYERS Design Style Guide into a governed component system connected to reusable production components.

I just wanted to stop rebuilding screens for the next request. Looking back, that became a habit: when work keeps repeating, I look for what needs to change in the system.

Read how this evolved at FYERS