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)
