Doc or No Doc, that is the question.

Doc is short for documentation. For most programmers it is not something we want to do are will do. Well then why not?

Let's look at what documentation is from MIT they say: "The formal description of a mechanical system or a technical process is known as its documentation. Documentation takes the form of technical and user manuals that accompany various technological objects, materials, and processes. Electronic hardware, computers, chemicals, automobiles all are accompanied by descriptive documentation in the form of manuals." Then they go to state that there are two types of documentation: user and technical.

There is another type, or sub-type if you will, that showing up all over. You will see as an installation manual with lots of pictures a very few words. It the equivalent of child's picture book. Yes, we have digressed to be very non-technical and show the user or technical person how to do something with screen captures and as few words as possible.  But if that works so be it.

What it still surprising is that no reads or even looks for the the documentation if you create it.  Even if it is the sub-type as described above, they do not look at.  Maybe that is why in today's editors have documentation as you type because most do read the manual.

Next time read the frigging manual and see what it has to say.  You might learn something after all.

Change before you have to

Sometimes in life we get to look back at what we have accomplished.
Sometimes in life we are up to our buttocks in alligators and our objective was to drain the swamp.
Sometimes in life we walk around and forget to smell roses as we are knee deep in UniBasic Code.
Sometimes in life we are doing the same thing and expect a different result.
Sometimes in life changes are inevitable.

Since 1993 the top person at Rocket Software U2 has been with Unidata, Ardent, Informix, IBM, and now Rocket Software.  Starting out a technical support person and currently holding the title Business Area Executive whatever that means.  As Jack Welch has said: "Change before you have to".  Well unfortunately with the current leader at the helm of Rocket Software U2, that will never happen.

Change is hard.
Change can be debilitating.
Change can be invigorating.

Whether you start at the bottom or in this case at the top, change must happen.  The Rocket Software U2 must look at themselves every so often and see where they are going which is more important than from where they have been.  For too long we have watch the U2 market go no where.  We hear speeches from the top how they are growing anywhere from 8 to 15%.  If that was the case then by now the U2 division should be at 250 million dollar business.  We know that is not the case.  The top management at U2 is stale and no Power Point presentation will every change my mind.

We need somebody that can imbue the U2 division with energy, personality, and rigorous performance that this business demands.  The stoic complacent nature of the top must go.  In the process, this organization with its great talent will develop great products and show the world market how nimble and hungry Rocket Software U2 is for your business.

Let's get this ship righted.
Let's start growing at 15% or more in bad years.
Let's start growing at 50% or more in good years.
Let's have this Rocket U2 software company on pages of the Wall Street Journal.
Let's have this U2 brand is known in the boardrooms of the Fortune 5000 corporations

Dragged Kicking and Screaming to GUI

Once upon a time, a customer said we don't need no GUI.  There is nothing wrong with our telnet (green screen) interface on our Public Warehouse Software you wrote in 1984.  All of the enhancements you have made of last 15 plus years have kept the software meaningful.   The software has all of business logic that truly reflects what we do.   There is no need for any changes just keep supporting this for many more years to come.

In order to get a copy of your inventory from this customer you call them up and say I want an inventory.  They print it off on the green bar paper.  They take it over to the copy machine and shrink to 8 1/2 by 11.  They then go over to the fax machine and fax it to you. Nevertheless, they would like to automate this task.

You are shipping in product to this warehouse and would like to get a confirmation back.  When, the product arrives and is put away in the warehouse, the receiving document is copied, in order to get the driver's signature, and faxed to you.  Nevertheless, they would like to automate this task.

You now ask them to ship your product.  You have to fax them an order.  They data entry the order.  The pick sheet is faxed to the back of the warehouse, where they pull the product.  The driver arrives and the product is loaded on the truck.  They fax back a copy of the bill of lading and the pick sheet to their customer.  Nevertheless, they would like to automate this task.

Over the winter of 2000, this software suddenly is transformed in to a 100% web application.  The customers can log in and get their own inventory. Using Unidata's RedBack middle-ware this application is driven by IIS on a Microsoft server running Window NT using ASP pages.

You announce to this customer that the green screen is dead, long live Web GUI.  They scream at you and say this web thing is a flash in the pan.  They say you have spent a lot time do nothing for us.  They say what were you thinking?  They say no you were not thinking about us, only about getting more money from us.

You stand your ground and they prosper.  You get a lot more headaches because you have four pieces to debug when things go wrong rather than one as before.  And things do go wrong.  RedBack won't stay up longer than a day or two.  Transactions somehow get their wires crossed and end up on the wrong workstation.   IIS need to be restarted as well do to memory problems and it gets slower and slower.

The customer reminds you that the telnet interface did not have this many problems.  However, the customer no longer has to fax reports, their customers can print themselves.  New enhancements are flooding in due the fact information is now at the finger tips of your customer.

Four year later you drop RedBack, IIS and ASP.  Your replacement is an homegrown package called U2WebLink™ that runs on Apache Tomcat using JSP, HTML and JavaScript.  The database is still Unidata but the middleware is written all in Java using UniObjects for Java.  You and your team write these Eclipse based tools to build web pages and an object editor for the middle-ware.  Since you have all of this free time you develop and UniBasic Editor, Dictionary Editor, a Universe and Unidata Resizer tool, and Software installer.

Thus ends the simple tale of one customer experience moving from green screen to Web.  By the way they cannot imagine where their business would be had the not "decided" to move to the Web.