Illegitimate Affecters

Posted on

I’ve long been searching for a succinct noun phrase for that certain annoying thing that seemingly requires you to do something in a less-than-perfect way. Something that you know can and should be done better. You curse having that ‘requirement’, you loathe having to create a ‘workaround’, and you dream of a better world. Whether it’s the tardiness of the web standards world requiring CSS browser hacks, or the less-than-stellar API of an enterprise system with which you have to integrate, or perhaps being forced to browse in IE because of corporate bureaucracy, you’ve probably become annoyed at having to contend with this thing that, if the world was a better place, would not otherwise be detrimental to your work or productivity.

Having failed at finding the correct phrase for such a thing, I’ve done what I usually do and made one up. I now consider something like the above to be an illegitimate affecter. Having this succinct term is useful when identifying individual constituent parts of the system that can then be factored out by function and treated to an increase in quality (refactoring/rewriting) on a part by part basis.

For example, I sometimes stumble on poorly named properties only to trace their source back to the (poorly named) property of an outside API. The developer that first created the property in our application used the property name of the API object as an affecter but failed to recognize it as illegitimate, unnecessarily causing that little bit of extra confusion to all developers consequently working with that property.

I’ve also been in design discussions when reasons are brought up against making some architectural/design change to the system, only to be carefully exposed as illegitimate affecters, often temporary in nature, and sometimes actually even lending more weight to the argument to undertake the change proposed.

When they are outside of your control, illegitimate affecters should be kept at bay by abstraction layers. When inside your control, they themselves should form part of the redesign and refactoring discussions.

What illegitimate affecters can you think of?

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