# DevEx Stories

Polkadot DevEx Perspective:

1. Cross-Chain communication -> addressed by XCM
2. Upgradeability -> DevEx + Storage Migration

-> How to make our products more usable for DevEx and why does it need the involvement of Core Engineering for the majority of these improvements (at least mid-term).

The overarching objective is to make the technology that we are building as usable as possible out of the box with as little as possibly needed interaction from "Parity". Most of them can only get tackled deeply in the architecture stack and therefore require the engagement from core engineering. However, we need to consider that not all of Substrate is used by builders, and a hybrid approach can be leveraged.

## Weights

How to make the weights configuration more user friendly?

While the weights configuration is usable already, with the appropriate knowledge and education, it seems to have room for a lot of improvements on the basic implementation.

*Solution Engineers:* Can educate DevEx to use and help configure weights in the right way.

*Core Engineers:* Can make the weight system itself more DevEx friendly.

__Comment:__

1. Even though there are available resources that explain the system (e.g. see below), the complexity of it makes it so that it needs to be tackled from root design.

> - https://docs.substrate.io/test/benchmark/
> - https://docs.substrate.io/reference/how-to-guides/weights/add-benchmarks/
> - https://docs.substrate.io/reference/how-to-guides/weights/calculate-fees/
> - https://docs.substrate.io/reference/how-to-guides/weights/use-custom-weights/
> - https://docs.substrate.io/reference/how-to-guides/weights/use-conditional-weights/

2. So while there are a lot of initiatives happening in regards to weights, they seem to be not consolidated or arranged collaboratively to solve it as a product.

__DevEx Responses:__
- As a developer I want to easily determine the weights I need to use in my pallets so that I can focus on the development of chain features rather than configuration.
- 25% of all issues identified by SRLabs on parachain reviews have been on weights.

__Bricked Live Chains:__
- Moonbeam
- Enjin

## Storage Migrations

Storage migration as a product vs as a tool. It can be used for teams to upgrade their products on the same level (parachain runtime upgrade) or to transition from a solochain into a parachain. Even potentially in the future, could be from a smart contract into a para{chain,thread}.

- Runtime/multiblock migrations
- [Centrifuge](https://medium.com/altair-network/altair-runtime-upgrade-2-a-post-mortem-618d8c3b12d8)
- Pallet indexing
- From a purely technical perspective, having array-indexed pallets is best, however it disturbs the DevEx experience. For a common developer it does not come naturally to think of it this way.
- SmartContract-2-Para
- needs strong thinking of a Polkadot product rather than a Substrate-SDK
- nobody has a clue about it,
- https://forum.parity.io/t/the-merge-ink-frame/1138
- *Solo-2-Para:*
- required the change of how the Substrate node itself behaves
- Parachains running AURA, Solo running BABE -> not compatible out of the box

## XCM

Key promise of Polkadot that's at a very complete feature and usable level. Now it's a good time to productise XCM by gathering and focusing on DevEx.

Productisation can happen at a FRAME level. Same as RPC API connects Core Infra with Runtime on Substrate, XCM could be think of as an API to connect a parachain's runtime to another parachain runtime.

Fast development can continue on the basic level, product can be built as a pallet sub-system.

## Out of Context:

Cumulus vs Substrate focus. Today, although we claim that parachains are built with Subtrate, reality is that they are using an implementation of Substrate called Cumulus. We should focus on developing Cumulus further as a product vs doubling down on Substrate in itself. **Every change that Substrate introduces should be to either improve Polkadot or improve Cumulus.**

- Is Parity building Substrate or Polkadot?
- If Polkadot, is Substrate the product or is it Cummulus?

While there are ways to utilize the support of support- and solution engineers for a lot of these issues, it will always only be reactive and never foster the out-of-the-box usage of products or 100% smooth DevEX.
On the other side, out-of-the-box usage of products have very often the need of changing the core-architecture to get the required improvements implemented.

As long as "Parity" or any related single entity is needed for the correct adoption of at product, it becomes it's bottle neck and stops it from being massively adopted.

## General Considerations

Different development scopes with their according goals:

- *Product Focus vs. Not-Product-Focus*

can relate to
- *DevEx Focus vs. Fast Iterations*


If Substrate is modular and Cumulus is a very specific implementation of it, couldn't different modules get developed under different development scopes!?!

It might lead to FRAME becoming more dedicated to DevEx scopes focused and Cumulus integrated, but would leave every other module the room to develop under the Fast Iterations scope.