Software Engineering With Separate Concerns
Building something new is hard work.
Often we imagine something we want, and confuse what we imagine with what we can build.
Mother Nature pushes back against these conceptualizations with constraints that were completely unaccounted for. This isn’t because the builders failed to notice something that they should have, it’s because we cannot foresee the future. Mother nature doesn’t fit into any plan.
So IRL, we must use an adaptive process to turn an idea into an actuality.
Engineers iteratively adapt their expectations to their observations. This is how we can account for the differences between what we want, and what reality has provided. Over time the concept becomes the reality.
BUT… for this to work we need a relatively clear concept to begin with, and this is where some thoughtful attention is called for at the planning stage. If we have a clear vision of the purpose of the thing we intend to build, then deviations between observations and expectations are unambiguous.
And how do we achieve this clarity of vision?
As far as I can tell, that’s a hard problem without a general answer.
So I rely on some heuristics. One of those is the strategy of “separating concerns”, if I want to build something to solve problem A, that’s a “separate concern” to a problem B solver.
That allows me to imagine, and reason about, the problem A solver in a way that deviates less from reality, than considering a Problem A&B Solver.
A Vision of a “Problem A” Solver
I want C++, and Go, to be eliminated from the core Zcash tech stack, in favor of Rust. For that to happen the functionality that’s currently implemented in those languages must be reimplemented. Almost all of that functionality exists in the “zcashd” codebase.
This is a clear single concern (which is not to say that the codebase in question is simple). The thing I want is:
Zcashd functionality reimplemented in Rust, such that all reliance on C++ is eliminated.
Notes:
(1) This problem is not defined relative to the Zcash Protocol Spec because that’s not running network-defining code.
(2) I won’t mention Go again because Zingoistas have already replaced it with Rust.
What Does this have to do with ZSAs?
I was surprised by @Dodger 's resignation, and frankly I am sad to think that I won’t benefit from his creativity and energy (in the near term, don’t be a stranger!).
Superficially @Dodger and I disagreed on the significance of ZSAs, but I have been gradually persuaded that ZSAs are in concept, as awesome (potentially) as their advocates claim.
That is where these threads weave together.
ZSAs are a separate concern to reimplementation of full nodes in Rust. They are a “Problem B”.
A full node reimplementation in Rust is itself a challenging project that requires a lot of work, by a lot of engineers.
The way for ZSAs (and everything else that depends on network upgrades) to become a reality, is to separate concerns, and replace Zcashd as is.
Once Zcashd is history, then ZSAs (and many other amazing new technologies, Scalable Payments, CrossLink, Nym-based network layer privacy, sender authenticated reply-to addresses, etc.) will be possible.
To get ZSAs ASAP we should:
(1) Define Zcashd deprecation as elimination of the current C++ implementation from the core Zcash protocol stack.
(2) Continue to work together across the core engineering teams to achieve that elimination.
(3) Do the necessary socialization to get the new implementation adopted.
That’s Problem A, any delay to solving that problem coming from any other concern, is running counter to the interests of our community.
Should we try to accelerate that by reallocating engineers?
No. Engineers are experts on the systems they’re focused on. They’re not fungible. Qedit engineers should keep hacking on ZSAs ( I am told there’re MANY features to implement ). CrossLink engineers should keep hacking on CrossLink.
That having been said, we’re all interested in Zebra proper and often we’re able to augment, and debug the parts of it that are closest to our own domains, so naturally we’re well-placed to both notice, and implement those components. That’s not a top down source of innovation, that’s bottom up.
What about the schedule?
I’m interested in actually eliminating the C++. How long that takes is not easily predicted, though it gets easier as we near completion.
I could wax poetic here, but I will just talk about how Zingoistas get paid.
We carefully plan out our projects with best guesses about how long it will take to build the thing we are imagining. We publish a schedule, a guess about when we’ll complete, to help coordinate with our partners.
Then we get to work!
Here’s the key bit, we then get paid, the only way anyone should be paid in Zcash engineering, for our results.
That means that when our schedule slips… we don’t get paid. It might not be sufficient to accelerate deprecation, but it’s the correct alignment of incentives.
If you want ZSAs ASAP and there’re teams that are getting paid for engineering work on salaries, then you want a reorganization.
I know there’s plenty of discussion around funding mechanisms elsewhere, this is me saying:
Cut the salary kruft, pay for results.
If there are Engineers who are getting paid salaries, then maybe we need a:
Department of Zcash Efficiency (DOZE)
So, while I am not advocating for anyone to shift which work they’re focused on, I am advocating for a migration away from salaried technical positions, which I think are better suited to “Pay On Delivery” structures.