Blockchain and other decentralised technologies allow very exciting new possibilities for the value that software and digital products can offer to the users. To achieve this value, the way we design and architect of new applications that use these types of technologies has to change as well. Agile software philosophy has arguably changed the way most teams handle innovation and product development, however the use of decentralised technologies requires us to step back and rethink some of these methodologies.

This blog will outline how we at Indorse are approaching innovation and technical progress, and how the use of decentralised technology as part of our stack has required us to make different considerations and strategies.

So what’s the problem?

Agile development insists on feedback from users to feed innovation. We have just pulled the image to the left to show how this cycle may typically go.

It also strongly highlights the necessity to continually iterate on the product. It is this part of the process that can create issues for blockchain products.

Generally, blockchains are immutable. That means that the state of the blockchain, once set by a processed transaction, can never be changed. This is of course part of the security model. How else could we trust a new token in an ICO not to disappear forever? Ethereum smart contracts are probably the most familiar example of systems where upgradeability of contracts after deployment is not possible and thus designers must be absolutely sure that the contract will work forever.

Batman thinking about agile blockchain development

Bummer, this goes against our idea that we want to change things in response to how our users like what we build.

And don’t even get me started on upgrading because there are bugs. This is so obvious that I’m not going to address this in this blog. If you are interested in upgradeablitiy for bugs, see my blog here.

There are systems out there, permissioned and private decentralised technologies, that ease this detail — we won’t go into details here. However, at the end of the day iterating on your application is made far more difficult with decentralised applications compared with centralised ones, period!

To give you some examples within our Indorse stack:

We are currently running a Bigchain cluster which holds user data. There are loads of challenges here, but going with the decision to use Bigchain exclusively (we also keep data in a mongo database) and hand over user asset control to users raises hairs on all our necks: what if there are good reasons to update all our users’ data — well, we can’t! It is of course our plan to do this, and Bigchain is not ready yet anyways, but when we do change this over, we will have to triple check our double checks before we go ahead. If interested, please see our blog with some more details about these challenges.

We just deployed a simple yet powerful smart contract on the mainnet, the Connections contract, that is powering better trust between companies and advisers on the Indorse platform. However this wee contract of ~400 lines took us through a very large testing, auditing and deployment phase, and that is not even to mention all the extra work required to get it to work with our application. All that done to ensure that the contract, once deployed, is correct — because we can’t change it.

Some of our users may have started to notice that we are starting to allow a plethora of different sign-in options — uPort login is in our pipeline as well! The rationale behind this is to try to give users more decentralised login options, but the development of platforms like Civic, AirBitz and uPort is a technical dependency that we are still largely waiting on.

So what are we doing about this at Indorse?

Firstly, we are slowing things down when it comes to decentralised technology. This seems to be what most blockchain companies seem to be doing in the space. Our technology stack goes ahead as fast as it can, but we have to constantly be asking ourselves how this will fit into our architecture in 2, 5, 10 years — not an easy thing to do when, for example, Ethereum has only released a version 1 software.

We have split up into several development units and each unit goes ahead with different features — some working on exclusively-decentralised tech and some on hybrid systems. Making irreversible decisions happens with the knowledge of all of the decentralised technology engineers and most of the business team in the loop. We have a weekly decentralised meeting where any decentralise work is put on the table to make sure all engineers can see the whole picture of what is going on.

Lastly, we are starting to look into ways to create a more agile process by researching and implementing upgradeable technologies. I have been very directly involved in this recently and you can see a summary of our most recent R&D here. We want to go faster than we currently are, and certainly faster than anyone else, while still maintaining trust with our users. We will be going ahead and starting to try out the fruits of our labour and accelerate our development process while maintains trust with our users.

In summary

We hope you have enjoyed this insight into the innovation process and thinking at Indorse. We hope that some of these philosophies can be considered by other teams and used to better adapt decentralised technologies to the ever-changing world environment, in part through the use of upgradeable systems.

Please comment or reach out with any experiences, insights, agreements or disagreements you have 😁😁😁!