Under-engineered

Typically, with software, you only hear about projects that are over-engineered. Too many features. Code is too fancy. High level of effort to solve a fairly simple problem.

What's not obvious from the outside is that (at a certain point) app complexity is inversely related to code complexity...

Let me explain. Adding another button, feature, or widget to your app is usually done because you've made a decision. You wrote some code and added the thing. For your users, too many things starts to look "over-engineered."

Choosing not to add features, and instead build a highly flexible system for future development is way harder. The app looks under-engineered from the outside (minimal features/decisions made), but the code usually explodes in complexity to handle this flexibility.

The weird thing is that blockchains are a fairly complex undertaking to begin with. So, when the Koinos Group decided to build the most flexible blockchain framework ever built, I would think that would make the effort nearly impossible. It turns out that a lot of the complexity of existing blockchains came from over-engineered decisions. Examples:

• Building Solidity and the EVM instead of using existing languages and WASM
• Building a hierarchical multisig authority model instead of letting users write their own authorizers
• Cramming all your functionality into the core blockchain instead of pushing those decisions out to smart contracts

The decisions made for Koinos are intentional and elegant. By under-engineering the Koinos framework (which took a lot of effort, don't get me wrong), they built a highly flexible framework where anyone can make whatever decisions they want.

​

-Luke

​

P.S. This flexibility required more effort in the short term, but it will pay off as the blockchain evolves with community demands and decisions in the future.