Debugging versus Logging

Being first to the market with our XLr8Editor for Universe and Unidata, we were asked why we did not have a debugger.  Most of the time the answer was that you could not hookup to Universe's RAID debugger or Unidata's debugger without Telnet session and some type of changes to both products.  After Rocket Software's BDT came out with a debugger we looked at what they had done.  Rocket Software had changed both Universe and Unidata to talk to Eclipse.  Now our answer was that we needed access to the API they wrote for Eclipse.

In "The Practice of Programming" the authors Brian Kernighan and Rob Pike state: "As personal choice, we tend not to use debuggers beyond getting a stack trace or the value of a variable or two. One reason is that it is easy to get lost in details of complicated data structures and control flow; we find stepping through a program less productive than thinking harder and adding output statements and self-checking code at critical places. Clicking over statements takes longer than scanning the output of judiciously-placed displays. It takes less time to decide where to put print statements than to single-step to the critical section of code, even assuming we know where that is. More important, debugging statements stay with the program; debugging sessions are transient."

We have found the debugger certainly has its place but we are not Fan Boys.  Whenever a program has HTML, JavaScript, and UniBasic code, how can you figure out where the problem lies?  Maybe you are not even getting to your UniBasic code and your error is in the JavaScript.  That is why we use Firebug's console.log statement in JavaScript which just prints out a log to the console.  In our UniBasic code we call a logger throughout our code.  This logger subroutine writes out data to a file which we can use later to figure out where our problem is.

We always do say that logging has its problems.  It can slow down an application and calls to the logging subroutine are sometimes left in long after the problem is resolved.  However, we find that the process is much cleaner and we can look at the output long after the program has been run.

Vindication of our Release Strategy

Many U2 (Universe and Unidata) programmers had disliked and voiced their opinion negatively when U2logic announced many years ago that our XLr8 Tools was going to 3 to 4 week release cycle. We felt that most of our bugs and enhancements could be released after they had been completed, unit tested and quality tested.  While Firefox, Chrome, and Safari browsers were getting released at least every month and half, we did not see any reason we could not do the same even though we have a smaller team.

Just the other day Rocket Software announced that it has been releasing it's Eclipse based tools almost every month since March of this year.  They also stated that they had fixed around 60 bugs, plus added many new features.  A competitor vindicates our strategy.

During the same period as Rocket Software, U2logic has enhanced and fixed over 140 items.  We should be patting ourselves on our back for a job well done.  This represents a lot of work from our staff of programmers, testers, QA's, and customers.

Whenever we are going through our Bugzilla items and deciding what we will tackle in the next few weeks, we are always aware of this mandated release schedule.  We have stopped working on some enhancements because they are taking too long and would contribute to a slower release schedule.

The question becomes can we keep this strategy going for more than a couple of years?  Is this strategy harmful to our customer base?  And last but not least, can we remember what the release numbers mean after 10 or 15 releases?

Just in case you have not updated your copy XLr8 Tools, the current release is 3.5.15 which was released yesterday.

Surprised, I'm over 40 and coding

Over the years I have discussed with my staff, at Spectrum Conferences, at CMUG meetings, and any other place people would listen about age and programming. When you get over 40, management starts looking at you and wonders if you can still code.  Somewhere the thinking goes that our coding brain cells die off or disappear after you reach 40.

With over 100 billion cells the thinking was that they die off.  According to USC Health:  "Now it is really clear that if you don't have a specific disease that causes loss of nerve cells, then most, if not all, of the neurons remain healthy until you die. That's a big change, and it has only come about in the last 10 years."

Over time some of my colleagues coding skills have declined but not due to the loss of brain cells.  I believe the loss of coding skills is part the lack of desire to push the envelope.  If you are learning something new at any age you will be making new neuron connections. The same article states:  "We expect to discover which environmental stimuli such as physical and mental exercise, are most likely to turn on new neurons in the adult brain."  This is like the old saying you lose if you don’t use it.

Just a few years ago one of my Java programmers was saying to me, you should learn Java.  I countered back that I did not want to learn a new language.  I had just a few years before learned JavaScript. One day a Java book arrived unencumbered on my desk.

A week later after mind numbing reading, I had finished the book.  I asked the Java programmer all sort of questions about inheritance, overloading, classes, and methods.  He smirked and answered all my questions.  My mind was very busy taking it all in for the next many months looking at our 500K lines of Java code.