Tuesday, November 26, 2013

Post Festum Code Changes

Just a quick one.

The mind of a programmer is rife with models of states and UI and objects and relationships. When they're coding something. Then later they're coding something else with different models of states and UI and objects and relationship. Ask them to go back and fix a bug in the first thing they wrote and they will do so from a fresh perspective. Ask them to go back and add functionality to old code and they'll do that with a fresh perspective.

Here's an example. The administration page has been developed to add users to a system. When it was developed it was after absorbing the relevant information, which included the fact that the user can choose an employee ID for the user and type it in - the system complains about any duplicates, preventing a user from being saved. To force the choice to NOT have an employee ID the default is 00000 and must be removed manually or updated to something new. The system seemed to be working great, then it was discovered that the customer wants a way to add lots of users from a list of first names and last names. This was added, but the person adding it forgot about the requirement for users to have unique (but optional) employee IDs and the code that turned the list into the user injected the 00000 default employee ID into all of the users, bypassing the input validation!

This is what I'm now calling a "Post Festum" code change. This is from the Latin usually meaning "too late" or "after the fact" - as in too much time has passed since the original coding. Helpfully, it literally means "after the feast", as in the main party is already over.