Only one line of code needed

The above statement is pretty profound if you think about it.  Can a program run with just one line?  Why would you write a program with just one line?

You really cannot write a fully functional program with one line.  The abstract principle here is the fact you have to think about not only get the job done but writing it in a few lines as possible.  Long ago when COBOL was king, programmers where suppose write 10 lines of debugged code per day.  Although that standard was so little because it took hundreds of lines to get anything accomplished and most COBOL programmers could write hundreds of lines per day.

The principal behind a single line of code is simple.  You have only one point of failure.  But realistically if you write 100 lines of code that can easily be debugged and your coding partner can write the code in 10 lines, whose is better.  If those 10 lines of code are easily debugged, then the winner is your coding partner.  You on the other hand will be working harder and longer for the rest of your coding life.

Windows XP had about 45 million lines of code.  Windows 7 has around 80 million lines of code.  It has been said that Linux Kernel has grown from 10,000 lines when it first came out to around 15,000,000 lines. Each line that gets added while none of lines are removed is good for employment but not so good for the employer that is trying to compete with the new OS or application program that is smaller and functionally better.

What this shows is that as you add more functionality to your code it grows and becomes this monster that not a single person can maintain any more.  So the goal is to add enhancements and bug fixes without impacting the total number of lines exponentially.   Can I make this change if think about in 40 lines of code instead of 300?  That is the important question that must be answered every time a line of code is needed.

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.

Is there a Dinosaur sitting next to you?

Sometime in the near future you will look at your coding partner, or your fellow programmers, or even your boss and wonder if you are ever going to start coding like you live in this century.  It is something we must do every now and then when people find out you are coding in BASIC.  Really UniBasic is not Dartmouth BASIC which was created in 1964.  No we are using a language related to Data/Basic from its big commercialization in 1973.  It has some similar conventions as Dartmouth BASIC and the same thing can be said of JavaScript and Java.

If you write programs that, for example have variable names like "A" or "B", then the dinosaur is not sitting next to you, it is you.

If you cannot spell out the word count and use CNT or CT, then extinction might be right around the corner.

If we cannot name programs to match the functionality calling them Wh200 which should be something like Warehouse_EDI_Subroutine, then you are becoming a DoDo bird.

If you continually use archaic tools like AE (Alternative Editor), ED (Editor), or plethora of the other names strategically not mentioned, then you may find our self's looking for a job in a shrinking environment.

If you have seen the word "Version Control" but think you should save the old version of the program in a file called BP.OLD, the world is getting a lot colder than you realize.

If think that your editor should not be auto correcting as you type, then you cannot see the forest through the trees and maybe the T-Rex will not get you.

If we think that your manager does not know anything of how you do what you do, then you are in for a long winter this summer.

At U2logic, we are enjoying ourselves with state of the art tools and processes, so we are neither too cold or too hot.  Check us out at our web page at www.u2logic.com/tools.html.

The Big Lie

So what is the big lie you should be asking yourself?  It is the fact that taking applications from the green screen to the web is easy and/or fast.  All of the software vendors sell this.  Here are some gleaned from their current web pages.

"...provides a wealth of end-user capabilities allowing the developer to rapidly create feature-rich, high performance applications.."

'Rapid application development for multivalue"

Web development can be fast and easy if you are converting or creating a simple screen.  Simple screens it turns out are a significant number of the forms that are done, however, they compromise only 5 to 15 percent of the time of development.

Lets talk about normal forms and where the time is spent.  Depending on which tool you use, some of your time is divided in setting up the objects to allow the translation of variables from Universe and Unidata to the web, and designing the form or re-designing the form to fit the web.  The rest of you time is either writing the JavaScript to run the custom features you want and modify or writing from scratch the UniBasic subroutine that handles the business logic.  For example, business logic might be where we are allowed to buy this dollar amount from this vendor or only these particular products.

The last part of Web development that no brochure or web page talks about is debugging the four headed monster you just created.  It is the UniBasic code, JavaScript, HTML, or objects that are causing my form to function unexpectedly.  A good rule of thumb is them more complex the form, the more complex the debugging.

Here is the figure you should use on most Web form development.  For example, if this form took about 20 hours to develop count on 40 to 60 hours to debug, pass quality assurance, and client approval.

BTW: U2logic's XLr8Developer hardly ever uses the word rapid to describe the web development process.  If we do we are speaking of those code file Web entry forms.

What your web site says about you

It has been almost 2 years since we overhauled our web site and it was time to do again.  I have been visiting web sites with my iPad2 to see what others in the industry are doing.  Some worked well for the iPad format some did not work at all.  I'm not even going to talk about the Flash sites which could be a whole blog itself.

I ran across a competitor's web site that sells a resize tool like U2logic's XLr8Resizer for the Universe and Unidata databases.  I right clicked using that handy dandy option where you can see the source code.  Low and behold their web site was written using Microsoft's Front Page 4.0.  I knew this site was ancient because of the references to Windows NT and Windows 2000, but how do you get a tool to run from 1996.  You don't, you just don't update your web site.

Now to answer my question proposed in the title.  What does your web site say about you?  In the above case it says you are hopeless out of touch with what is going on and you want to milk all of your users for technology that was good enough 10 to 15 years ago.

That my friends is why we are constantly updating our web site. Today our web site uses jquery and some free software that allows the web site to show a slide show.  The site even supports accordion views of data.  All of this was tested on Firefox, Chrome, IE and the iPad.

Our web site does reflect that we constantly keep our Eclipse based XLr8 tools upgraded and relevant as technology changes and users preferences evolve.  Check us out at www.u2logic.com and see if web site reflects our commitment to excellence.