3 ms·

I just want to point out for any poor soul who may find themselves on the other end of a request to implement an FTP feature and who may not know this: FTP is

I just want to point out for any poor soul who may find themselves on the other end of a request to implement an FTP feature and who may not know this: FTP is plain text file transfer protocol, there's not really any good reason to use it anymore IMHO FTPS is an extension to FTP to support SSL/TLS SFTP is "Secure Shell File Transfer Protocol" (e.g. over SSH) We had a project once where the customer asked us to use "SFTP" to manage some critical files. This was handled in-app, we added the functionality, did our testing and moved on. Later when we did integration testing with their system we discovered that what the customer actually meant was to ask us for "FTPS" and we had to rip out the SFTP library with FTPS stuff. Something similar _almost_ happened a couple of years later in another project (due to miscommunication by someone doing requirements gathering) and this time we caught it early.

Jugurtha 5y ago
>Something similar _almost_ happened a couple of years later in another project (due to miscommunication by someone doing requirements gathering) and this time we caught it early. Right on. Requirements gathering and problem scoping is refined conversation. We were in a meeting with someone who wanted us to predict an event that caused losses in the 9 figures 48 hours before it happens and trigger an alert. 48 hours sounded round and arbitrary, so I used "negative framing" and asked "At what point would an alert be useless. At what point is it too late to inform you?" He said "It's never too late. Even if you predict it two minutes before, we can do things. We have procedures". Effectively reducing from 48 hours to 2 minutes. This changes the whole thing. Requirements that are polluted by client's solutions should always be explored further for the actual job to be done, and the actual problem to be solved.

Jugurtha 5y ago

>Something similar _almost_ happened a couple of years later in another project (due to miscommunication by someone doing requirements gathering) and this time we caught it early. Right on. Requirements gathering and problem scoping is refined conversation. We were in a meeting with someone who wanted us to predict an event that caused losses in the 9 figures 48 hours before it happens and trigger an alert. 48 hours sounded round and arbitrary, so I used "negative framing" and asked "At what point would an alert be useless. At what point is it too late to inform you?" He said "It's never too late. Even if you predict it two minutes before, we can do things. We have procedures". Effectively reducing from 48 hours to 2 minutes. This changes the whole thing. Requirements that are polluted by client's solutions should always be explored further for the actual job to be done, and the actual problem to be solved.