Programming is actually like that, too. The fewer exceptions, the easier things are and the fewer bugs. Even writing documentation and testing notes are easier when there are fewer exceptions.

Example: Suppose you have a print menu with 5 options for 5 reports. Each of the 5 menu options creates a two-dimensional array of cells and calls a common function, PrintTable, that formats the table and sends it to the printer.

Suppose a client reports, “When the ‘forgiven debts’ report prints, the header is centered aligned. It would look much better if it would be justified.”

When you code this, you can decide whether to do the minimum requested and only change one report or do it consistently for all reports. If you do more than the minimum requested and make all the reports consistent then:

• You are more likely to find bugs sooner. Since the report is only used 5% as often as other reports, it’s unlikely that bugs in its title formatting will be found. However, if all reports would use the new justification, you’ll be more likely to find the bugs sooner.
• The code is easier to read. You’ll avoid adding one more parameter, shouldJustifyTitle, to the PrintTable function. That is certainly a favor to the mainenance programmer, since he will not need to research and understand one more parameter.
• Documentation is easier. Which is easier to write: “The title on all reports should be justified” or “The title on the ‘forgiven debts’ report should be justified, but the title on all other reports should be left aligned”?
• You’ll even avoid needing to mark bug reports as “no action needed.” If there are exceptions, even if intentional, the testing team may not know what those exceptions are and may report them as bugs.

Words to Live By:

If I can make two features work alike, that will save time.

If I can eliminate an if statement, that will reduce bugs.

If I can avoid adding a parameter, I am preparing the way for the maintenance programmer.

If you combine two pieces of text (A and B) and separate them later, you need to make sure that the delimiter (D) can never be in A nor B. Or if it can be, you need to generate a scheme to encode D where it appears in A and B.

Example bug #1: An GUI creates a sample commandline to allow a task to be automated. The command-line is the following:

Batch.exe ‘Report Name’

Because the commandline contains multiple pieces of information (a program name and a report name), the Guideline applies here. The above commandline will work until a user creates a report named “Bob’s Sales Reports”.

Example bug #2: A database has a “contacts” table with two fields: a contact name and an e-mail address. This is displayed in a web application in a dropdown list in the format “Person (name@example.com)”. When the form is posted, this combined name gets sent to the server. The server removes the trailing “)” and then splits the string at the first ” (“. This works fine most of time. Until someone adds a contact named “Hillary (Rodman) Clinton”. According the Guideline, using “ (“ as a delimiter is not safe since the contact name can contain that delimiter.

Example bug #3: An accounting program has a set of accounts. One or more accounts can be selected at a time. When the program shuts down, the list of selected accounts is stored in the registry as a single string separated by commas. According to the Guideline, this works only if the account name cannot have a comma. Chances are the GUI validates against commas, but the batch “Create Accounts” tool does not.

Conclusion: In my experience, these sorts of bugs are often missed in testing. Even once the software is deployed, they are not caught right away. They sometimes show up 5 years later. But more often than not, they do show up. It’s worth coding it right.

I personally find myself favoring fast web sites. I have long been recommending Bank of America over HSBC mostly because Bank of America has snappy online banking.

For an excellent book on this topic, see High Performance Web Sites by Steve Souders. It has a lot of practical advice and is an easy read.

Synchronization has definite advantages:

1. Data is available offline. This allows accessing information when the Internet connection is down, at the coffee shop that still doesn’t have Internet access, and on the plane.
2. Existing desktop tools can be used to edit and view the information. Most desktop applications still do not know how to load/view/edit data in the cloud.

However, synchronization also introduces several problems:

1. Freshness of data. Data must be kept fresh enough. How fresh is fresh enough? That depends on software. For photo sharing software, two-day-old photo tags are fine. For CRM software, however, twenty minutes old can be stale enough to cause misinformed decisions.
2. Conflicts. If data is synchronized, conflicts will occur. These need to be handled well. The user who caused the conflict should be notified in a timely manner. Because he or she can resolve the issue more quickly than anyone else, he should be the one who resolves it. The document should merely not be duplicated, since that makes it hard for others to know which copy to use.

Synchronization is inherently harder than a simple database server. Sometimes, however, the benefits are worth the challenges.

However, its usefulness is limited for several reasons. For one, the new operating systems are not widely used. For another, many corporations use network attached storage, which does not necessarily support transactional NFTS.