I get asked every so often what my photo processing workflow is like, so I decided to post it here:

1. I always shoot RAW. (Why? Disk space is cheap; ruining a great shot because of white balance issues is annoying.)
2. When I arrive home with a new batch of photos, I copy them all to two places: my NAS (to back up my unedited photos) and my photo editing workstation (into a to-be-edited folder).
3. My wife Caroline reviews the photos on the photo editing workstation using Canon’s Digital Photo Pro (DPP), marking the ones she does and doesn’t like.
4. I review Caroline’s selections and occasionally make a few changes to the selections. In addition to some differences in taste, I will occasionally toss out photos because I don’t think they are salvageable. I also add in  photos similar to some of the already-selected photos because I plan on cropping or editing them differently. I will also sometimes switch out a photo for a very similar looking one for technical reasons — slightly better focus or exposure, or less noise. Having said all that, about 95% of the photos I post are the ones Caroline selected.
5. I delete the rejected photos from my photo editing workstation. (Note that I still have all the unmodified photos on my NAS.)
6. I edit the selected photos in DPP, and then export them as top-quality JPEGs.
7. If needed, I edit the photos some more in Photoshop. (This is pretty rare.)
8. Caroline reviews the edited photos and provides feedback. If needed I work with her to retouch the photos she has concerns about. Usually a few more photos get deleted at this point.
9. I upload the photos to SmugMug.
10. I move the edited RAW and JPG files to an edited folder on my NAS. The NAS now has every photo I took straight off my camera, an edited RAW file for photos I’ve posted, and all the JPGs that I’ve posted.
11. The NAS is backed up regularly to two separate external drives, one of which is stored off-site.

(And before anyone says, “You should try Lightroom!”, I’ve tried Lightroom, and prefer DPP’s RAW processing.)

Almost invariably at the end of a software project, someone will insist on fixing an annoying but non-critical bug. Perhaps the browser will freeze if you hit refresh 200 times in a row, or maybe button text overlaps when you get more than 20 incoming calls during an outgoing call. The cry will go out, “We should fix this bug! It’s a simple change! It couldn’t possibly break anything!” Sometimes this will come from marketing; other times the engineer for that component will want to make the change.

Looking at the proposed fix, the change will appear to be fool-proof. Perhaps a variable didn’t get initialized properly, or a resource had a typo, or someone forgot a break in a switch statement. You may say to yourself, “There’s no way something this simple could possibly break anything, so let’s do it!”

Before you agree to a claimed “zero-risk” change, read this true story from Raymond Chen at Microsoft. It demonstrates how every change has risk, sometimes in unusual and unexpected ways. During the middle of a project, there’s time to find and react to any unexpected side-effects from a change; at the end of a project, the side-effects may be serious enough that dealing with them will delay the software’s release. Do you want to be the one explaining to the CEO that the product can’t ship on time because a “zero-risk” cosmetic fix introduced a serious problem into the planned final build?

So avoid the temptation, and at the end of a project only fix bugs that actually prevent the product from shipping.