Database application front-end programming

Specifications and Assumptions

We all know what it means to assume — but sometimes our assumptions are so completely hidden from us that we don’t even know when we are assuming.

I had an iinteresting conversation with another developer last week that illustrates this point (…and a few others that I’ve blogged about also).  It seems that my developer friend had been involved in a project for another developer who had created an apparently extensive (read as complete) almost 80 page specification regarding what the application was to accomplish, and how.  Required tables and fields had been defined, as had been the associated indexs for the tables.  (Personally, by the time I would have developed such a document I could have had a significant portion of the program created - but that is another story!). 

In the development process all appeared to be proceeding as desired — and then the customer began testing.  It seems that with one of the tables the documented indexes reflected a configuration which would allow duplicate child records - not what was desired - but what the spec allowed.  An assumption was made on the part of the developer writing the code that since the index allowed for duplicates, then duplicates must be desired and programmed to allow them (…all the while knowing that it was not usual).

This one instance indicates a problem that all developers face.  In my experience, it seems that no matter how detailed the spec, there always seems to be some underlying assumptions being made - and they make for keeping our jobs interesting.

How to Measure Application Value - Step 1

Since my living is earned through providing organizations with software application value this topic is one of great interest to me.  I’ve also stated regularly in this blog that I normally am dealing with small business.  In many cases when it comes to establishing the value of an application my clients are relying heavily on my skills in establishing application value for them.  They in most instances have recognized that there is some business process of theirs that is just not working.  This is the starting point for establishing value of an application project. Continued »

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 »

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 »

Small Business and Business Intelligence

Business Intelligence — I have heard it referred to as an oxy-moron, but I think I’ll not go there.  Reading through the technical press one needs not look very far before coming upon writings about BI — implementation issues, how to’s, pitfalls and about BI project ROI.  There is much ado about BI - but what about BI for the small business?  Does it fit, and if so how?   Continued »

Application Developer - User Communications - More Thoughts

“Be careful what you ask for” could be another title for this post, yet another tale of communication mishap, misunderstanding and misconception during application development. Is it just my limited perspective, or could it really be that communication breakdowns are just - to be expected? Expect the unexpected might be my motto after my most recent experiences. This post comments on questions asked, answers received, and resulting misunderstanding(s). 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 »