I'm not going to get into specifics; instead I'm just going to say that my project, today, is painful to deploy. And not only is deployment painful, it's error-prone. And I don't mean "error" in the hypothetical, higher-percentage-than-that-other-hypothetical-percentage sense of the word; the sanitary, almost clinical sense. I mean, oops, there went four hours troubleshooting when I deployed the wrong DLL, preventable kind of error.

So it hurts.

There's lots of pain in the world of software development, but it doesn't have to be this bad. All I need to do is, in the beginning, set aside some time to deploy an empty shell of a project. When I say empty shell I mean, almost literally, a Hello World type of application. If this Hello World application involves seven databases, twenty seven service accounts, a network load balancer and forty web.config files, so be it. If the deployment requires granting of security permissions to these twenty seven service accounts, so be it. Sure, it's going to seem useless, and the tangible payoff will be minimal. Painful? Error-prone? Bring it on. Bring it on at the beginning.

And please, for your own sake, one-click automate the deployment! If nothing else, automate the happy path, which is orders of magnitude easier than building a fault-tolerant deployment. Worst case, your automated deployment fails and you're back to manually deploying. In other words, if you're deploying manually, then you're already living out the worst-case scenario.

And by you, I mean me, today. Again, not hypothetical.

Happy path/sad path by example: copying a folder

Happy path:

  1. Copy a folder and contents to a destination directory.
  2. You're done! Congratulations!

Sad path:

  • Does the source file exist?
  • Is the source file unlocked for read?
  • Does the destination folder exist?
    • Or its parent folder?
      • Or its parent?
        • Or the parent drive?
        • Or parent network share?
          • Or maybe you need to connect to the network share with a different service account?
            • So this means you need to explicitly drop all current connections.
  • Can we drop (delete) the existing destination folder?
    • Is the folder locked?
      • Is this because we have an Explorer window open to the folder (sooooooooooo common for me)
  • Are we overwriting a file?
    • Do we have permissions?
    • Is the file locked?
  • What if some of the file copy operations succeed, but not others?
    • Do we have a perfect backout strategy?
      • Can we restore the original folder in its entirety?
      • If not, can we restore each individually changed item in its entirety?
        • Are we running in a transaction?
          • Are all our options atomic?
            • Do we implement a transaction log of sorts? How do we know without a shadow of a doubt our operations succeeded?
  • Did the virus scanner interfere when copying an .EXE?
    • On your machine?
    • On the remote machine?
    • On an invisible HTTP proxy on the network?
  • Is the remove file share something crazy like WebDAV, where only some operations are supported?
    • Are you sure you're running the WebClient service required to make this WebDAV/explorer integration work?
  • Are the file+pathnames reaching the maximum allowable limit, and are you copying to a deeper subdirectory which would cause "too long filename" errors to occur?

IT as a career makes me paranoid--this is a ridiculous checklist for just copying a file. But I've experienced all of these things. Yes, it's ridiculous, and yes, it's real.