Sweeping Consequences - Avoid All In Until You Are Sure

There is an old joke about sweeping consequences in IT related to wildcard commands like "rm -rf *."  However, there are ways to avoid getting bit by them. For example, we can do test runs and subset queries before doing the real thing.  While it is undoubtedly faster to rip off one of those commands, it is also dangerous.  This episode looks into some tricks of the trade I learned after countless times of being tripped up by this concept. Sometimes Easy Creates Sweeping Consequences A database is the best tool for examples of doing something quick and dirty that ends up costly.  We can see this even with resource usage before more significant effects like data loss or corruption.  The old SQL command of "SELECT * FROM ..." is one of the first many people learn and the biggest culprit.  We do not see any problem with a table with a few rows.  However, once we move to millions of rows, we can quickly turn this quick call into a time-consuming one that ties up a lot of resources.  Even worse, we can add a join or two without constraints and bring a system to its knees.  It is easier to grab all the columns for a quick browse, but that can also drain more resources than desired. Check Your Expectations The database example is nice and clean because we can always add limiting constraints or do counts of result size.  These tools allow us to validate our query meets our expectations without fully running the query.  For example, we can do a select before a delete is run and ensure that the records we will delete are the ones we desire to remove.  Likewise, we can select before we update.  We can also do smaller selects to determine the result set size before joining those queries.  These are just a few examples; we can apply this to our other coding efforts and most life situations. If you like this season, you will probably like Scott Adams' book, "How to Fail at Almost Everything and Still Win Big: Kind of the Story of My Life."