The assumption is this:
Steemit, Inc. Knows What They're Doing
Are they going to implement your favorite feature? Maybe. Probably not, though. Are they going to do it perfectly? No. Are they going to try their very best? Yes and they have an incentive to do so.
Will Steemit, Inc. do anything it takes to go mainstream, even if it means abandoning early adopters? Yes.
You might say, "What? They can't do that! They can't abandon the early adopters!"
I didn't say they would abandon their early adopters. I'm saying that they are willing to if it means going mainstream.
Want to know what they're up to? Read on:
Quotes from The Mythical Man-Month by Frederick P. Brooks, Jr.:
The opportunity to be creative and inventive in implementation is not significantly diminished by working within a given external specification, and the order of creativity may even be enhanced by that discipline.
We don't get to look at the full specification before the developers. We can only jump to conclusions from the current iteration.
By documenting a design, the designer exposes himself to the criticisms of everyone, and he must be able to defend everything he writes. If the organizational structure is threatening in any way, nothing is going to be documented until it is completely defensible.
Yeah, the documentation sucks. Just suggesting such a thing is threatening. They're working on it, but that's what they're up against. It's normal.
It is more important that milestones be sharp-edged and unambiguous than that they be easily verifiable by the boss. Rarely will a man lie about milestone progress, if the milestone is so sharp that he can't deceive himself. But if the milestone is fuzzy, the boss often understands a different report from that which the man gives. To supplement Sophocles, no one enjoys bearing bad news, either, so it gets softened without any real intent to deceive.
We have a roadmap with some pretty sharp edges in terms of timeframe. Maybe it doesn't go where you want to go. Deal with it.
This does not mean there will be no course correction. The wonderful thing about having a roadmap is that if there is any course correction, we'll know where we were going and where we're going now.
The brain alone is intricate beyond mapping, powerful beyond imitation, rich in diversity, self-protecting, and self-renewing. The secret is that it is grown, not built. So it must be with our software systems.
This is why it's right to be excited about a new voting button animation. Small incremental changes will add up. This is not to say there cannot be large sweeping changes. But they will take the form of going from State A to State B, not right to State F like we users tend to prefer.
Organizations which design systems are constrained to produce systems which are copies of the communication structures of these organizations.
I'm just going to leave this quote to stand on its own.
An omelette, promised in two minutes, may appear to be progressing nicely. But when it has not set in two minutes, the customer has two choices—wait or eat it raw. Software customers have had the same choices. The cook has another choice; he can turn up the heat. The result is often an omelette nothing can save—burned in one part, raw in another.
Although I want Steemit, Inc. to stick to the timeframes set out in the roadmap, I also do not want them to just turn up the heat if there is any slippage. It's their call. They know what they're doing.
The general tendency is to over-design the second system, using all the ideas and frills that were cautiously sidetracked on the first one.
Lucky for us, the STEEM platform is the third of Larimer's systems. This means the frills that were added to the second system (BitShares) have been pulled back a bit and corrected.
Also see: To Be The Best In Crypto