Don’t Be Underhanded

Keeping with chapter 1, the Proverbs tell us to be careful about the company we keep.

In particular, the Proverbs tell us to seek wisdom and instruction, and stay away from the sneaky, the violent, the cold-hearted, the flatterer, and the foolish.  As developers, this remains good advice.  We should not work for the foolish, cold-hearted, or violent.  It is wisdom to work within the law and to be kind to the customer. Cheats and sneaks in business are no good and will ultimately take their comrades down with them.  Socially this makes sense.  In a business sense it makes sense.

But lets turn this to code. We’re told not to join among those who look for gain by violence or subtlety. Our “gain” in code is that people will pay us for increased functionality.

Now we can add functionality in legitimate or illegitimate means.  We know that the right way involves testing, coding, refactoring, and testing some more.  It involves examining the code before and after making changes.  On the other hand, there is almost always some way to “cheat” the code into working.  I remember an ill-fated POS system where deposits and change-making were considered very late in the process.  The team decided to cheat it into place by treating deposits and change-making as “purchases” because the system already knew how to sell things. Now the end-user could “buy a deposit” of $200.00 instead of making a $200.00 deposit.  The accounting came out right, but it was a funny way of looking at things.

Likewise, we have all seen people writing code that cheats a feature into existence in ways that are not immediately visible to the end-user.  These cheats (“hacks”) seem like a clever way to get something for nothing.  Eventually people make quite reasonable changes to the system, and find that code breaks in mysterious ways.  The cheats were counting on certain underhanded tricks. When those tricks no longer work because of very reasonable code changes, the system is broken.  Often changes have to be abandoned, and new functionality cheated into the system in order to restore function.  In these cases, the code has to get increasingly worse over time, or someone has to invest more time and risk into setting it right.

Cheating, tricking, or forcing changes into the code are foolish acts of coding violence.  Even if the code still works, the final rewards are code death — or something that at least *feels* like eternal punishment.  “So are the ways of everyone who is greedy for gain; it takes away the life of its owners.”


About this entry