Why there is no ETA on eCash’s technological upgrades
Yes, waiting can be frustrating…
Just think of the uneasy feeling you had, when you were waiting for the bus and it did not arrive at planned schedule. Every added minute felt much longer than usual. Or maybe you waited for a friend you wanted to meet at a specific time and space downtown; What’s worse is when you’re left with no further details on the issue: Maybe the bus was actually a bit too early and you just missed it?
Even if you receive the notification of delay, most of the time it comes right after the appointed time of arrival. Everyone experienced this when they got a message on their phone 2 minutes in waiting for another party: “Sorry, I will be 20 minutes late”, let alone the fact it won’t be 20 minutes, but most likely going to be 40minutes, at least. A complete waste of your time and stress-test of your patience. Many people I met would even call it disrespectful.
It is no different in the crypto-space or any technologically challenging project for that matter. Forget the daytraders who are used to reacting to 5 minute charts or the investors, who are patiently awaiting some news about the long awaited technological upgrade in the hopes to see their portfolio appreciate.
Anyone - developers, marketers up to the biggest supporters of the project, they all feel disheartened when they get the feeling of waiting in a certain darkness on what, how or when a feature or upgrade will finally arrive.
How nice it would be if the developer team simply gives us a date. It can’t be that hard, right? Are they actually just making empty promises? Are they too perfectionist to ever take the lead and just go live? Or do they just add up useless tasks so they can pretend to work on stuff, only to justify being paid?
Many of these questions — or accusations, rather— were made already.
Not only regarding the development of eCash infrastructure; I see it since the day I joined the crypto-space actively in forums and chats. In fact, I see such claims and questions in most projects far before cryptocurrencies even existed. The best example I keep referring to are multiplayer-games, which are often highly community driven in many aspects, bringing in useful communication and contributions from the user base but also creating a higher sense of entitlement of “what should be done”.
Be it a new feature, an age old obnoxious bug that seems trivial to fix, a new game rule, a “nerf” or “buff” of an over- or underpowered in-game item. Whatever it is, it ultimately results in the user base being frustrated and sometimes even at war with each other about the development and to the detriment of the entire project, this negativity takes up the entire energy and attention, making it even harder and demotivating for everyone involved.
Ethereum case in point:
We just heard about Ethereum’s delayed merge, despite its successful ‘Shadow Fork’ test. And this is just one of a collection of many. The picture below shows comments on the last delay, years ago.
Now, I am not here to point fingers at Ethereum not meeting their deadline, nor do I want to call out any of the users for being “entitled”. Yet, I want to say that it looks to me as if everything is still going “as planned”, even though estimated time of arrival was not met. The part everyone is missing is, that they were successful (or at least claim so) in implementing what they wanted to implement, which is actually something to celebrate, even if there is still more work to do. But only if you have internalized what I am trying to tell you, that is.
That’s why I want to share a few points that I think anyone of us has to internalize, before getting impatient with the team. You know, those few people who are actively keeping this chain alive and having the expertise and sole oversight of what is actually happening at the infrastructure level and why things are how they are.
My own experience with suggestions made to Bitcoin ABC
Years ago, just as many other users in the community, I was thinking to be really helpful telling ABC members to ensure their needed funding by creating a simple document and listing plus billing of all the items they are working or want to be working on in the future.
A few weeks after that, I read an article by a developer of another node software, who took the time to make things much clearer to me. I realized that I should rather start to learn, before trying to teach others and meddling in affairs I have zero experience in.
In hindsight, it’s pretty obvious, but this is just another part of what I mean, when I talk about “the sense of entitlement” in a space. It is so common that it needs to be explicitly addressed for people to get it, especially those, who have the least experience in these affairs. Here is an excerpt of Chris Pacia’s article, lead dev of BCHD node software, which made me understand I needed to change my entire perspective on “what should be done”:
It seems like many people are under the impression that software is just “write once and forget”. Software is rarely ever “done” in any meaningful sense. Instead it requires continual, on-going maintenance to keep functioning. For a large, complex codebase like full node software this includes bug triage and fixing, refactoring, optimizations, improving test coverage, paying down technical debt, backporting, code review, and documentation. Code review usually being the biggest bottleneck. Especially in a codebase where if you fat finger one line of code you can blow up the whole system.
This generally isn’t the type of work you create an itemized list and bill for. For example, bugs come up all the time that are unexpected and not planned for. Libraries you are using publish new versions that require updating, often necessitating changes to the code to conform to a new interface. If you set out to improve test coverage you may end up finding that several modules need to be refactored before you can even begin to write more tests, etc, etc etc.
In a thread on Reddit one user wrote that for every $1 in development a company usually spends $4 in maintenance. Not sure how accurate that is, but you get the general point.
While this article was written in a time where development funding was the burning issue for Bitcoin ABC, this excerpt still timelessly encapsulates the response to today’s question about ETAs and why they are almost impossible to create.
Maintenance
At this point I would say that whatever estimation you make, it is nothing more than a shot in the dark. While you might know how the feature you want to implement will look like, you simply cannot know as to how many and what size of hurdles you will face down the line while implementing those.
As Pacia writes, most of the work being done just keeps adding up maintenance issues and quick fixes that happen with every module you integrate and new tasks keep being added, regardless of what you integrate, just by dependencies on other software-libraries.
Imagine building a bridge, which is also connected to other, external infrastructure. Even if you’ve built one half of the bridge already, you still need material, resources and manpower to keep that “done” part of the structure in tact, all while keeping the work on the other half that still needs to be engineered as well as doing reworks on all the external endpoints that occasionally keep shifting.
Prototyping vs. Production
We are not talking about an ETA on a marketing event, which can be pinpointed to a specific day. Or even regarding software, there is not just a hyped up front-end feature, such as adding support for a swap-exchange on top of a smart chain, or “enabling staking” for your favorite Meme-Token that doesn’t even have its own infrastructure but is based and implemented on one of the common smart chains. Granted, this may be a big deal for you and everyone else, trying to sell the hype, but it is simply not a big deal to implement from a technical perspective. Let alone solving the problems Bitcoin was created to solve in the first place.
An infrastructure upgrade like Avalanche on the eCash chain is nothing like this. You don’t have templates or documented API’s to simply connect to and go through a few tasks step by step, repeating what has been laid out for you by other — mostly corporate backed — projects and produced one thousand times already. You are building a prototype. A completely new thing on a self funded, decentralized open source technology with a team that you wish would be about three times as large as it is right now. Yes, it’s pretty much rocket science: Failure, setbacks, high stakes, new challenges, unintended consequences and delays are simply part of the deal.
A change in Mindset
Maybe calling it “rocket science” is a bit of a stretch in a technical sense.
I myself just say this tongue-in-cheek and I am certainly not a scientist or have any technical expertise to be able to make that claim, but I am willing to lean out the window here and make this bold statement. I want to take the opportunity and reach out to you and try to make clear, that we need to be patient and we need to change our focus from “why isn’t it ready, yet!?”, to maybe something more like “how far are we in?” or “what does it improve?”, “how is it better?”, “which problem does it solve?”.
We can contribute engagement and interest understanding and advertising the technology and how these implementation set eCash apart from so many other chains in this space. There are many more questions to ask that would also motivate the team much more to work harder or might even drive in new skilled developers and engineers, who ultimately help speeding up the complex infrastructure work.
No ETA might be bitter, but broken promises hurt the most
That’s why I actually support the ABC team fully in not giving out any ETA on this. Mind you, we have actually do have a solid road-map showing a list of what needs to be done to scale into a competitive global p2pcash-system:
e.cash/roadmap-explained
And we also have a detailed list on all the needed items that will be implemented on Avalanche one by one:
avalanche.cash
This is already a lot of outreach towards the community from the developers, who are hard at work, even if you don’t hear much from them. Let us appreciate their work and show more interest towards what genuinely awesome technology actually is being implemented with an outlook in the long term and less entitlement for something that creates an impact only in the short-term. This is what most other projects do. Our project in terms of technology, outlook and culture has set itself apart from most other chains, you should know this.
That is not to say that there is nothing to be done to generate excitement and fun that will gather attention in the short-term. We also have an eCashArmy. We also are happy to generate fun activities and make some noise as we go. We also do outreach, marketing and partnerships, whenever we see potential for impact. And we do so without losing sight of our mission and without wasting resources.
Don’t chase the Hype
So, maybe instead of trying to generate a cheap and short lived sense of FOMO through hype and empty promises which leads to entitlement and in the worst case to complete failure to meet resulting expectations, we could find ways to come up with strategies that enables incorporating a culture of excellence, knowledge, gratitude and long-term forward thinking, still managing to give people a sense of urgency to check out eCash, accumulate and contribute, resulting in appreciation of the project on any levels, short- term included, without compromising on the long-term goals or crucial principles.
Here’s a link to Chris Pacia’s article I’ve taken the quote from
And If you’re interested in watching the eCash rocket being built layer by layer by the developer team, check out the Bitcoin ABC commits on github.
Thank you for reading and considering,
-Kousha