RSS Feed

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.


About Catalina Feloneous

Catalina Feloneous (“Call me Cat, I’m not a felon”) has been on Final Fantasy 14 since the initial beta. She is very much into fashion, humor, and games. As a gamer (lower case g) she always plays on Super Easy much to dismay of her friends. She lives on a ranch in Texas with her husband, one horses and two cats. “Feloneous” is misspelled intentionally.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: