As Jet V2 has recently gone live on mainnet, the Jet core development team wanted to check in with the community here and offer some retrospective lessons learned from the previous year both working on V1 and V2.
Thinking through some common questions asked on Discord, Twitter, the forum and one on one, we’ve shared the current format of A (what’s the issue) and B (what we are doing about it). If you have any questions that were not addressed here please feel free to follow up here in the thread.
A. The releases that were planned were overly broad, with too many features jammed in. Due to product vision being too “complete”, this translated into excessively long product cycles. Trying to create innovative DeFi apps on the edge of what’s possible will continue to have unexpected challenges and the longer the cycles, the more these issues tend to compound.
B. We have subdivided future releases into smaller “product atoms.” This should result in more nimble, faster product cycles. For example, margin swaps (as opposed the full margin trading dapp) or post-only bond order books (as opposed to a full bonds platform release right out of the gate) are ways we are tackling this issue.
A. Teams were isolated in their particular domains of the stack, passing problems back and forth, fostering communications issues.
B. By creating smaller, more focused teams that work across domains (frontend, integration, protocol, data) to deliver a smaller and quicker release, we can have smaller teams focused on the full stack of a deliverable product atom. This reduces knowledge silos and bubbles up issues more quickly for faster solutions.
A. To date, our QA processes were quite manual.
B. We have adopted an end to end framework to test consistently and in real time such that if something breaks, we hear about it from our testing system first.
A. Integration of the UI and backend was left until the last stage, but often required modifications to backend and frontend components, causing delays.
B. Similar to other issues, we are solving this by having smaller, more focused teams connecting the pieces from the start. Through this continuous development style the teams are able to match their work more consistently with less surprises in a vacuum.
A. We were making extensive and excessive improvements to releases, which dragged out timelines. Basically what amounted to scope creep.
B. Now we commit to delivering product atoms as specified, which can later be refined. Understanding it’s better to get the work out and then get feedback on it, we can enable greater interaction with the community of users which is powerful from a product development perspective.