Software maintenance

Application Code Maintenance vs Re-Creation

Which would you rather do — maintain an existing application’s code or create (maybe re-create) an application from scratch?  Obviously, it would depend upon the complexity and size of the application, and perhaps the tools used to create the app — but I believe that at some point after an app has been in service for a while, it reachs a point where I’d rather re-create rather than do maintenance to bring it up-to-date.

It has been my experience that somewhere in the 5-10 years of use range between hardware changes, O/S changes, functionality additions, “bug” fixes and patchs for the various changes — it becomes time to “rebuild” the application.  Again in my experience, what I have found is that the code appears to resemble more a patchwork quilt than that of a logical program by that time.  This fact appears to be one of the best “selling” points to use when approaching the idea of re-writing an application with the management that will have to pay for it. 

Our off-the-shelf software creators take care of this for us — we get what they want to give us — like it or not.  I won’t go off on a rant about application “bloat”  (…which I am very capable of doing!).  With our custom application programs we DO have an opportunity to evaluate and re-design according to the latest techniques, and add functionality (or not) in an orderly - maintainable - fashion.  I don’t suggest adding functionality “just because you can”, yet if it “fits”, if it adds to the useability of the application, then consider it.

There is many a program which I have re-written as the result of a re-evaluation of the application.  Particularly I will choose to re-write when the application has become a “bear” to maintain.  Sometimes the user sees no change, yet an application which can be easily maintained and is up-to-date with the technology is (at least in my book) always preferable.

Thoughts on the Elusive “Bug”

My last post was certainly created in the heat of the moment, and displayed I’m sure a significant amount of the angst that I was feeling at the time.  The issue that I was having has now been resolved, but it really serves as an excellent example of some of the pitfalls that can occur when developing an application.  Let me explain.

I failed to follow one of the cardinal rules of development — that of changing too much at one time.  As I understand it the procedure that I usually follow could be classified as “unit testing”.  I was suckered in by the fact that the program was a very “simple” one.  Because it was so simple, I didn’t take the time to make a change and then test for that change.  As it turns out, that was a big mistake.

I also made the mistake — because I was feeling time constraints — of not taking the time to follow my usual step-by-step procedures.  Not only was I not checking incremental changes, but I was also dealing with a situation where I was integrating third-party software into my program.  What I had not realized was that by using some old code I was in fact negating some of the functionality I was expecting.  Since this was the first time I had newly integrated this Active-X component using the latest version of my development tool — Visual Dataflex (VDF) — I was caught off guard.

Moral of the story?  Make changes in increments, test frequently, and be patient.

In Search of the Elusive Program “Bug”

It happens sometimes, that elusive “bug” that just drives you crazy as a programmer.  I know I’m not the only one that this has happened to, as there are many other developers with whom I’ve spoken that relate similar stories to mine — that of spending hours looking for the solution to a problem that you know just shouldn’t exist.  As for me, I’d just as soon forget about today’s episode.  It was not a pretty sight!  Heck, it still isn’t pretty!

The fact of the matter is, the problem that has been “bugging” me all day has still not been exterminated.  And in spite of my best efforts to analyze, use every tool available to me in my efforts to find the problem, and even after reading the manual, the problem remains.  I hate it when that happens!

It all seems like it should be so simple, yet something has changed that I have not been able to identify.  As a result, the program is still not working, nor at this point is my brain working.  It’s really time to stop thinking about the problem — but it seems I just can’t get it out of my mind.  So, since I have this blog available to me I thought I would share a bit about my problems today.  Hopefully others who read this will be able to relate.

This was one of those infamous projects which was supposed to be “quick”.  After all, what I was doing was updating a pretty straightforward “simple” application.  The problem with this update appears to be that I am actually working with two updated versions of software.  During earlier beta testing of the software, the updates worked flawlessly.  Now that I have the final release of the program, I can’t seem to get it working.

I have tried everything I know of to help me keep a clear mind while addressing the problem — I’ve walked away from it, and then come back.  I took a few short walks!  As simple as the program is, I even started from scratch — with the same result.  It was at that point when I decided perhaps the change in versions may be the root of the problem.  That’s tomorrow’s project.

May your programming day be void of these issues — and if you’re NOT a programmer — be thankful and think of those who create the applications you are using.  It might just be that a lot of sweat went into their creation.  Not a marathon for sure, but seems like it when dealing with the elusive “bug”.

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.

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 »

Testing Application Changes - Test Data vs “Live”

So you have completed making the small changes required in your application, you have tested, you have debugged, you’ve done “everything” right!  But alas, your application goes “live” and — problems!  Strange error messages are being generated faster than the eye can follow!  You find yourself saying “I’ve never seen that error before –”  (…or perhaps you’re thinking more along the lines of “…<expletive deleted>…”!  Whatever the thought process going on at that point, you have to act fast.  Continued »

Expectations in Software Development

I’ve heard it said before that an expectation unfullfilled leads to upset, and I must honestly say that I buy into that 100%.  How many times have we begun using a new piece of software with an expectation (or 2 or 3) that was left unfulfilled once we started using the software?  I believe that I can say for certain that it has happened to each of us on at least one occasion - leaving us upset because the expectation (probably unrecognized and undefined beforehand) was not met. 

With this in mind, I would like to explore some thoughts regarding just what some unspoken expectations for software are. Continued »

Time to Redesign? - An Application Development Quandary

No, I do NOT belong to the writers guild, and am NOT on strike.  So much to say, so little time in which to say it! 

I awoke this morning thinking about my latest quandary — whether to just give up on maintaining the non-working component of my application, or to continue my efforts to come out of my predicament by means of a “breakthrough” which suddenly fixes the problem.  (So far this morning I have chosen to blog about it instead of working on it — somehow hoping that I talk my way through to a fix.) Continued »

What Constitutes Good Program Code?

Good program code first and foremost just “works” as expected, does the job for which it was designed, and provides trouble free operation in a timely fashion.  Working, however, is only one component of good program code.  There are certainly many other aspects to good program code which must be considered, but how does one evaluate program code to say “…this is good code”.?  “Good” program code is an especially elusive label, based upon criteria that is as individual as each programmer.  (Now that’s a scary thought - I’m glad Halloween is over!) Continued »

Software Quality and Maintainability

Maintainability is often included as a component of software quality, and as with so many software quality components, there has been much effort expended on measuring.  For me trying to measure “software quality” in any manner seems to mimic something that I might see on the TV show “Numbers”, it is WAY over my head.  While I was looking into “software maintenance” via a recent Google search, I discovered an interesting paper titled “Can We Measure Maintainability?“.   Once again I’ll leave these academic discussions for the “experts”, and just put out here my thoughts on the subject, right, wrong or somewhere in-between.  Continued »