RSS Feed

Monthly Archives: February 2014

I Hate Patch Files

I do a lot of coding in everything BUT the latest and trendiest languages for my job. Typically it is C or C++ for either small (as in 16K of RAM) microprocessors or, if I’m lucky, Linux.

Today I want to talk a little bit about patch files. You either love patch files or you hate them. Frankly, I think a lot of people hate them, that profess to love them, but that is their issue, not mine.

If you never had to deal with a patch file, the concept is really simple. The program, patch, looks for lines in the source code that match then adds or removes lines between those lines. So if the lines were “abcdefg” and the patch file was “abCDEfg” (where CDE were lines to be deleted), the result would be “abfg”.

Conceptually simple, elegant and, for the most part, foolproof.

Except for one little tiny thing. It is based on the assumption that code rarely ever changes. This is, of course, a bad assumption. Most software products have a 5-10 year lifespan (except for Windows – a whole different topic). In other words if it is code you didn’t write, don’t have control of, there IS no guarantee that it won’t substantially change tomorrow. Or next week. Or the day before you have to make that “minor tweak that shouldn’t take but a day”.

Which is why I hate patch files.

But I need the modifications, which is why I use patch files.

This is a case of there is no “right way” or “elegant way” without reinventing the wheel and maintaining it yourself.

So what is the solution? Beyond forking the project and maintaining it yourself there are only a few options:

  1. Document the order the patches need to be applied
  2. Document what each patch does (do not rely on code as documentation – it isn’t and it doesn’t)
  3. Explain how you derived the patch file. That may seem obvious now, but in three years you are going to go “wow… I must have been seriously brilliant back then”
  4. DO NOT ASSUME other people’s code will remain constant. If third party code is mission critical, keep a copy of the old code as a back up. Older code is better than no code or code that is wrongly patched.
  5. Never, ever, assume that you can just “patch and go” and slap that on a timeline projection. If the third party code has changed significantly (it will), then you will be doing yourself a disservice.

Patches are a good way to maintain tweaks to software, but they are fraught with assumptions. The best method of assuring that you don’t end up in a “redevelopment cycle” is to maintain clear and concise documentation as to what each patch does and why it does so.