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) > -- -John john.blum10101 (skype)
