The hierarchy of need in system design
In discussion of the early voting penalty change in HF20, an attitude I'm seeing over and over is: our first priority is stopping people from exploiting this bug. This post is my attempt to explain why that's a terrible plan.
When we're designing a system, it's important to have our priorities straight and constantly in mind. This is why some of us have mission statements, to make sure that we don't narrow down so far onto a perceived problem that we stop taking the whole system into account, and make decisions with ill-considered side effects. In particular we have to know what actions are most important to the success of our system as a whole in order to make good decisions about each individual piece.
In any growing system, there's a strict hierarchy for what's important on a basic level:
- Encourage and reward new users.
- Encourage and reward desirable behaviors.
- Discourage and punish undesirable behaviors.
(In a system focused on retention #1 and #2 can flip, but #3 only ever moves up if you're actively averse to new users.)
If you treat those three priorities as if they were progress bars, anything that moves a progress bar up but moves the ones above it down is a bad idea and you should come up with something better. Of course, if you treat those priorities as progress bars, the first one on Steem is so far in the negative that you'd need a second monitor to see it all. The reason for this is Steem's design priorities look like this:
- Discourage and punish undesirable behaviors.
- That's it.
We can see this in the way @steemitblog reports the best change in HF20, Voting Mana. Voting Mana is amazing: it makes delegation work more smoothly and more intuitively, it allows you to get your new voting power immediately when powering up, it knocks off a few small exploits at the same time, and as a bonus it allowed them to cut the delegation cooldown time by at least 28%. It's a clear win on all three levels, it makes the whole SP system better and friendlier for everyone, it's just generally excellent. How did they pitch it to us?
Users reported two exploits: (issue 2428 and issue 2539), where an account could gain extra voting power by using up all of their voting power, and then delegating their SP to another account, or powering down and powering up again into another account.
We are including fixes for these exploits as part of Hardfork 20.
(These are also highly technical, so feel free to skip over if you’re not interested.)
Not only do you basically have to be a complete nerd about these changes to have any idea how great it is, they specifically tell you you don't have to think about that part. They reinforce this at the end of the section:
This will not negatively impact the user experience: it is a technical change designed to specifically address the double voting exploit.
They've made a clear and strict improvement to the system for everybody, and their pitch for it is this will not negatively impact the user experience. They ought to be saying This is pure awesomesauce, what a marvel of system design, let us celebrate it! I am not a fan of self-congratulation but Voting Mana deserves it. Instead they downplay the whole thing and tell you you shouldn't care, because this is all about stopping the exploits.
Voting Mana should be the shining example of how to redesign how the system works, the standard to which we hold all other proposals.
We need a change in attitude.
Priorities on Steem need to be re-focused on making the system attractive to new users and continually compelling to existing users. The early voting penalty change in HF20 is just one terrible example of what happens when we don't do that. It's so bad we can't even document how the voting system will work after the change in a way that is coherent and appealing to new users. That's why Steemit has been so bad at communicating it that I've had to explain how it's really going to work to several witnesses now. Approaching it from a historical perspective doesn't work so well either:
The last sentence in that paragraph might as well be "Buy EOS." This isn't how an appealing system is built. We can do better, and we should.
It starts by always, always, always thinking about the experience of new users first. Because growth is the key to a viable Steem in the future.
New users can’t even sign up in any meaningful way. As a design philosophy it’s so far off the mark to make everything else irrelevant.
There's a plan to change this in HF20 as well, but it's maddeningly short on details.
I'm biased of course, but personaly I still feel the solution I presented when reporting issue 2539 still seems more elegant than the voting mana cludge they came up with, and its concequences would have been even more friendly to non-abusers.
In short, the elegant solution would be to define STEEM equal to SP at 100% VS and to always preserve the sum of products of SP and VP in attomic transactions involving one or more accounts.
I understand there might be practical issues in implementing this and Voting Mana might be the only currently viable alternative, but again it remains a mainly defensive solution that punishes (be it less) those not set out to cheat the system.
An atomic Constant Sum Of Products (CSOP) solution would for example actually allow for reducing the delegation return period to zero instead of five days.
Don't get me wrong, the Voting Mana solution is still a huge improvement, sure, but the fact they chose it over a CSOP solution in my mind shows a duct-tape rather than an architectural approach to the fundamental issues.
I'dd love to hear your views on Voting Mana vs CSOP, and I'dd love to learn reasons why Voting Mana would in any way be better (other than the fact that the name of the solution is kinda cool).
I agree that full atomic would be best but I don't think there's any reason you couldn't do that in Voting Mana. I'm not sure what specifically they've implemented, but it seems like even if they've just gone halfway on that it sets up a framework to go to the full atomic solution fairly easily. Whereas getting there from the current system basically involves rebuilding everything.
It also provides a framework to eventually allow users a choice of how much VM to move within a delegation, which I don't think a basic implementation of full atomic would do.
To listen to the audio version of this article click on the play image.
Brought to you by @tts. If you find it useful please consider upvoting this reply.
As always expected from you- a top quality post. Thanks.
Thankfully someone gets it. I always appreciate your insight into the inner workings of steemit because it is definitely not my strong suit.
Steemit needs a PR person.
Thank you tcpolymath your helpful opinion.
Well done bro
I can relate to what you are writing here.
But you know, there are also new steemians who are only around for short time and really just want to spam others.
New comers think of fast money.
New steemians who realy makes an effort to write from sratch but no one notice.
For those who can afford to buy bots, they seems to be more on top feed.
Don’t you think after all its a business?
I have been her 105 days. I try writing and posting every single day and interact with others too.
I am one of those you were talking about. No one notice anymore new or not. Great content or not.
If we do not invest buying upvote from bidbots- we never can make it.😭
You got a 29.17% upvote from @ocdb courtesy of @tcpolymath!
@resteemator is a new bot casting votes for its followers. Follow @resteemator and vote this comment to increase your chance to be voted in the future!