Why Rapid Update Software

For many years we have made users or clients wait for updates. Whether we are trying to save those updates to roll into an update package or they are insignificant in our eyes, we have been very self-serving. Sometimes we will make a change in the client's account to fix a significant bug or problem, and then we will make the change in the base product. The latter is used on rare occasions.

We have to be responsive to user’s needs. When they say they want a new feature or a bug fix, we need to get on it right now. If we do not see the urgency of their request, we may not have that client in the future.

On incident comes to mind. We had a client that went to look at their competitor and spent some time looking at the competitor software. This client came back to U2logic and said they saw their competitor software do drag and drop dispatch. Then they asked the $10,000.00 question: Can you do that? Unfortunately, we answered the question with maybe given enough time and money. The better answer should have been: Yes! Then wait for the client to ask how much it will cost and how long will it take. Within in a year the client went somewhere else. We cannot tell you that the above was the only reason, but it did not help our case that we did not give them what they wanted.

Mozilla is releasing Firefox every six weeks. Users are complaining that this requiring a lot of work on their side to test their software to make sure it is compatible with the new release. In one of the developer’s blog he states:   "If we want the browser to be the interface for the Internet, we need to make it more like the Internet.  That means delivering capabilities when they are ready."

So our position is that users/clients that are waiting sometimes years for us to get a feature may cause them to look elsewhere.  Our release schedule for our XLr8Tools is 3 to 4 weeks.  Our applications software is now every 4 weeks.

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