A new approach towards immutability in smart contracts

Using PBT+I method will reduce dApp development cost and saves time

Current Web Development Process

The current web developers are comfortable with BMLF (Build-Measure-Learn-Feedback) loop. BMLF focuses on rapid development based model where you build an application, take it to market, learn on how customers are reacting to the application and then make changes accordingly. BMLF continues throughout the life-cycle of the product which makes it better.

Immutability

In the case of smart contract immutability kicks in which means the smart contract once pushed into the blockchain network cannot be changed in the future. If we have found out an error in smart contract and want to rectify the same, we have to make necessary changes and push the new contract to blockchain network as a separate contract which will have a separate address.

Dealing with smart contract needs a paradigm shift the way developer looks at programming. We have to follow the carpenter’s style of working: “Measure twice & cut once”. So the BMLF loop will not work for smart contract development.

PBT Loop + I

For better experience in smart contract development and to reduce the cost of development, I propose Plan, Build, Test loop + implementation.

As per this loop the team will have deep primary research about the preferences of the stake holders. Once they get an idea, an internal discussion has to be conducted where team members analyze the idea and design the structure of the application.

Now the developers start building the application. In each stage team has self evaluate the process and make sure they are on track. Also module wise testing has to be done.

When the whole application is completed, testing of the application has to be done considering all the possible scenarios that customers can go through. Testing has to be extensive as making changes to an application in blockchain is costly and tedious task.

Once the problems are found out team has to come together and find out a solution.

This process has to be continued until all the possible scenarios from the customer side are tested on the application and made sure that there are no errors.

Now we will go for implementation. Make sure that there is a transfer function where we can transfer all the information added to the application when we move from one version to another. Also there should be a kill function so that the older contracts can be destructed while changing the versions.

Originally published at https://www.wrefresh.in.