Change Without Fear
Change Without FearThe ability of information processing tools to make nearly effortless copies of files and even entire directories gives us a very powerful technique to manage change: before you do anything, make a copy! This has now become almost second nature to most software engineers. (I think of it as "working with a net," and I think of copies made for this purpose as safety copies.)
The key idea is NOT to waste a lot of time deciding whether to make a change, delete a file, etc. Just make a quick copy, and then forge ahead. If it turns out that you made a boneheaded mistake, you fall back to your original file(s). (Note that if you're really applying this technique consistently, you won't just delete your "mistake," either -- you'll rename it something like "file.bad" in case you decide later that you had the right idea, or at least the germ of a good idea...) [See TheRoadNotTraveled for more on this.]
This technique potentially applies to any kind of information: source code, images, documentation, whatever. It works best if you either (a) have simple commands or tools to make copies easily, or (b) write scripts or tools to make it easy. It is extremely useful to have an intelligent command or script that will choose a unique (and hopefully meaningful) name for the copied file/directory for you (date/time stamps are one way to go), so you don't hesitate to think about what to name the copy. It often helps to keep these safety copies in a separate directory from where you're working. (I often use a directory named Back or Safe or Old; sometimes I end up with cascading names like Old, Older, Oldest... {grin})
Another helpful behavior is to periodically set aside some time to do housekeeping on all these safety copies; usually some of them were clearly only for a short-term backup and can be deleted; others you may want to weed out (e.g. for example, delete all files except source), and possibly archive (compress, zip, tar, etc.) for a few weeks, months, or years. (I often apply a personal heuristic along the lines of "if I haven't used it for so long that I don't even remember what it was for, I probably don't need to keep it anymore...")
Version Control and Configuration Management are just fancy and more comprehensive ways to do the same basic concept. If you know you've got a "good" version of your software captured in a "baseline" somewhere, you can forge ahead with confidence that if you screw up, you can fall back to a known quality, something that (presumably) still works....
I think there are possible tie-ins to DeleteByMoving, JunkBox, PackRat, and others...
-- AndyMoore
I have a tool that works like this. I always have a complete, unmodified copy of my work in a directory called "Latest". I make any changes I choose, then activate the tool. It creates a directory named by the date and time, for example 200202191555. It compares my working version with the version in "Latest". For any given file there are three possibilities:
Works a treat.
I use a system of versioning files which serves to preserve files by time and date. Say the file is "WhatWasRead?.txt". The latest file is named "WhatWasDoneToday?.txt". When the file is opened for revision, I save it as "WhatWasRead? 200309051215.txt", then proceed on whatever modifications or additions. When it is complete, I then save it as "WhatWasRead?.txt". Using this method, it does not require the preparation of a date-time directory, and when multiple versions occur in the same directory, a sorted listing will result in the current file at the top or bottom (depending on sort order) with the versions in order. Using a file-find with the YYYYMMDD will provide a listing of files by date changed, regardless of location. (I use a similar method for saving wiki-pages, with this page being saved as "WardsWiki ChangeWithoutFear 200309052230.txt")
EditText of this page
(last edited December 14, 2014)
or FindPage with title or text search