From an early age, I learned that building things with code was almost more fun than playing video games.  It’s like solving a puzzle or building a craft.  Coding gets even more fun when you can use what you have built to save yourself time or you watch someone else use your brainchild. 

Now, any problem that arises, I set my head spinning through plans and my fingers flurrying across the keyboard.  It’s almost an involuntary reaction.  Users don’t understand how to enter the data?  Let’s build a wizard that walks them through it.  Keep forgetting to add code to the project for migration?  I can create a tool that checks for missed objects.  Takes too long to text the kids on the little league?  I’ll just code a tool to blast out the messages. 

Over the years, I’ve learned that reaction isn’t always the best.  Sometimes the solution isn’t code or even technical at all.

90% of Transactions 

To handle all of the different types of transactions can take a great deal of effort.  The effort you have to put in to build a solution grows exponentially the greater the percentage of transactions that you want to handle. 

Often, a solution that can handle 98% of all transactions takes twice as long as one that covers 90% of the transactions.  Coding for 99.5% can take four times as long. 

So, in this case, a technical code solution isn’t the best.  Planning to handle 10% of the transactions manually can save half of the development time.  In addition, once developed, a less complex solution maintains much easier. 

A textbook example is midstack rows in Job Data.  In other words, an employee has a future-dated row in Job, and the solution requires inserting a row as of today.  The situation is complicated because the code must determine whether to use the values from the future row or the current row when creating the new row.  The best solution is to simply throw up an error message informing the user of the future row and instruct the user to contact HR to perform the update manually.  Assuming future rows are rare, this is low impact to the users. 

Understand Why 

Before writing code, make sure that you understand the whole picture and the background of what you are trying to accomplish.  Taking the time to analyze can sometimes show other solutions rather than building something new with code. 

For example, we had an issue with a migration tool taking too long to process and load data.  The temptation was to build a solution to process it in the background so it wouldn’t time out. With more analysis, we found that the problem was in the data.  A bug was causing the import data to include duplicates.  Rather than building a complex solution to handle a huge import, the correct solution was to fix the bug. 

Another example is bad data in component interfaces.  On multiple instances, I’ve run into errors during a CI load.  The temptation was to try to go through the code and fix it to handle the error better.  Instead, taking the time to understand the data kept me from wasting time in the code.  In at least one instance, the problems were all in old data.  The solution was to simply turn off ‘include history’, and the errors went away. 

A good programmer will open his mind to all options.  Taking time to understand the issue and think outside the code can make you a better programmer.