Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I have a question about the best practice in this situation.

At one point, my small application allowed the client to upload a file to a server, and download a file from the server (it would also compress / decompress as well).

This was created in 1 solution which consisted of 4 projects:

  1. FTP
  2. CompressDecompress
  3. UI
  4. Tests

Now, the spec has changed and there will 2 end users, one who only wants to upload, the other who only wants to download and they should never have access to anything else (ie downloading people cannot upload and vice versa).

So, I have a few choices here. I could either

  1. Keep it as 1 solution, and ask users to login, based upon the credentials will display a different UI

  2. Alter my UI so it only shows tools to download, create a new solution which consists of just a UI project and reference my .dll accordingly.

  3. Delete my UI, create 2 new solutions, each solution being created for either download or upload (and each solution probably only consisting of just 1 project, the UI) and again, referencing the .dll

Does any one have any suggestions? Would any guidelines have allowed me to have not gotten into this situation in the first place (or at least made me more aware of the potential disasters)?

share|improve this question
add comment

1 Answer

up vote 3 down vote accepted

I am mildly surprised by the requirement that the uploading user is only allowed to upload. I can see a use-case for read-only access (download only), but much less for write-only access (upload only), unless that role is to be filled by an automated system.

With that in mind, I would weigh my options as follows

  • If both users are expected to be human, extend the UI with login functionality and provide either the upload or download functionality, depending on the user credentials. This keeps the project future-proof for the case that there will be another requirements change to support both up- and download again for one user.
  • If one of the users is expected to be a machine, add another project to the solution, providing an API that is tailored for machine-machine communication, parallel to the functionality you currently have in the UI. The unneeded functionality should be stripped from the UI.

Big scope-changes like this can usually not be foreseen during the initial development of a project, so there are no guidelines to prepare your codebase for them.
What you can prepare for are requirements that seem oddly restricting (like the write-only user you have now), and write your code in such a way that the requirement can change without forcing a complete rewrite of a project.

share|improve this answer
    
Thank you for the comments, it's good to know! –  Dave Rook Feb 19 '13 at 11:13
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.