3 ms·

How do you justify ever changing anything with that attitude? This change made parsing more lenient which is generally considered fine [1] and made the softwar

by dtech 7y ago

How do you justify ever changing anything with that attitude? This change made parsing more lenient which is generally considered fine [1] and made the software actually follow the spec, since it specifies object entries are unordered. [1] https://en.wikipedia.org/wiki/Robustness_principle https://en.wikipedia.org/wiki/Robustness_principle

tantalor 7y ago
> How do you justify ever changing anything By rolling out the change over a period of time to a small sample of users and comparing the experimental effect to a control sample.
roenxi 7y ago
The target culture would be to justify the change by saying "the reason this was implemented is X but X no longer holds". Anything else is an indicator of change without understanding; which is likely to lead to unforeseen results. The robustness principle is a powerful guideline for interface design; not an excuse to turn off validations that someone else has put in place. If the person who designed the interface wasn't ready for something, principles won't make the software work.
Someone 7y ago
”This change made parsing more lenient” How do you know? It makes the outermost layer of the system accept more liberal in what it accepts, but that doesn’t guarantee that the inner layers can handle that more liberal content. For example, the code may assume that “<user-ID>” always is the first node in the json. If you start sending “<car-ID>” instead, things may go fine until you get two customers who share a car. ”and made the software actually follow the spec” How do you know? The spec of this piece of software may state it has a JSON-like API that requires the “<user-ID>” to be the first node in every request. And yes, most of its code may handle that change fine, but it only takes one piece of code to break things. ”How do you justify ever changing anything with that attitude?” In the case of ”a service running IBM DataPower Gateway which sat on top of WebSphere which sat on top of the COBOL.” where ”Much of the system was so old that it was hard to find anyone who knew how it actually worked, and it’s maintenance had been outsourced ”: very carefully. This change may have been fine, but you have to check that.
Spivak 7y ago
The problem is that you have a complex interconnected system and you just flipped a switch that changed the entire protocol by which data was being transmitted. OrderedJSON and JSON might seem compatible on the surface but are you sure you caught every little code path that might have been assuming OrderedJSON? This isn't an issue of spec compliance or not because the data format wasn't JSON in the first place. OrderedJSON is not a subset of JSON even though it has the property that all OrderedJSON documents are syntactically valid JSON -- they represent different abstract values and JSON is the lossy interpretation.

by dtech 7y ago

tantalor 7y ago

> How do you justify ever changing anything By rolling out the change over a period of time to a small sample of users and comparing the experimental effect to a control sample.

roenxi 7y ago

The target culture would be to justify the change by saying "the reason this was implemented is X but X no longer holds". Anything else is an indicator of change without understanding; which is likely to lead to unforeseen results. The robustness principle is a powerful guideline for interface design; not an excuse to turn off validations that someone else has put in place. If the person who designed the interface wasn't ready for something, principles won't make the software work.

Someone 7y ago

”This change made parsing more lenient” How do you know? It makes the outermost layer of the system accept more liberal in what it accepts, but that doesn’t guarantee that the inner layers can handle that more liberal content. For example, the code may assume that “<user-ID>” always is the first node in the json. If you start sending “<car-ID>” instead, things may go fine until you get two customers who share a car. ”and made the software actually follow the spec” How do you know? The spec of this piece of software may state it has a JSON-like API that requires the “<user-ID>” to be the first node in every request. And yes, most of its code may handle that change fine, but it only takes one piece of code to break things. ”How do you justify ever changing anything with that attitude?” In the case of ”a service running IBM DataPower Gateway which sat on top of WebSphere which sat on top of the COBOL.” where ”Much of the system was so old that it was hard to find anyone who knew how it actually worked, and it’s maintenance had been outsourced ”: very carefully. This change may have been fine, but you have to check that.

Spivak 7y ago

The problem is that you have a complex interconnected system and you just flipped a switch that changed the entire protocol by which data was being transmitted. OrderedJSON and JSON might seem compatible on the surface but are you sure you caught every little code path that might have been assuming OrderedJSON? This isn't an issue of spec compliance or not because the data format wasn't JSON in the first place. OrderedJSON is not a subset of JSON even though it has the property that all OrderedJSON documents are syntactically valid JSON -- they represent different abstract values and JSON is the lossy interpretation.