Software maintenance

The Danger of Over Simplication

How many times have you heard “I have an easy request for you…” from either users or the non-technical manager with no concept of what it takes to create an integrated software application?  Most of us that have been up and down the development block have experienced this I’m sure, and also for many of us the request has actually been easy!  :-)  What a relief when it is!

But then … there are those other times which fall into a couple of different categories.  The first category is the category where as the developer, after looking at the request more closely you determine (much to the dismay of the requestor) that to accomplish the task will really require some major changes - lots of work - and of course that also means time and money!  After close consideration the idea for the change is either re-designed and re-considered, or scrapped.

Then there is the second category — I call it the “…seemed like a good idea at the time…” category.  This is the project which is stated very simply, and upon further investigation as the developer you decide that it will in fact be a great enhancement to the program, and will not take much to implement.  WRONG!  This is the killer project!  Not until getting into the finite details of the application do you realize that it is a monster!  After spending double the time you expected on the project with no definitive end in sight reality has hit hard!

Very simply, the requirements were over-simplified, the review before the project was over-simplified, and the execution anything but over simplified.  Oh well, chalk it up to just another day in the world of software development.  Cheer up, there’s another project coming along right after you finish this one - if you ever do that is!

Time for Application Re-Design?

As an independent custom application software developer I have determined that any really active application (…defined as an application basically designed and developed on an on-going basis, changed and updated frequently as business needs develop) periodically requires that the developer step back and once again look at the application as it exists, the new requirements - and the methods required to maintain and implement the new requirements.  Often I have found that rather than update the application it is often just easier (…read will take less time) to basically start from scratch on many parts of the application.

Now, I’m not suggesting that one throw everything away — but what I am saying is that often early development of the application design limit the ease with which new functionality can be added or processed. This is caused by the simple fact of not knowing ahead of time the additional requirements which may come up.  While it is possible in some cases to “suspect” that some future requirement may arise and therefore plan design to accomodate the future need, often it just isn’t apparent.

It is difficult to determine just when to look at re-design and re-structure of an application, but I have developed one simple step for establishing when it is re-design time — When “conditional code”, “exceptions”  and new table relationships begin to look like spaghetti code of COBOL days — its time for re-design.  I’ve recently found such an application at a customer site — re-design is in progress.

Coming Back to a Project

Regardless of the reason for a development project being delayed, coming back to a project which has been “on the back burner” for a while seems always to raise questions about the project.  For me the questions may start out with “Where was I on this before I had to leave it?”, to “Why on earth was I heading in THAT direction with this?” — or my favorite “What was I thinking!”   …usually an indication that I wasn’t thinking! ) .  Besides the “lost” time of re-aquainting oneself with the project, there have been many projects for which the longer they sat, the more I just wanted to start over again.

As an independent developer I’ve always had to be working with multiple projects at a time, and somewhere deep down in my being, I wished that I could just have one project to work - from start to finish!  The problem with that idea is that for one thing a custom application project never seems to end — mostly as the result of constant improvements being made to the application — or “tweaks” as one of my customers call them, so there is seemingly always something more to be done. 

However, coming back to a project can be challenging.  It can also be an indication to one as a developer of how much they’ve learned in the say, six months that a project sat without being worked on.  This is a good thing!  Whenever possible when I have identified that some previous work can be improved upon to simplify or somehow make the code more maintainable — if at all possible I make the change.

Another thing I have experienced after coming back to a stopped project is that very often I find that in the time lapse since last working on the project the needs of the user community for which the project is designed may have changed.  Certainly it is imperative that before going ahead with any stopped project there be clear communication with users or as a minimum the person ultimately responsible for the project from the business need standpoint.

Coming back to a project can be exciting — but it can also bring new requirements, expectations and challenges.

Maintenance vs New Design

My previous post made reference once again to the human interface design of an application and application speed considerations. As a follow-up to that post, I find myself thinking once again about a few of the issues which I have previously posted about code maintenance and new design. “Software Quality and Maintainability” was one of my earlier posts which may be of interest.

The topic of maintenance vs re-design once again (as with so many of my topics) has been prompted as the result of fresh experiences with my clients. My earlier post made reference to factors beyond the programming considerations which might otherwise be no problem, such as hardware or O/S issues. The current issue I’m dealing with however is really a useability issue. The client needs have changed so much that another maintenance band-aid to the existing program just isn’t appropriate. It is past time for updating - new design is the only logical option.

There is of course the shrinking budget — and that is an issue for this client at this time whether they were to decide to buy off-the-shelf or build. Perhaps this is a time for them to ignore? I think not! Their need is there, the budget isn’t. This is where they should be making plans for the future. They’re still working with what they have, and, inefficient though it is, they are getting by. However, by using this time for planning future IT infrastructure improvements they will be well served and perhaps be able to establish a method where their investment can be “piece mealed” and thus keep moving forward.

Updates that Fail

Don’t you hate it when an update fails? I had the experience just yesterday while doing an update on my Microsoft Vista laptop. The updates appeared to be going correctly, but at the very end I found myself in an endless loop situation. The situation was not pretty and upon further investigation in the web a Google search pointed me in the direction of a workaround. I wasn’t sure that was the right direction, but this was not something that was unique to myself. The work-around worked!

I was fortunate. I only lost about an hour in my struggle to find the answer to take corrective action. However, others were not so lucky, many losing countless hours before recovering — or not — their system. My investigation to this point indicates that while this has happened on an occasional basis for some, Microsoft has been apparently quiet regarding this problem. This was an update that I expected to work absolutely perfectly since a fellow developer friend of mine said he never liked Vista until he had installed service pack one.

It seems that on August 12 of this year VMare issued an update which caused issues regarding the licensing. The problem prompted an open letter to VMware customers from VMware’s president (…see letter). This appears to be a fine example of software quality assurance going wrong — just how this embarrassing situation occurred is certainly under investigation by VMware.

As I see it, these two examples of updates that failed are very different. In the case of the VMware issue a fix was readily found, as the issue was the result of a programming error. A quick fix of the error and the problem was resolved.

As for the Microsoft issue. I see the problem as somewhat different in that while the problem has occurred for some, there are many for whom it has not occurred. This represents a much more difficult issue to resolve. As a result of the very nature of personal PCs, testing for this error becomes much more of an issue. I can almost forgive Microsoft for not having a solution to it.

Yes, I’ve had perhaps more than my share of failed updates. I find that I am much more upset with programming or testing errors than with errors which occur as the result of network or hardware issues which I cannot duplicate. Regardless of the cause, there is no such thing as a good failed update.

What keeps an out-of-date application in place

I had the opportunity recently to make some minor changes to reports originally created in the late 80’s. The application is a character-based app running on an “old” version of SCO Unix, and hardware that has been kept alive by some clever mix and match combination of “old” components taken from servers long ago taken out of service.  To say this is out-of-date is being kind - let’s say it owes nothing.

My first thought when I posed the question “What keeps an out-of-date application in place?” was that of course — it’s money!  While that jumped into my mind immediately, I began also to consider what else would be keeping the app alive.  For one thing, there is the fact that it is basic, lean and mean (read that fast response), and works well for what it was designed to do.  The issue here is that it wasn’t designed to do much of what the modern business requires it to do in 2008.  It is also difficult to support, although it doesn’t require significant support.

So what else might be keeping it going if money isn’t the real issue?  How about fear?  With any new implementation there is always a fear factor that has to be overcome.  What if the wrong application has been chosen?  What if it doesn’t fit as expected?  What if, what if, what if???  You can probably think of dozens of scenarios which might cause an organization to avoid replacing an application, but none of them would exist on any of the “best practices” lists.

It just so happens that in the history of this company there was a failed implementation of software which at the time was thought to be a good “upgrade” for the company.  Many thousands of dollars were spent on equipment, software, support and consulting fees for the project which never got completed.  It seems that the business processes that needed to change in order to get the desired results from the software were just too much.  The company was sold during this time.  Go figure!

(…although I don’t remember the year that took place, I’m pretty sure it was over 10 years ago

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.

Small Business Application Development and Use Cases

While there is no shortage of writing available on the internet or in software development textbooks regarding the various software development methodologies available, I find that the great majority of it is really geared toward managing large projects for large companies.  Since I develop for small and medium size businesses who often have very limited budgets for development, I am always interested in the processes and methodologies that can help me produce better software for my clients.  My clients IT infrastructures often leave something to be desired - and therefore often I become an infrastructure consultant as well as software developer.

My reading this week pointed me to an article on the SearchSoftwareQuality site entitled “Useful app dev practices trump full-blown processes.”  The article, written about prominent software methodologist Ivar Jacobson touches on how Jacobson is willing to rethink processes and practices, something which is always difficult to do either because of time constraints or because of being reluctant to admit that something which you previously had thought was so great - perhaps isn’t, or needs to be modified.

Custom application software needs to be reviewed regularly in order to maintain or increase its value as it is used.  This is no trivial task.  I’m currently in the process of conducting 2 such reviews for clients, and they are taking considerable time — and it is these reviews which bring me to “Use Cases” and another article titled “Five use case traps to avoid“.  Use cases can be a very valuable methodology to incorporate when reviewing existing software, procedures and planning future rewrites or modifications to the application - even for small projects, creating such a document will help solidify understanding and communication among the analyst, developer/programmer and client.

Robotic Arm Programming, Mars and Agile Methods?

I read with great interest an article about the recently successful Mars Lander “NASA: Robotic arm key to finding life on Mars”  In particular what caught my attention was that the programmers for the mission are sending daily code updates to Mars to guide the robotic arm as it gathers and prepares sample for analysis.  They are on a daily schedule of writing, testing and sending new code sequences to their “baby” on Mars!  Sounds like a story straight out of science fiction!  (I wonder if this is considered an Agile team

The article refers to the sequences taking about 20 minutes, and then 12-16 hours later feedback from the Lander.  Certainly there’s no pressure to get the code right the first time - is there?  Well, there is also the pride of the development team — my hats off to salute them!  What an accomplishment!  Man and machine, working together - what a team!

May our programming future enable such flexibility, whether we program for business, medical or space exploration.

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.