Don’t make your code do the Hokey Cokey

Awkward words and perverse DIY projects have enough in common with some software design problems to teach us things.  Instead of always adding stuff on to change something to be the way we want, sometimes we should take things away.  These are all instances of a forwards and backwards problem that reminds me of the Hokey Cokey. I think this is called the Hokey Pokey in other countries: why we can’t agree on the name for such an important thing, I don’t know.

Awkward words

There are rules for making words of from one part of speech out of words of a different part:

• Noun ⇒ adjective: X ⇒ X + “al” e.g. bride ⇒ bridal (yes, I know that the final e is removed too)
• Adjective ⇒ noun: X ⇒ X + “ity” e.g. special ⇒ speciality

Given these rules, if you have the adjective conditional what’s the related noun?  Some people say it’s conditionality, treating conditional as an indivisible adjective that needs something adding onto it to make it into a noun.  If, however, you realise that it’s actually a smaller noun that’s been made into an adjective already, you can simply undo that to end up with the noun condition.  Similarly, modal should go to mode and not to modality.

Perverse DIY projects

You’ve probably seen at least two kinds of door in people’s homes: flat ones and panel doors.  You might want a panel door because it has character.  You might want a flat door for its clean and simple outside, or so that you can hide snacks.

If you have a panel door and want a flat door, instead of getting rid of the panel door you could convert it to a flat door by putting a sheet of plywood on both sides to cover up the recessed panels.  Alternatively, if you have a flat door and want a panel door, you can approximate this by sticking on bits of moulding to resemble the sloping edges around the recessed panels.

You can see where this is going, probably.  You have a flat door and want it to be a panel door – do you stick on ridges, or see if there’s a sheet of plywood covering up the panel door underneath?

Software design problems

You have a large lump of data in your GetCustomers code, that ultimately came from a database, and it’s in the form of a list of Customer objects.  You need this to be dumped into a spreadsheet, and the old 3^rd party code you’re using for this will accept data only in the form of a DataTable.  (It’s possibly easier to use the OpenXML SDK, but let’s assume you can’t for some reason.)  In case you haven’t met DataTable before, it’s a general-purpose container of a grid of data.  It has a list of strings that describe the column or field names, and then an array of objects for each row’s data.

You could write some code that converts the list of Customer objects to a DataTable.  Or you could dig down into lower levels of your GetCustomers to see if the data was fetched by calling a stored procedure.  If this is true, then it’s possible that the data was returned from the stored procedure as a DataTable, which was then painstakingly converted into a list of Customer objects.  You could then edit the lower level code so that you could have access to the DataTable directly, and avoid the conversion List<Customer> ⇒ DataTable and the other conversion DataTable ⇒ List<Customer>.

Maybe your code doesn’t have customers, but it does have points in 2D space.  There might be two ways in which a point is represented – Cartesian and polar co-ordinates.  If you look across the call stack for each path through your code, are there times when a point is converted from one form to the other and then back again?

Summary

Watch how data is represented, particularly if you find yourself converting it from one representation to another.  It might already have been in that representation earlier in its life.  Try to avoid your code having to do the Hokey Cokey (or Pokey).