Need help with your internet presence?


I’ve decided to try to get into the consulting business for internet support and web sites.  Do you want help getting your business a web site and a presence on the internet.  I will provide free help in order to build up a local reputation.  No cost, no obligation, and I will provide links to posts and web sites that will help you.

I’ve been working in information technology for thirty years, and somebody might as well get some benefit out of it.  By the way, this web site is hosted on, which provides absolutely free web hosting.

The following are some related posts.

  • Putting your business on the map – How to make sure that your business is shown on Google and Apple Map applications.  You want people to be able to find you.
  • Initial website planning – Think about what you want your website to be before you start developing it.  It saves a lot of work.

Beware the Genie

via Daily Prompt: Genie

If you look at the old fairy tales, you will find that Genies grant your wishes according to Murphy’s law: “If anything can go wrong, it will go wrong”.  To a large extent, this applies to many pieces of computer technology.

  • You can wish to control the lights, air conditioning, and doors in your house from anywhere in the world via the internet of things (IoT) and then find out that everyone else also has the ability to do so, including the burglar who robs your house while you are out of town.
  • You can wish to have access to a site that will build your web site without your having to think, and then find that you have created a site that clearly shows the amount of thought that goes into it.
  • You create a web site because you want to be widely known, and find that the most avid readers are people who want to sell you resort timeshares and a piece of the Brooklyn Bridge.
  • You wish for web site development frameworks that will drastically reduce the effort required, and find that everyone can now hack your site and obtain all your personal information, including your credit card and checking account numbers.

There are a number of books and movies that will show you that magic is dangerous.  According to Florence Ambrose in the online comic Freefall, “Any technology, no matter how primitive, is magic to those who don’t understand it.”  So perhaps you should stop asking the Genie for things until you understand what is happening.  It may take some effort, but as stated by Agatha Heterodyne in the online comic strip Girl Genius: “Any sufficiently analyzed magic is indistinguishable from science!”.  So, before we go to the Genie and wish for things, we should analyze our desires and the available technology more closely.

After all, asking for a Genie and receiving an air to air missile with an atomic warhead would really be bad.

This is my first attempt at writing an entry for the WordPress Daily Post.  If you feel that it is taking the topic less than seriously, you are correct.  After all, if you learn to laugh at yourself, you will always have a source of amusement.  Or as the Cheshire Cat said in Alice in Wonderland, “We’re all mad, you know”.

Initial Website Planning

This page is a work in progress.  Let me know if you have any comments.


There is a very old saying that “Failing to plan is planning to fail”.  (Before you complain about my not providing a citation, I have seen versions of this attributed to Winston Churchill, Benjamin Franklin, George Patton, and I believe that that were a number of ancient Greek and Chinese philosophers who said something very similar.)  Assuming that you want a website, the first question that you need to answer is “Why?”

  • Why do you want a web site, and what do you expect the web site to do for you?  You must be expecting something from it or you wouldn’t be doing it.  Some possible areas are improving reputation, improving public awareness, providing assistance or entertainment to others, providing a place to share information, assisting in the operation of an organization or business, making you feel better, helping you to make money, and helping you to reduce costs.
  • How would you describe the typical person you expect to be a viewer for the web site?  You may want to provide a few different types of descriptions.  (Think novice, intermediate, expert, hobbyist, professional, etc.)
  • What do you expect the web site to do for the viewers?  If the web site doesn’t have value for the viewers, they won’t use it.  Many of the possible areas are the same as the same benefits that the creator of the web site expects to receive.
  • How do you expect viewers to find the web site?  There are a number of possible methods.  Don’t spend money on advertising or boosting the site until you have first gone through the free methods.
  • Why should viewers come back to the web site after seeing it the first time?  I have seen some websites where I literally have no idea of how to use it, where images and flash animations take so long to load that I shut down the browser before the first page loaded.
  • How are you going to assure that people don’t run away from the web site screaming in panic?  A blind person will be very frustrated with a web site where all of the information is shown as images, and a deaf person will be very frustrated with a site where you need to listen to a spoken voice?

Don’t try to provide lengthy essays for each question.  A paragraph or two is sufficient.


Once you have answered these basic questions, it is time to do some research.

  • Try to find some web sites that are similar to what you plan to do, and look them over.  What do you like about them and what do you dislike?  How are they organized?  Try to make a list of the various sections and what they do?
  • Find some web sites that you really like and look them over in the same way.  What do you like about them, dislike about them, and how are they organized?
  • Get a book out of the library on creating web sites and read through it.  You aren’t going to try to memorize it, just get some ideas.
  • Try looking at a few tutorials (either written or video) on creating web sites.

Requirements Planning

What are the “use cases” (also known as “user stories”)?  These are the things that people should be able to do with the web site.  If the web site has user accounts, some of the standard situations would be the following.

  • Create a user account
  • Allow the user to deal with a forgotten password
  • Log in to the site
  • Log out of the site
  • Change the profile information for the account
  • Set a message to the web site administrator

Depending on the web site, some other situations would include the following.

  • Participate in forums
  • Create and read blog entries
  • Join a mailing list and remove your name from the mailing list
  • Obtain information about the organization or business, including its products, activities, and events
  • Obtain support from the organization or business
  • Look up items in a catalog
  • Order items from a catalog
  • Pay for the items ordered from a catalog (Credit cards, PayPal, etc.)


At this point, you can start making a list of the pages that will appear on the site.  The idea is to start with a very rough layout and then refine it in successive iterations.  You start with a list of a few pages together with a few sentences about each page.  For example, here are some common examples.

  • Home page – The home page is the page you see if you enter only the domain name and port number for the server.  The main purpose is to let the viewer know within a few seconds that the web site will be useful or helpful to him.
  • About – This page describes the organization or business behind the web site in more detail and also includes more information about the web site itself.
  • History – The history of the web site or the organization or business that it represents
  • Blogs – Blogs are essays that are placed on the site and are of interest to the viewers.
  • Forums – Forums are areas where the viewers can have discussions and exchange information
  • Online Store
  • Entertainment
  • Calendar

Next Step

After this you can start designing your web site.  This will involve a number of steps that will be covered in later posts.  However, the design process can be considered as comprising the following.

  • Refining the descriptions of the pages
  • Refining the requirements
  • Verifying that the pages will satisfy the requirements

You will then be able to start the development.  The design and development steps can be combined, but not doing the planning first will cause you to have to redo a lot of work.



WordPress Installation Problems

In working with WordPress, I have run across a few problems where the manual appeared to be assuming the administrator to have information that is not obvious from the documentation.  I give you this so that you can learn from my past mistakes without having to repeat them.

Configuration Files

There are a few different configuration files that the user should be aware of.  Since the software packages may be downloaded from different sources, the configuration files are not always consistent.

  • httpd.conf (/etc/apache2/httpd.conf on my system)  This is the configuration file for the Apache web server.  Since WordPress requires PHP, the line reading LoadModule php5_module must be uncommented.  (Remove the hash sign at the start of the line.)  If the line is commented, the PHP files are sent to the browser instead of being processed by the PHP module.
  • php.ini (/etc/php.ini) This is the configuration for the PHP module for the Apache web server.  When working with UNIX/Linux systems, the parameters pdf_mysql.default_socket, mysql.default_socket, and mysqli.default_socket must match the value in the my.cnf file.  On at least some versions, this appears to be /var/mysql/mysql.sock.  On my system, I edited these values to read /tmp/mysql.sock. Uncomment the lines in the configuration file that you wish to use. (Remove the hash mark at the start of the line.)  If the values don’t match, this will result in errors declaring that a database connection can’t be made.
  • my.cnf (/etc/my.cnf on my system) This is the configuration file for the MySQL database software.  You can use this file to specify the UNIX/Linux file to be used for socket communications.  On my system, the default is SOCKET=/tmp/mysql.sock, but it seems some releases may have different values.  The important thing to remember is that in UNIX systems, this value must agree with the socket file in the PHP configuration file.  Uncomment the lines in the configuration file that you wish to use.  (Remove the hash mark at the start of the line.)  If the values don’t match, this will result in errors declaring that a database connection can’t be made.


Some of the plugins, such as BuddyPress, require you to allow mod_rewrite.  (See and  This requires two changes to httpd.conf.

  • Uncomment the line that reads  #LoadModule rewrite_module libexec/apache2/
  • Look for the section that reads <Directory /xxx> where /xxx is the directory containing the files for your web server.  If there is a statement here that reads AllowOverride None, change it to AllowOverride FileInfo.  If there are already other attributes there, add FileInfo to the list.

File Ownership

Since WordPress makes changes to the files in the Documents directory of your web server, you must ensure that PHP uses the account that owns the files.  For UNIX/LINUX systems, the account information is given by the parameters User and Group in httpd.conf.  The UNIX command chown can be used to change the ownership of all of the files for the WordPress site recursively.  (My system uses _www as the account name.)

The Wrong Way

I have seen the following on some forums, but they seem to show a lack of understanding of the underlying situation.

  • Some people have gotten around the problem with the socket file name by using in the URL rather than localhost.  This causes the system to use TCP/IP instead of UNIX sockets for communication with the database.  Although this works, there are some advantages to using sockets.
  • Some people have handled the file ownership problem by setting the file permissions on the files to read, write, and execute globally.  This is a big security problem.


The section entitled mod_rewrite was added 18-February-2017.

Holiday Hours

On Christmas Day, I was looking for a place to eat. I checked with the Burger King app and it said that the local store was open. However, when I went there, I found it was closed. The following is the response from Burger King.

Apologies you ran into issues with listed hours at your local Burger King! Burger King locations are closed on Christmas Day and unfortunately store hours within the app are not dynamically reflected, so we apologize for any inconvenience this may have caused.

I saw a few big problems with this attitude.

  • If all Burger King locations were closed on Christmas, it should have been easy to have the app display that information instead of saying that the store was open. At least they should indicate that Christmas and Easter Sunday hours may be inaccurate.
  • The website indicated that Burger King stores are open on Thanksgiving, but the hours may be different. Since the app doesn’t adjust for holiday hours, that means that the hours for Thanksgiving can’t be trusted.
  • They don’t see a problem in the fact that I can’t trust their information.
  • I’m not saying that I won’t eat at Burger King in the future. But I am saying that they suffered a self-inflicted wound against their reputation.

Applications like Google Maps, Google Search, Apple Maps, and Yelp have ways of indicating holiday hours on the listings for their businesses. Listing this information will increase the trust that people have in your listing.

If you are going to be closed on a holiday, have you considered listing nearby locations that might be open on your site. If you can supply a potential customer with useful information, he is more likely to come to your business and web site in the future.

Putting Your Business on the Map

If you have a “brick and mortar” store or restaurant, you want people to be able to find it while traveling with their smart phones. Even if a page for your business already exists on Yelp, Google Maps, and Apple Maps, you want to claim ownership of the information on these pages so that you can insure the accuracy of the information and make it as attractive as possible.


This information is for stores, offices, and restaurants having a fixed street location and are not run out of a residence. The procedures may also differ for some countries other than USA. It should also be noted that some of these web sites frequently make changes and their help pages can be extremely unhelpful.

Claiming A Page

Apple, Google, and Yelp have special web sites for businesses wishing to claim and manage the information on their businesses.

  • Google – The site is and it uses the standard Google accounts. The information entered on this site is used for both the Google search engine and Google Maps.
  • Apple – Management of the Apple Maps pages is done via and it uses the Apple ID accounts. This site is used for controlling the location of the map pins for the businesses, while the rest of the information is taken from Yelp. You should note that Apple Maps is not accessible via the web. You will have to go to an Apple iOS application for the iPhones and an Apple OS X application for laptops and desktops.
  • Yelp – Go to the site to manage your Yelp page. Yelp is different in that many of their sites have separate systems of account names and passwords. An account for will not work for You will create the account for when you claim your first business page.

The process for claiming a page is fairly similar across the three vendors mentioned above.

  1. When you first log on to the site, you will be shown a web page showing the business pages that you manage, and there will be a button to click for selecting an additional business location. If you haven’t claimed any business pages yet, you will start with the page for selecting an additional location.
  2. You will insert the name of the business and at least part of the address on the web page. For USA locations, the city and state will often be enough. For other countries, enter the location as if you were sending mail from another country. (e.g. London Ontario Canada or London United Kingdom) The next page will show you a list of businesses that match the criteria. You may have to supply the street address if there are too many listings.
  3. If you can’t find an entry for the business, it is possible that the name of the business has changed since the reference database for the site was last updated. Try the old business name. There should also be information on the page about how to enter a new business. However, this may cause a delay because it will have to be verified.
  4. When you go through the process, a message should pop up indicating whether the business location has already been claimed. If it has already been claimed, it is possible that somebody else working for the business has already claimed it or it may have been claimed by a previous owner. There will be information on the page on how to proceed if you believe that the page should be available.
  5. After you select the business, you will be asked to enter information about the business location such as hours, type of business, links to other web sites, etc. After entering all the information, you will be asked to confirm your identity.
  6. The databases for the sites have telephone numbers listed for each of the businesses. The system will call the telephone number and one of two things will happen: the telephone number will contain a number to be entered on the web page, or the web page will contain a number that will be entered via the telephone.
  7. You have now claimed the business page and can use the web site to manage it. If you are using Google or Apple Maps, you should make sure that the map pin is where you want it. For a number of reasons, the location of the pin may not be where you want it. The database used by the site may only have data for selected street numbers and may be interpolating for the rest. There may be an error in the address. In addition, you normally want the map pin to fall at the customer entrance for the business. In other cases, you may want it to fall where the drive leading to the business enters a public road.

This blog entry was previously entered on LinkedIn as


I will be adding some links from time to time which will provide additional information.



Keeping Anchor Names Unique

When using HTML anchor (<a>), it is necessary to insure that no two anchor tags on a page have the same name. Otherwise, the result of clicking on links can be unpredictable. Since WordPress may show several posts on a single page, this means that each post must use unique anchor names.

My old method

When I started this blog, I used the HTML string <a href="#x"><sup>x</sup></a>, where to indicate a link to an item in the reference list, where x is the item number. The item in the list would then start with <a name="x"></a> x.

This seemed to work fine, but then I tried using the links on the home page where multiple posts were displayed. Instead of going to the reference that I desired, it would go an anchor in another post that had the same name.

My new method

The first thing that I decided to do was to use unique prefixes for each post, such as aa, ab, ac, …,az, ba, bb, etc. This post uses the prefix ab.

The first item in the reference list is Unicode Character Table – Arrow Sets1. The superscript 1 at the end of the previous sentence is the link to item in the reference list and is coded as <a href="#ab1" name="ab1b"><sup>1</sup></a>. The suffix of b at the end of the name indicates that this is the anchor that points to anchor ab1.

The item in the reference list then starts with <a href="ab1b" name="ab1">↑</a> 1. The up arrow ↑ is a special code entered as an HTML literal using the HTML tab of the editor or using special characters entered via the Visual tab of the editor.

I will eventually alter all of my posts in this way, but it may take a while.


Javadocs and Maven

Note: The code samples discussed in this post are available at while the documentation can be found at This project uses Maven. Although you don’t have to use Maven, the comments in the pom.xml and other configuration files provide a great deal of useful information.


As I mentioned in a previous post1, documentation is required in order to understand and debug the code. The Javadoc tool from Oracle provides a means of documenting Java code with the software development software itself carrying out the bulk of the effort.2 Meanwhile, the Maven pom.xml file provides a mean of providing additional information about the project in a computer readable manner.

  • By processing the source code, it can generate a document that lists all of the classes in a project, including descriptions of the methods, fields, and constructors. Since it generates this information from the source code, it will always be up to date.
  • It provides a method for the programmer to insert additional information into the document by reading specially formatted comments in the code.
  • The Javadoc can contain the complete source code, with links from the detailed descriptions of the fields, constructors, and methods taking the user to their location in the source code.
  • It is possible to link the Javadocs for libraries used by the project to the Javadocs for the project itself. This can make it
    much easier to review the code.
  • Using Maven and Javadocs together allow you to get a great deal of useful documentation for little effort. When the Agile Manifesto4 states Working software over comprehensive documentation, this is because of the Law of Diminishing Returns5. Spending too much time on documentation is wasteful, but not documenting at all will cause major problems later.

Like other Maven plugins, the Javadoc plugin has a number of conventions concerning where the files should be placed.6 These conventions will be discussed in terms of the tutorials example.


The bradleyross/tutorials project on GitHub is a package that I wrote to provide some examples for various lessons and tutorials.7. Documentation for the code can also be found in GitHub.8.

  • Each Maven module should be located in it’s own directory on the server containing the documentation, and the Javadoc should be contained in the subdirectory apidocs for that directory. The main directory for the module is then placed in the pom.xml file using the tag url. For the tutorials-common module, the URL for the module documentation is while the URL for the Javadocs is
  • The modifications to the pom.xml file can be placed in either the module for which the Javadocs are being generated or in the parent module. I placed them in the parent module for simplicity.
  • The overview for the module goes in the file src/main/javadoc/overview.html.


Java Logging Frameworks

Note: The code samples discussed in this post are available at while the documentation can be found at This project uses Maven. Although you don’t have to use Maven, the comments in the pom.xml files provide a great deal of useful information. The Javadoc files also contain links to the source code and other Javadoc libraries.

I am going to be revising this a little, but I wanted to get this draft out.


After discussing the mental attitudes for debugging, it is time to discuss the tools and techniques that can be used in debugging in Java. Many of the Java open source libraries make use of the various Java logging frameworks (also known as logging services). Using a Logging Framework greatly simplifies verification, testing, and debugging. Not having a working logging service makes it almost impossible to verify the proper functioning of your code. The vast majority of programmers use the Apache logging frameworks (

API versus Implementation

One of the first things that you have to understand is the difference between the API’s and the implementations. The API is the set of class names and method signatures that you will use to actually place items in the log. Examples of code that places messages in the log can be found in the package bradleyross.library.debugging package in the tutorial-commons module.

There are actually multiple implementations of the API’s. There is one set that is based on the log4j 1 logging framework (See the dependencies in the pom.xml file in the tutorials-log4j1 module.). Another is based on the log4j 2 logging framework (See the dependencies in the pom.xml file in the tutorials-log4j2 module.). There are many classes in the log4j 1 implementation that have the same name as those in the log4j 2 implementation. If you use the wrong combination of classes, the logging software will not work correctly and may not work at all. (One of the major dangers is that you may think it is working correctly, but it simply isn’t displaying the error messages.)

The logj4 2 implementation is currently the only API being maintained. It is also capable of supporting all of the API’s supported by the log4j 1 and slf4j implementations. The syntax for the configuration file differs between the log4j 1 and log4j 2 implementations, but creating a new configuration file is not that difficult.

Java Exceptions

I am assuming that the reader is familiar with the nature of Java exceptions. If you feel uncomfortable, the Oracle web site
contains a tutorial on exceptions.2

Java exceptions can be either checked or unchecked exceptions. Unchecked exceptions will be passed to the next higher object in the stack unless a try/catch block captures the exception and processes it. (If you are already at the highest object in the stack, the program will halt and an error message will be generated.) If there is no try/catch block processing an exception in a class and the exception is not listed in the throws clause of the method signature, the program will be halted when the exception is passed to the next higher class in the stack.

Catch and Release

When you are trying to test or debug a program, you want to ensure that your log statements do not alter the flow through the program. The approach that I take to this is what I call the Catch and Release method. When you capture the exception, log it and then throw it so that it goes to the next higher object in the stack.

Consider the following snippet of code.

LineNumberReader input;
File file;
try {
     file = new File("reports.txt");
     input = new LineNumberReader(new FileReader(file));
     String data = input.readLine();
     if (data != null) {
} catch (FileNotFoundException e) {
          logger.warn("File not found", e);
          throw e;
} catch (IOException e) {
     logger.warn("IO exception", e);
     throw e;
} catch (Throwable e) {
     logger.warn("Unexpected throwable", e);
     throw e;

Because I am throwing the exception after logging it, the flow of the program is unaffected. After logging the information, the exception is passed up to the next higher structure, which is what it would have done originally. There are cases where I won’t want to throw the exception, but not when all I am doing is logging it.

Where to Test

The following are some guidelines for inserting logging statements in the code. In inserting these log statements you have a choice of several warning levels. (The most severe is FATAL, with the levels ERROR, WARN, INFO, DEBUG, and TRACE following in order of decreasing severity.4)

  • Every catch block should contain a logging statement.
  • If there is a throws clause in the method signature, consider placing a try/catch block around the entire contents of the method. This may enable you to get more usable information.
  • I should have a try/catch block everywhere I believe that something might go wrong.
  • There should be log statements after an operation has taken place successfully. To prevent the size of the log from becoming unmanageable, you can alter the levels of the log statement. By putting these messages at the DEBUG or TRACE they will be available for debugging but won’t clog the system while running normally.

Encapsulating Logging Statements

You want to get as much information passed in the log statements as possible. However, writing all that code can be a burden. The way to do this is to encapsulate the log statement in a helper class such as bradleyross.library.helpers.ExceptionHelper in the tutorials-common module. As an example, SQLException contains some more information than most exception classes, and this code is designed to detect SQLException and print the extra values.

Another possibility would be to write an additional method or class that can process file-related errors. Such a method would have the File object and the file name as parameters and then place additional information in the log such as size of the file, whether the file exists, type of file, and read/write permissions.

Throwing Exceptions

When you throw an exception, you should always consider throwing a subclass of the standard Java exceptions. (Throwable, Exception, Error, RuntimeException, IOException, SqlException, etc.) This is something that you may be able to take advantage of in the future.

Attitude and Philosophy

The term “expect the unexpected” definitely applies to debugging code. The following are some things to keep in mind.

  • You don’t know how the code will be used in the future.
  • You don’t know who might make changes in the future or what changes they might make.
  • There is a very good chance that errors will be introduced into the code. Furthermore, the existence of these errors may not be detected until long after all of the programmers have left the project.
  • Descriptions of errors by users will often be incomplete or misleading.
  • Your log messages should contain enough information to determine the location of the problem.


World’s Best Debugging Tool

I have debugged many programs during my career, and I have assisted many others in debugging programs. I have also seen many people fail to get their programs working. I’m going to use this article as a means of helping others to get their programs to work. To put it bluntly, the best debugging tool and the one that must be used is a good attitude.

Will Rogers often said “It isn’t what we don’t know that hurts. It’s what we know that ain’t so.”1 (Yes, I know that others said similar things before him, but a video of Will Rogers is where I first remember hearing it.) When debugging software, there are many bad attitudes that people believe are actually good attitudes. Believing in things that are false will cause problems, and refusing to reconsider is a bad attitude.

A good attitude would be to seek methods and processes that are appropriate for debugging software. Other entries will discuss how to debug once you have a good attitude. For the moment, let’s discuss a few common beliefs.

Debugging Is Not Agile

There are people who will say the appropriate means of fixing bugs is to use Agile Scrum or one of the other Agile methodologies. Saying that Agile is the best for all situations or even that it is appropriate for all situations is a bad attitude.

The acronym INVEST (independent, negotiable, valuable, estimable, small, testable) has been mentioned as a means of determining whether a story is appropriate for Agile, while the acronym SMART (specific, measurable, achievable, time-boxed) is used to evaluate goals.2 Let’s first investigate the suitability of debugging as an Agile story.

  • Independent — One error in coding may result in multiple bug reports and a single bug report may actually involve several errors in coding.
  • Negotiable — Bugs are symptoms of coding and design errors. However, you don’t know how serious the errors are until you find the error. When you go to a medical doctor, small symptoms can be signs of serious illnesses, and the doctors run tests until they find the cause. If you don’t know how serious the problems are, you can’t determine which bugs have the highest priority.
  • Valuable — At last we have one for the positive column. Debugging is valuable.
  • Estimable — Finding the cause of a bug may take just a few minutes or it may be weeks.
  • Small — Since the effort required to fix a bug is virtually impossible to predict in advance, you certainly aren’t safe in saying which problems will be small ones.
  • Testable — On the positive side, it is possible to see if a fix removes the appearance of a bug. However, it may not be possible to test whether the root cause of a bug has been fixed.

Debugging Requires Doumentation

There are people who say that there is no need to prepare documentation when debugging because the Agile Manifesto states “Working software over comprehensive documentation”.3 There are a few problems with this attitude.

  • The manifesto mentions working software. If the software was working, you wouldn’t need to debug it.
  • The manifesto mentions comprehensive documentation. So they are really talking about the amount and kind of documentation.
  • Another statment reads “Individuals and interactions over processes and tools.” I interpret this to mean that you must reconsider the agile methodology if it interferes with individuals getting their work done or interacting with each other.
  • If all items on the left are more important than all items on the right, the last statement would mean that processes and tools have very little value. If that is what you believe, why do you believe that the agile process is valuable?

By the way, if I have to debug a program with no documentation, the first thing that I do is to read the software and make notes. Another word for those notes is “documentation”.

Other bad attitudes

Before the complaints start, I want to make it clear that there may be some validity to some of the comments listed below. You are going to have to release software at some point. However, the following types of statements are often used as excuses for releasing software way too early. You need to be able to justify these rather than using them as excuses.

  • It’s not my job — If you have a problem and it’s not your job to fix it, whose job is it? Are they actually working on it and are they able to do it? Is it a problem for you if nobody does it? If it’s not a problem for you but is a problem for the organization, aren’t you part of the organization?
  • It’s good enough — I follow a simple rule of thumb: if somebody says it’s good enough, it usually isn’t. A similar attitude is feeling that there is nothing that you can do to make it better.
  • We don’t have to worry about that — The classic case for this is not worrying about errors in the subroutine libraries, the data provided to the programs, or the ability of other programs to utilize the data your program generates. This is a bad idea. (I have found that when people say say something goes without saying, I really do need to say it.)
  • We can’t risk anyone learning that we made errors — If nobody made errors, you wouldn’t have to fix it. The users are usually going to find out about the errors later. If you find and fix the errors before the users find them, the users won’t know you made any. If your team can’t survive anyone finding out that anyone made errors, you have big problems. The only way you can truly cover yourself is with success.

The Scientific Method

I was trained as an engineer. So I approach debugging as simply another engineering problem. A good starting approach is the scientific method, using the following steps.

  • Collect information — Collect information about the bugs and the software that you are trying to use. To the extent possible, this information should be collected in a format that can be processed by automated procedures. Some of the information will be the bug reports, the source code, log files, knowledge about the subject matter, and knowledge about the automated systems used by the process.
  • Analyze collected information — Go through the information to try and detect patterns. In some cases, it may be possible to use automated tools to help with the analysis.
  • Generate potential hypothesis — Potential hypothesis would include possible locations where problem might occur, and possible situations which might result in errors.
  • Design experiments — Possible experiments would be creating test data sets and situations. Inserting code to create messages and using debuggers is equivalent to adding instrumentation in a physics experiment.
  • Run experiments and evaluate hypothesis — After you run your experiments (tests), evaluate the original hypothesis.
  • Create a potential fix and test it — Use the information to put fixes in the code, and see if the problem goes away.
  • Continue until everything works