IF this THEN oops!

by Sean McGrath

July 30, 2007 —

You cannot spend more than two seconds thinking about solving problems with computers without running into the concept of "if...then...else..." A significant part of computerized problem solving revolves around the tantalizing simple notion of capturing behavior in terms of machine readable sentences of the form "if [something is true] then [do this thing] else [do this other thing]."

Sadly, it is also true that you cannot spend more than two seconds thinking about why a given problem is not being correctly solved by a computer without running into the concept of a logic error. Namely, all the places where the simplicity of "if...then...else..." is shattered by ugly brutish facts. Facts whereby the bit after the "else" does not logically follow from the bit after the "if".

For my own amusement, I have gathered together some of my favorite examples of nasty, ugly little facts that ruin beautifully simple "if...then...else..." theories. So, without further ado....

IF you have a security problem, THEN you need to use encryption.

IF information is to be properly managed THEN it must be in a database.

IF information is in a spreadsheet as well as in a database THEN the database version is more mission critical.

IF work is distributed amongst employees THEN the flow of that work can be mapped out and explained to a computer.

IF work is to be automated THEN the computer must know everything about what happens and when in order to be effective.

IF your data is in XML THEN it follows that it is more open and interoperable than it would be in other text formats like RTF or CSV.

IF an application works great on the Intranet THEN it can easily be transitioned to the internet by just flicking a few switches.

IF a person is good at mathematics THEN they will be good at computer programming.

IF a computer has lot of CPUs THEN it follows that it has better performance than one with less CPUs.

IF an application package has more features than some other package targeting the same problem domain, THEN the one with the most features is better.

IF you computerize a business process THEN it will be better than it was before you computerized it.

IF you have a detailed testing strategy THEN you can find all bugs prior to live running of a system.

IF you have N developers THEN adding more is always an option to speed up development cycles.

IF you have backups THEN disaster recovery will be merely mechanical exercise.

IF you remove duplication of data THEN you will always end up with a more robust system.

IF you give a committee enough time THEN the discussions will always converge on the right solution eventually.

And last but not least:

IF you read enough about how to do something with computers THEN actually doing it afterwards will be a mechanical exercise.

ITworld.com