I am often surprised how frequently developers fail to make database modifications simply out of laziness. Say you have a customer identifier for favorite color, and the values tend to be either blue, yellow, or red. Now say you add a new attribute to a customer and this attribute only applies to one existing subset that already exists.
Say only customers who put red as their favorite color also like beets. Should you add a new field (named beets) or should you split the "red" values in the existing field to "red likes beets" and "red dislikes beets." All too often I see folks go down the path of trying to squeeze additional information into the existing fields, "red likes beets."
Sure this requires changing less programming logic immediately but it also builds up "technical debt" by increasing the analytical complexity in the future. In short it trades elegance for immediately impressing the boss.
And this really gets to the crux of the matter in the Art in software development: do you shoot for pleasing the boss, or do you aim for a pleasing future?
