The Mindset From Divi Early Days to Divi 3.0

‍

When I arrived at DiviLabs, the state of the core codebase can be summarized simply as significantly disorganized.

While that to most people may seem silly, the job of a good software developer is to weave computer action out of logical intent. A disorganized codebase, like a tangled ball of multi-colored yarns, means you cannot safely take action till you untangle each thread individually and re-wrap it into its own yarn.  This is especially true for blockchains which are immutable. This was a significant effort and the focus of my first year there.

It's important to note that decentralized, and more generally open source projects, would naturally tend to experience this kind of disorganization mainly due to the fact that each developer contributes their own thread of logical intent. Like anyone who's dealt with a clump of wires knows: those will eventually tangle unless measures are taken up front or continual monitoring is undergone. 

‍

Moreover, as originally Bitcoin was built out as a proof of concept, it was not built out with all the standards of high quality that common software projects experience: it was only built to prove out that Bitcoin - the idea - could work in practice. It's important to call out that upgrading an implementation from a 'draft' to a full-fledged product is a significant investment of time and energy, and particularly hard if the goal is to remain absolutely or maximally backward compatible.

‍

As most other Bitcoin projects just forked the Bitcoin codebase without paying attention to this detail, they also inherited the same quality issues and in (seemingly) most cases, didn’t try to fix them. This was probably done to allow them to reuse the Bitcoin core developers’ work (i.e., import changes from the Bitcoin core and add them to the given project; after all, it’s permissionless). Simply taking what they needed and building on top of it. Easy!

‍

‍

Of course not all projects forked from Bitcoin, others just repeated its "mistakes": let's create a prototype and if it succeeds we will fix it as we go. 'Move fast and break things' is a bit of a naive software development strategy. Moving fast can often be a cost to the development speed of others - it’s like a leveraged bet against your team mates’ competence. 

‍

The quote "Society prospers when old men plant trees, the shade of which they will never sit under" applies to code very strongly. You MUST always leave it better than you found it.

My goal was to have even a novice developer be able to understand the flow of the code, by organizing it better and restructuring it to convey the behavior of the code. This is critical in order to quickly adapt to changes in a safe fashion. In short: Maximize clarity, Maximize Transparency, Maximize Adaptability.

‍

During my journey to 3.0, as the messy threads became detangled I was able to more clearly see how the overall system worked. In doing so I was able to better understand how it could adapt and how it could not.

‍

‍

The first discovery in this process was the changes needed to support mobile masternodes (<5s node deployment). It was an obvious change, but one that could not be seen under the mess. 

‍

‍

A second discovery came to me while I was always thinking about individuals who spent their hard earned time and money to purchase Divi. In particular I was worried about the fact that we only had hot-staking at the time. In my mind this was a risk, and why masternodes (at the time) were a safer bet. In order to support decentralization, staking needed to be made safer.  The direct result was the development of staking vaults (i.e. cold staking on a node). This too was another relatively easy change that was simply hard to envision originally.

‍

RandomString42

‍