Database

The Buy, Build or Ignore Decision

A recent visit to a doctor’s office this week channeled my thinking once again toward the simple applications that can save time in any environment.  As I was checking in at the registration desk, it was noted that they did not have the latest copy of my insurance card.  I gave the receptionist my card, and card in hand she walked to the back of the office to the copier, where she leisurely made a paper copy of first one side and then the other.  She then walked back to the front of the office and passed my card back to me, adding the two 8-1/2X11 mostly blank sheets of paper to my file.

This was one of those times when I wished I had a stopwatch in my pocket.  Yes, it has become just a part of her daily routine.  It seems like nothing, but this is a very busy office, and the receptionist figures she makes that trip at least 20 times per day.  I know that this journey of hers took approximately 1 minute, and used two sheets of paper.  Anyone care to estimate the cost of doing this on a yearly basis?  Monthly? Daily?  It certainly adds up!

Now, what might it take to create a simple application to scan and electronically store this information?  Recently the most requested functionality I’ve been adding to my custom programs have involved scanning application integration.  One can get as complicated or as simple as desired — and a high level of integration can be costly.  However, a simple database coupled with a scanner can be a powerful addition - even if only a temporary one.  It wouldn’t take much time before the cost of such a simple solution paid for itself.

Anyone else see inefficiencies easily and cost effectively addressed (even if incompletely)?  I see them all around me — but maybe I’m the only one :-)  I suspect not however.  I commonly hear from clients that they’ve tried the idea of scanning “…but it was too complicated…”.  It needn’t be, but scanning applications like so many others have fallen prey to the “bloat” we have unfortunately become accustomed to.

Spending the Day with Microsoft

Last week I had the opportunity to spend the day with Microsoft at their Heroes happen {here} Microsoft 2008 Launch Wave in Boston.  Evidence of Microsoft’s commitment to virtualization were plentiful.  Many of the demonstrations they provided, clearly were accessing virtualized machines.  Application virtualization was not quite as prominently noticeable however I understand one session which I did not attend, their session on virtualization in your infrastructure, did show application virtualization on Windows Server 2008.

I chose to follow the presentations provided in the “developers track” — surprise, surprise?  Microsoft managed to provide information sessions, for the most part, rather than vailed sales pitches — I commend them on that.  Of course, the greatest percentage of sessions and information provided were really geared toward the larger enterprise customers.

It’s always difficult to know after shows like this just what value I have gained from the time spent.  It probably will be a while before I truly understand the value to me, however, having the opportunity to work with the provided Not for Resale software — Server 2008, SQL 2000 and Visual Studio 2008 — I’m sure will provide value to me in the coming months.

Quick Thoughts on Application Value

Experience a major meltdown of your workstation and I suspect the value of various applications will come to mind VERY quickly! There is nothing like going without your favorite applications, or your workhorse applications for a few days to develop a significant appreciation for application value. My last 2 weeks have been filled with recovering from such a meltdown.

If you’re like me as you have used your workstation (…perhaps for years) it has accumulated a number of handy utilities that are not “big” names, yet you use them each and every day. Perhaps they were something you found on the internet years ago and fell in love with and it has become part and parcel of your day-to-day work. What happens IF (or more likely when?) suddenly your workstation has a meltdown? It’s really not pretty!

Replacing a defunct workstation with a brand new one is only the start of the battle - the easy part. Gathering all the software you had, reloading it, re-registering it, restoring all the “little” applications (…finding where you got them from can even be a challenge I found!) all present challenges. Doing all this while at the same time tending (…or trying to tend to) the business needs becomes a stress-producing and frustrating experience.

When it comes to establishing application value I really wonder how one would determine in advance the effect of having an application suddenly NOT available once all the investment in application creation and implementation was made. I believe that if in the early stages of application definition one would be able to look ahead 5 years to look at what the potential dependency might be on the application it could be another way to think of application value.

How to Measure Application Value - Part 1

When it comes to applications and the buy, build or ignore decision, one of the first considerations must be to find an answer to the question of what value the application is expected to bring forth.  That sounds simple enough, but how exactly does one measure the multiple values which any given application may be expected to provide.  On top of that, many applications once implemented can produce results which were totally unexpected.   Then of course there is always the challenge of putting A monetary value to the benefits.  All of these present challenges for both the developer organization and end customer.  So - where does one begin.

 I certainly don’t pretend to have the “answer”.  In fact, I believe, there really is no one answer for any organization, and the answers and methods used to evaluate “value” will vary from project to project.  My experience would show that sometimes the applications that prove of greatest value weren’t on anybodys radar, but were championed by someone within the organization with enough “clout” to say simply “do it!”

To set the record straight, I’m not saying here to “build it and they will come”, but I am saying that with proper consciousness to the business processes it is possible to hit a home run with an application that if analyzed early on with a “cost / benefit” analysis would fail miserably.  In following posts I intend to bring forth some of the perhaps “odd” methods I’ve been familiar with.

In the mean time, If you have anything you think should be addressed about application value — please post.

Applications, the Business and the Processes

Reading Bob Lewis’s most recent article in KJR set my head spinning with thoughts of a commoditized IT similar to that of an electric company.  What Bob Lewis refers to in his article is a recent book entitled The Big Switch: Rewiring the World, from Edison to Google (W. W. Norton, 2008), and written by Nicholas Carr.  The very concept of IT as a commodity makes my stomach churn, as I’m sure it does with many of my associates.  Continued »

Development Humor as Thought Provoking Material

While reading through one of the Visual Dataflex newsgroup posts last week I stumbled upon an exchange where some developers were talking about their preference to keep their machines “clean”, as in not installing programs which are not going to be used, but for one reason or another get “added” — something like the various shortcuts that appear after loading just about any commercial program these days –  tax software for instance:>)

Anyway, the following excerpt was just too good to not pass along. Continued »

Software Development Using Multiple Environments

I have used the Basic, ASP, Java, Progress 4GL and DataFlex languages to some degree within the past week.  (…as well as operating system specific programs which are another form of programming).  Each of these were used with different tools for different applications.  For Each (…there I go looping again) there are syntaxes which are very similar to identical, and at least for this brain, easily confused.  Thankfully, many of the tools provided for development today shield the programmer from the intricacies of the language. Continued »

Web 2.0 Applications - Ending Desktop Clients?

There is much in the tech press today about Web 2.0 applications, and although the term is used very loosely, and seems to be loosely defined, there are those who seem to think that the days of the desktop client are numbered!  My question is — what number?  My answer to the question would have to be roughly equivalent to the number of days that it has taken Cobol to die (remember Cobol, the language of business years ago?  and still around today?).

Well, Web applications have in fact come a long way from their start, and certainly they have made significant advances in their ability to handle the tasks of ordering on-line and related tasks.  However, while I read about all the wonderful Web 2.0 applications being created I find myself wondering at what point will these web applications be ready for the moment-to-moment database data entry tasks of a well-developed desktop application — or will they ever be — or if so, what about cost effectiveness?  Is there really a desire to have an ERP system for example with only a browser interface? Continued »

Business Goals and Application Development

I am continually shocked by the constant writings I read that express (…as if it were a “New” requirement) the need for IT departments and developers to “…consider the needs of the business” — Duh!

To my way of thinking this is as basic as getting up in the morning.  There will always be something new (and improved) that the marketing gurus will be touting - and it probably won’t be inexpensive.  Determining the ”savings” of the latest and greatest is tricky at best, and what about the “learning curve” before the “savings” can be realized?  How can one know until the time is spent?

In most companies one needs not look very far before coming upon areas of inefficiency. Continued »

Developer - User Communications - Another Visit

Once again I find myself writing about the value of having good communication between the application developer and the users expected to use the program for their day-to-day operations.  Two noteworthy instances of this value came to me once again - just yesterday.  Each incident was unique in its own way, but the common thread was clearly communication - either poor, incomplete, misunderstood or a combination of all.  In each case the end result has been delay in getting the task completed. Continued »