John, I 100% agree with your statements!
We should add that to the list as well...
On 11/28/18 11:54, John Blum wrote:
1 more thing...
Yes, CORRECTNESS is not going to be the glamorous thing. You cannot market
it because it is not sexy, not cool, it is simply expected as the bar to
entry. No one notices when the system just works as it should. You will
not get compliments, no thank you's. It's just "Business As Usual". Of
course, look out things don't work! You'll hear about those, even when it
is not your problem. Anticipation is key, but not at the expense of over
engineering the problem. It's fine balance and art to be learned.
Performance is one where its fast one day but slow the next. Correctness
does not take a day off.
If you can only optimize for 1 thing, opt to be correct. Users will
silently be thanking you, especially during the holidays when they don't
have to worry about keeping the lights on at work.
+ $0.02 more,
-John
On Wed, Nov 28, 2018 at 11:42 AM John Blum <jb...@pivotal.io> wrote:
There is only 1 thing I would add to this list is, above all others...
1. Correctness
Of course, this ought to go without saying, but do the right thing,
always, even at the peril of all the other things combined. It is all too
easy to focus on the shinny things (e.g. performance, latency, high
concurrency), which have external factors (e.g. hardware failures, network
issues, resource limitations) beyond the control of the system itself.
Correctness has no external factors, especially if the system is designed
with resiliency/recovery in mind. When in doubt, do the simplest thing,
less is more, write a test. If it is hard to test, it is probably wrong,
poorly designed, or both. I cannot count how many times I have been proven
wrong simply by writing 1 more test. If you think it can happen, it will!
Finally, by way of example, I want to pick on "performance". Ooh! Ah!
Shinny! I hate nothing more than premature optimization. Unfortunately,
performance might have the most external factors out of any of the above
things and if you are not correct, then it really does not matter how fast
you go if you are going in the wrong direction/doing the wrong thing
faster. You are just magnifying the problem. Also don't confuse
consistency with correctness. You can be consistently incorrect, too.
There are many instances where features/functions are NOT doing the right
thing.
$0.02,
-John
On Wed, Nov 28, 2018 at 11:12 AM Udo Kohlmeyer <u...@apache.org> wrote:
Hi there Geode dev's.
I'm starting to notice more and more discussions about proposed features
or JIRA tickets, where imo, core Geode tenets are being violated.
Initially I thought that Geode must be lacking core tenets, to guide our
decisions. BUT then I noticed that we do state the on the home page.
http://geode.apache.org/
I would like to remind everyone working on Geode of the following tenets
which Geode lives and dies by:
1. Performance
2. Consistency
3. Low Latency
4. High concurrency
5. Elastic scalability
6. Reliable transactions
7. Share-nothing architecture
The reason I am calling this out, is that every decision we make, every
piece of code we write needs to meet and exceed (if possible) these
tenets. IF a solution or feature violates ANY one of the tenets, that is
solution needs to be revised to meet these tenets.
I would like to suggest that in the future we add two more tenets:
1. Modular
2. Predictable
Imo, Geode has to be modular. A simple architecture where it is possible
to easily replace modules of the system with more suitable (and greatly
improved) successors.
As for */Predictable/*, Geode needs to be predictable in the following
areas:
* Latency
* Error Handling
* Service contracts
Any thoughts?
--Udo
--
-John
john.blum10101 (skype)
