reThe Order of the JSON, AKA–irresponsible assumptions and blind spots
I run into this post, in which the author describe how they got ERROR 1000294 from IBM DataPower Gateway as part of an integration effort. The underlying issue was that he sent JSON to the endpoint in an order that it wasn’t expected.
After asking the team at the other end to fix it, the author got back an estimation of effort for 9 people for 6 months (4.5 man years!). The author then went and figured out that the fix for the error was somewhere deep inside DataPower:
Validate order of JSON? [X]
The author then proceeded to question the competency / moral integrity of the estimation.
I believe that the author was grossly unfair, at best, to the people doing the estimation. Mostly because he assumed that unchecking the box and running a single request is a sufficient level of testing for this kind of change. But also because it appears that the author never considered once what is the reason this setting may be in place.
- The sort order of JSON has been responsible for Remote Code Execution vulnerabilities.
- The code processing the JSON may not do that in a streaming fashion, and therefor expect the data in a particular order.
- Worse, the code may just assume the order of the fields and access them by index. Change the order of the fields, and you may reverse the Creditor and Debtor fields.
- The code may translate the JSON to another format and send it over to another system (likely, given the mentioned legacy system.
The setting is there to protect the system, and unchecking that value means that you have to check every single one of the integration points (which may be several layers deep) to ensure that there isn’t explicit or implied ordering to the JSON.
In short, given the scope and size of the change: “Fundamentally alter how we accept data from the outside world”, I can absolutely see why they gave this number.
And yes, for 99% of the cases, there isn’t likely to be any different, but you need to validate for that nasty 1% scenario.
More posts in "re" series:
- (19 Jun 2024) Building a Database Engine in C# & .NET
- (05 Mar 2024) Technology & Friends - Oren Eini on the Corax Search Engine
- (15 Jan 2024) S06E09 - From Code Generation to Revolutionary RavenDB
- (02 Jan 2024) .NET Rocks Data Sharding with Oren Eini
- (01 Jan 2024) .NET Core podcast on RavenDB, performance and .NET
- (28 Aug 2023) RavenDB and High Performance with Oren Eini
- (17 Feb 2023) RavenDB Usage Patterns
- (12 Dec 2022) Software architecture with Oren Eini
- (17 Nov 2022) RavenDB in a Distributed Cloud Environment
- (25 Jul 2022) Build your own database at Cloud Lunch & Learn
- (15 Jul 2022) Non relational data modeling & Database engine internals
- (11 Apr 2022) Clean Architecture with RavenDB
- (14 Mar 2022) Database Security in a Hostile World
- (02 Mar 2022) RavenDB–a really boring database
Comments
I think you made a typo and you meant "expect" instead of except (or maybe accept) in your 2nd bullet point.
Thanks, fixed
The post in question squares with my experience working with IBM teams. So many catastrophic failures, so many multi-million dollar solutions that basic algorithmic knowledge could have delivered in days with very little cost. It's Ockham's razor that the estimate is just profiteering
It's a typical IBM estimate that is based on how many people they want to bill and for what period. Their consultation provides no value and they won't tell you why they're doing anything, just how long it will take to fix your ask. A valuable consultant would be able to argue for the current implementation's saliency and concretely describe why this is the case. They would also be able to explain why the checkbox in question exists. They did not and could not do either of those things, therefore the estimate is invalid.
Disclaimer: I've spent thousands of hours of "KT" training IBM "consultants" that my client hired. Every two years you'd get an entirely new team of IBM India recent college graduates (questionable if that). They move them to some form of management after they get their h1b to maximize profits, so you're guaranteed zero intellectual capital retention. I've met very few who were competent at or even cared about their job. IBM farms India for anyone who will work at their price point, especially in practices like Datapower and application maintenance.
Miu, To be honest, I wouldn't be surprised by this at all. But the fact that such a checkbox exists doesn't mean that the actual work required is just setting it. And I can certainly see the quote's details / reasoning getting lost along the way.
Comment preview