4 ms·

Can you clarify your argument/provide a possible solution? Your line of thinking seems kind of absurd to me - "Hey, we can't possibly predict our data model re

by s4vi0r 9y ago

Can you clarify your argument/provide a possible solution? Your line of thinking seems kind of absurd to me - "Hey, we can't possibly predict our data model requirements in the future, and explicitly encoding them into a schema/ADT/etc hinders flexibility (and somehow productivity?)" doesn't really hold up to scrutiny. Flexibility is great, but if anything the lesson mongo taught us over the past few years is that stability and safety are more important, and will cause you less of a headache in the long term. I feel like the same applies to ADTs - of course its more flexible to just have a free floating `name: String` or whatever, but then you also get to have the fun of validating your data all day as opposed to letting your compiler do the dirty work for you.

wellpast 9y ago
> Flexibility is great, but if anything the lesson mongo taught us over the past few years is that stability and safety are more important, and will cause you less of a headache in the long term. It sounds like you don't really need clarification, that you've learned the same lessons I have, but that you're just prioritizing differently and explicitly choosing "stability and safety" over flexibility (adaptability/agility). I go the other way. The biggest software costs in my experience are wanting to pivot on this or that business idea/requirement but being severely hindered[1] due to some unnecessary data taxonomization decisions that are so woven into the code (via ADTs/entity types) presumably for "safety" or "stability". By locking things down with ADTs and type taxonomies you most certainly get stability, I won't argue with that. But that stability by definition is rigidity. I want things to be dynamic. I want to be able to readily change my code assets because in most business operations the future demands that. Do you get "safety" with this stability as well? Probably, perhaps - but this would warrant a whole conversation about what is safety. In a dynamic/agile business environment, I personally will give up a little bit of safety for agility and dynamism. Because having an easily-fixable bug show up in production is far less costly to me than being paralyzed by an increasingly rigid/"stable" system that is hard to modify for future purposes. And even if I'm truly worried about bug volume, I can decouple that concern with the code agility concern. That is, I don't have to weave my bug mitigation concern into my codebase via hard type taxonomies. I can use other measures like code reviews, QA & testing, etc. and turn the knob up or down on these as a I see fit. The systems that weave all these concerns together in my experience always become harder and harder to bring new capability into. This is and should be no surprise, though. The world does not fit neatly into static, hard-line taxonomies. Our OCD minds would love it if it they did and people really try to make it fit into that (hence all the ADT hoopla we see everywhere) -- but in my experience the world always finds creative ways to frustrate our taxonomies...and systems that predicate themselves on a taxonomy always get frustrated by that. [1] Severely hindered means that something that should take very little time with very little impact on your app suite and very little coordination across the codebase(s) and team(s) instead requires all of these things.

by s4vi0r 9y ago

wellpast 9y ago

> Flexibility is great, but if anything the lesson mongo taught us over the past few years is that stability and safety are more important, and will cause you less of a headache in the long term. It sounds like you don't really need clarification, that you've learned the same lessons I have, but that you're just prioritizing differently and explicitly choosing "stability and safety" over flexibility (adaptability/agility). I go the other way. The biggest software costs in my experience are wanting to pivot on this or that business idea/requirement but being severely hindered[1] due to some unnecessary data taxonomization decisions that are so woven into the code (via ADTs/entity types) presumably for "safety" or "stability". By locking things down with ADTs and type taxonomies you most certainly get stability, I won't argue with that. But that stability by definition is rigidity. I want things to be dynamic. I want to be able to readily change my code assets because in most business operations the future demands that. Do you get "safety" with this stability as well? Probably, perhaps - but this would warrant a whole conversation about what is safety. In a dynamic/agile business environment, I personally will give up a little bit of safety for agility and dynamism. Because having an easily-fixable bug show up in production is far less costly to me than being paralyzed by an increasingly rigid/"stable" system that is hard to modify for future purposes. And even if I'm truly worried about bug volume, I can decouple that concern with the code agility concern. That is, I don't have to weave my bug mitigation concern into my codebase via hard type taxonomies. I can use other measures like code reviews, QA & testing, etc. and turn the knob up or down on these as a I see fit. The systems that weave all these concerns together in my experience always become harder and harder to bring new capability into. This is and should be no surprise, though. The world does not fit neatly into static, hard-line taxonomies. Our OCD minds would love it if it they did and people really try to make it fit into that (hence all the ADT hoopla we see everywhere) -- but in my experience the world always finds creative ways to frustrate our taxonomies...and systems that predicate themselves on a taxonomy always get frustrated by that. [1] Severely hindered means that something that should take very little time with very little impact on your app suite and very little coordination across the codebase(s) and team(s) instead requires all of these things.