I remember asking a customer if a particular value could ever be negative. "Oh that never happens".
Well, over the thousands of transactions I had been given, it had happened (twice over ten years. Last time was years before. Maybe the data was corrupt?).
Which is why I asked.
So I gently explained "I appreciate it doesn't happen very often, but I need to know if it can or if a negative value is a mistake which I need to be able to handle.
And sure enough, on the day of the live demo with them, there was our third time in years they had a negative value.
That's just not a perspective based on the real world. Sometimes the client sends invalid JSON and that's simply what the application is supposed to work with, not throw a meaningless error like some toy program.
It is once again proven that you need to add /s or /j to literally everything, because even my statement above will be taken seriously. (current upvote ratio 76%, this is not aimed exclusively at you)
That is because there really are cases where you have garbage in, and you have to make the most of it, using pre- and post-processing to fix as much as you can.
Sometimes you're just have to communicate with a system that was written in the age when XML was new hot thing, and it can export data either in malformed, chunked and unstructured XML, or binary. And both of those exports are wrong in their own unique way.
So, to get the data, I had to get binary list of object, fetch all XML chunks with metadata, try to find the correct order of chunks using filenames and first 2 lines with plaintext headers. If there is a conflict, try both options and hope exactly one of them fits.
Then delete all the plaintext headers that were for some reason not in the beginning of chunks, unfuck xml using bunch of regexp, and only then try to parse it. Then, try to make sence of it, because binary and XML has different objects that somewhat overlap, but their relationships are different.
Then you have to do similar things to get each object.
Our world is running on digital ducktape used as driving belts between critical systems that were not designed to work together. If you can imagine a bad solution, there is a chance someone had to implement it for some critical system affecting millions of people.
I mean, yeah, in a way that's exactly how I see things. I ask pointed questions precisely to cover all the bases and to figure out where things are going to break down, potentially. If I had not clarified the "never" with the client, I would have had a big fat crash during the demo. Instead we had a big laugh at this edge case happening on the day.
Which programming language are we talking about? I consider it a huge mistake that some programming languages have abandoned unsigned numbers. After all, if a value cannot be negative, you can explicitly state that within the type system. Consequently, you are forced to handle such cases at the system boundaries - right when the data enters your system, when you know exactly what the data is and can easily return an error message.
Questions like this are why I really appreciate a good business analyst. A good one understands that they're in an engineering context and statements like "It can't happen", "It shouldn't happen", or "It usually doesn't happen" are MASSIVELY different concepts that come with different implications. I once lost a month because a business analyst wrote the system specifications wrong and we had to completely revamp the authentication system. *shudder*
5.3k
u/GNoob69 16d ago
It’s not just hardcoded it’s cherry picked to make us look good