In practice the two are, in my line of work, very difficult to separate. The what is almost always the how. But both, out of practical necessity. When the client insists on a particular implementation, that’s the implementation you go with.
That’s part of it, but no, that’s not what I’m referring to. Client necessities are client necessities.
“Encryption and file delivery need to be in separate process flows” would be closer. (This sounds high-level, but in the scripting language I do most of my work in, both of these are atomic operations.)
I take non-programmers seriously about programming all of the time. That’s pretty much in the job description.
Just because I’m not stupid doesn’t mean I’m not wrong. Indeed, it takes some serious intelligence to be wrong in the worst kind of ways.
About implementation, or about what to implement?
In practice the two are, in my line of work, very difficult to separate. The what is almost always the how. But both, out of practical necessity. When the client insists on a particular implementation, that’s the implementation you go with.
I would assume that’s high-level—“use Oracle, not MySQL”
That’s part of it, but no, that’s not what I’m referring to. Client necessities are client necessities.
“Encryption and file delivery need to be in separate process flows” would be closer. (This sounds high-level, but in the scripting language I do most of my work in, both of these are atomic operations.)