Crazy release strategy (CRS)

Whether it is Facebook, or LinkedIn, or now even Microsoft, software changes will be released at least on a weekly basis or even daily basis by these companies.  Not to mention Google, Mozilla, or Oracle that are releasing software and a continuing basis for many years, this is a trend that it only escalating.

The quality assurance departments of those companies are either pulling their collective hair out or rejoicing in that the daily changes are far easier to test than changes that have taken the company many months or years to produce.  Probably many companies are just releasing software and hoping for the best outcome like Google did for years with the word Beta on the software page you were running.  Do we really know or really care?

What all of the CRS means that changes have to be drilled down to their smallest element.  The maximum time for those code changes and bug fixes are reduced from months and weeks to hours.  That means the programmers must have a laser focus as to the problem or enhancement and not worry or even think about the other ramifications of this change.  Those issues should have been already thought of by the person filling out the bug or enhancement request.

We here at U2logic have put out 25 plus releases this year for our flagship XLr8 Tools product.  There have even been some days that we have put out 2 releases in a day for various reasons.  One particular reason was the feature was requested by a user in the morning after we had generated a release and that user needed the release today.  We put out another release late in the afternoon with that feature.

In order to keep some control of your CRS you must have a good version control.  Another indispensable product is bug tracking system.  At U2logic we are using SVN for version control after using CVS for many years.  We are using Bugzilla for bug tracking because there is a built-in interface for Eclipse.  You never have to leave the Eclipse environment to version control, bug tracking, and programming.

For those applications developers, we at U2logic have been updating our code on a daily basis and sending it through our XLr8Installer to our customers.  Some days the customers could get multiple fixes and enhancements.  Does this sound like a Universe or Unidata programming shop?  We think not.

This CRS really is Crazy Release Strategy not Continuous Release Strategy.

The Best Programmers have OCD

Sometimes talking, or in the case blogging, about a problem is a good thing.  I have been thinking what makes a good programmer.  Why is this programmer better than another?  Why can some programmers remember their code while others forget it minutes after typing it in?

Maybe the good programmers have some mild form of OCD (obsessive compulsive disorder).  The one symptom that seems to fit was constantly check and re-checking things.  I cannot tell you how many times I look at code and look at code and look at code to see what I have written is okay.  But the difference, with me at least, is that I can do this in seconds not minutes or hours.

There is many a time while driving, sleeping, eating, or doing chores that I figure out what is wrong with a piece of code. That I believe is the obsessive portion of my brain.  I cannot stop the process whether it is conscience effort or by letting to code lie like a sleepy dog.

Maybe it that obsessiveness that creates programmers that are the best.  None of their code is good enough.  The brain never stops. They strive to be the top of their profession but do not always work well with others. The skill set is well defined not to one style of programming or even one language type. They are more than bilingual.  They are a polyglot of programming languages built into a bundle of "nerddom".

Probably the most distinguishing feature is they sometimes tackle projects and quickly hack the code.  Whether the code is pretty or good that is not the point.  The point is that the code is done and finished quickly and can be improved on the next iteration.

Here is what  Mark Zuckerberg's letter to investors February 2012 about the hacker way:

The word "hacker" has an unfairly negative connotation from being portrayed in the media as people who break into computers. In reality, hacking just means building something quickly or testing the boundaries of what can be done. Like most things, it can be used for good or bad, but the vast majority of hackers I've met tend to be idealistic people who want to have a positive impact on the world.
The Hacker Way is an approach to building that involves continuous improvement and iteration. Hackers believe that something can always be better, and that nothing is ever complete. They just have to go fix it -- often in the face of people who say it's impossible or are content with the status quo.

Sometimes the OCD programmer is someone you would never guess has it in a million years.

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.

Your company killed your skill set

It is probably not intentional that your company is actively killing your skill set or maybe it is.  A better view is that they refuse to train you in any new technologies because of your age, or the fact that their applications you are maintaining are hopeless out of date, or change is not something that they want to embrace for business reasons.

Many years ago when my former partner discussed where the U2 (Universe and Unidata) industry is going, he believed that we would always make money as consultants.  Since most of our clients we were their IT department that seemed like a safe statement.  When the economy does is down cycle, then the first people that are out of work are the consultants whether you are running your clients business software or not.

Our U2 world with its plethora of "green screen" applications with the accompany tool sets written by staff that has a lot of learning to do.  Whether it is education of the current IT department, with seminars, or in-house training, or even enrolling in University sponsored, management must embrace it.

Enrolling in U2 University is a start.  But the learning at U2U is more of a walkthrough of current technology and will not help those who do not know what data objects are or even there is a format called JSON.  The web, the resource at your fingertips, is the best place to start.  Some programmers spend hours and hours reading articles and taking on-line study guides.

In summary, your company has a lot responsibility to have you highly trained.  But the question is will they spend the money?  More importantly, you have to push you company to embrace new technology and you have to have gained the knowledge to help them along this course.

ABS Brakes and U2 Databases

While my life experiences were flashing before me in the few seconds before my ABS brakes gripped the frozen payment in front of a stop sign, I thought how similar this braking system was to U2 databases.

ABS was first introduced in late 1920's by Gabriel Voisin for stop his aircraft without blowing tires.  It took until 1970's when Ford and General Motors first put them on mass production cars.  Around the early 1990's you could get ABS brakes as option on most cars.  ABS brakes took some where around 60 years to refine the technology for the masses.

The Pick database the precursor of U2 databases Universe and Unidata was started in 1973 with the release of Microdata version.  In around the middle 1980's Universe and Unidata we started.  We are 40 years in to this technology.  Hopefully, before the next 20 years main stream users, programmers, C-suite people, and the media will find out revolutionary these databases can be.

I believe we won't have to wait another 20 years to harvest this technology.  I, with my team of programmers, have created our suite of tools using Eclipse IDE.  Our XLr8Editor allows editing of programs, dictionaries, procedures, paragraphs, and data with built-in version control.  With our XLr8Resizer you can resize your account with a few click of the mouse.  Our XLr8Installer allows you to build a XML install script you can run to build you software accounts for your internal use or for your customers.  Our XLr8Developer and XLr8Object Editor the help you create these wonderful web pages using our middle-ware call U2WebLink.

U2logic offers free trials on all of our tools.  With U2logic there is no capital investment you just pay maintenance every year to get access to all bug fixes, releases, and email support.

Scope is either local or global, but not here

Having an animated discussion with a Java programmer is not always the best way to start or finish you day. Java programmers have a valid point about the strong typing of variables that Java requires. This was no contest with Java and UniBasic, because I have spent the better part of the last two weeks changing our Java U2WebLink. I really know what scope is after trying to figure out why Eclipse editor kept pointing out to me that I had my code in the wrong area for the try/catch loop to work.

Had I not been programming in UniBasic so long, I should have known what variable scope is. All of the variables you create in UniBasic are global, so what is the local scope thing anyways. Wikipedia defines local scope as: “…a variable that accessible only from the function or block in which is declared.”

In UniBasic a variable is assigned through a couple of ways. It must be on the left side of any operation such as math or string manipulation. You can introduce variables through Common statements, includes or my perennial favorite Subroutine calls.

So now you ask yourself how a UniBasic programmer keeps track of all of those variables. Surprise I don’t. That’s right I don’t. If the programmer before us was good or bad I don’t sometimes care with how prior programmer handled the variables. If the program is working then the variables are handled correctly. When the program starts malfunctioning then I have to care and must trace the problem.

That is where the fly is in ointment. UniBasic programmers have no tool to show us where all the variables are assigned or re-assigned which Java programmers have built into the Eclipse Java Editor.

U2logic has begun to approach this problem in our XLr8Editor that is based on the Eclipse IDE. Hopefully, in the next few months I will have something positive to show that UniBasic programmers can control their scope as well.

Horse Blinders for U2 Programmers

Over the course of many years we have wondered why U2 UniBasic programmers still insist on coding with vi, notepad, ED or AE. The latter two are line by line editors that were developed in the 1980's and are installed with the database. So coding with horse blinders on seems to fit some of our esteemed colleagues.

Many programmers believe ED or AE keeps them focused on what is in front of them, encouraging them to pay attention to the code rather than other distractions. ED or AE programmers are commonly seen to help keep them from being distracted or spooked. See the real Wikipedia explanation http://en.wikipedia.org/wiki/Blinders and not the satirical piece that was co-opted in this paragraph.

That not to say they cannot do the job or that the job they do does not have value with those tools. The point really here is that some U2 programmers are stuck in the 1980's coding with those tools or have some hybrids that have been cobbled together from various open source projects. Why should we not be programming like millions of Java, C#, and VB programmers that have great tools.

We can have state of the art tools with full screen editors, reserved word colorization, syntax completion, cognitive help, local or database editing, search, local history change log, and version control to name a few of the new features. Bugzilla or other connectors can be attached to some editors an allow you to see what bugs you have to fix or software you have to enhance.

Some enlightened programmers live all day in their tool set and very rarely wander into the world of TCL (terminal control language). Of course, we know a few of them.

Eclipse platform is what IBM, the former owner of the U2 databases, believes is the integrated development platform of the future. Eclipse is used by hundreds of thousands of programmers. There are plug-ins for many languages such as Java, PHP, Cobol, C++, and C# to name a few that come to mind. There are thousands of other plugs-in to do whatever you can think of.

The Basic Developer Toolkit that is part of client software for U2 databases since 2008. The Basic Developer Toolkit is free when you upgrade your database. The other Eclipse developer is from U2logic, Inc. and it is called XLr8Editor. XLr8Editor has been on the U2 market since late 2006.

It time to change old habits and move to the 21st century.

Looking for the "one".

I have spent countless dollars and hours looking for the "one". I am not talking about the finding a significant other. What I am talking about is a tool for the Universe/Unidata world. Not a day had gone by when some programmer would announce the great tool since sliced bread. I cannot name half of them nor would I care to.

Today, except in some green screen software companies and those not enlightened, every one is looking for a way to GUI the interface for the multivalue applications. To say I found the solution for everyone is a brash statement that would need considerable facts that would be worth the effort. There are, however, some points that I have learned in this arduous process of taking code that is some cases over 25 year and moving them into our Web-enabled world.

I have a significant amount of business logic that I just do not want to lose or reinvent, so what did I do with all the Basic code. First, every program that had a user interface (UI) was removed. That's right I delete all of the UI from the Basic code. All that was left was just the basic code necessary to update the files and verify the integrity of that data or the business logic.

I found JavaScript a scripting language that is very close to Basic in many ways and unfortunately very close to Java as well. The validation of dates, numbers, codes, and even calling Basic Subroutines to verify inventory levels, was re-written in JavaScript. I, then, had a series of functions that could be called from any form and perform the data checking I needed to accomplish what I had been doing in Basic for many years.

I had not even found the "one", but I found a way to accomplish one of the goals without purchasing a product.

There is a great tutorial at W3Schools if you need help with JavaScript.