Updating Legacy Systems

Application Cost Estimating

When I first posted “Cost Estimating Rewrite of Legacy Applications” I had not planned that it would turn into a series of posts such as it has.    What I found is that the more I wrote, the more there was to write about.  Since I struggle with post topics from time-to-time, this topic has become this blogger’s dream.  Hopefully it is helping others in some way. Continued »

Comments on Cost Estimating (Continued)

I seemed to have a lot to comment on in my last post, and decided it was best to have another post which continued my comments from my list of considerations for legacy application rewrites, so I continue my comments in this post.

Myself, very early on in the review of a potential project I like to look at the tables, any relationships between tables, and any indexes which may be defined for the tables.  At one point I had developed a method of estimating which assigned a basic value for each table based upon number of fields, number of relationships, and number of indexes.  The more of each the greater the cost to replicate.  This was a time consuming analysis, but provided a significantly more in-depth understanding of what I was getting myself into.  The problem I had with this method was that I never quite did enough of these to establish meaningful values.  The other thing I did (which I highly recommend against!) is to decide I was making it too complicated and therefore misjudging the time it would take!  Problem was, estimates using this method, while they produced the work, the work was produced because I was “giving it away” by ignoring what I thought it would take based on the details I knew.

Legacy apps which are not based upon a relational database are of course the most difficult to estimating in my opinion.  I believe that to estimate such a potential project one must basically create the tables, relationships and indexes on paper at least.  Here creating a diagram of tables and relationships can be a valuable asset as well.

Yet another time-consuming exercise that is best taken on early is an evaluation of the ratio of entry/processing programs to reporting programs.  It’s my experience that entry/processing programs generally are more complex than the general reporting program.  Of course, I have had plenty of very complex reports which break this “rule”, but they have been the exception.

Comments on Application Cost Estimating

In my previous post “Cost Estimating Ideas for Legacy Application Rewrites” I provided a list of considerations for preparing estimates for legacy application rewrites.  This post is a follow-up to that post where I will add comments to some of the considerations listed in that post.

• Industry — A couple of the considerations which I listed relate to the industry using the particular application.  I’ve found that some developers are not at all comfortable jumping into a new industry application environment, so in that case industry familiarity and team experience becomes a large factor.  There can be an argument made that IF a developer is NOT familiar with the particulars of an industry that they are probably not the developers for the job.  However, a case can also be made that a development team that is NOT familiar with the industry has no predefined set of “…this is the (ONLY implied) way to do it!” methods.  This lack of experience in the industry can result in creativity beyond that of the experienced.  The smart development team that is geared toward accomplishing an effective application can overcome industry inexperience by listening to those with the experience, and applying their own experience in new ways for the project.  It may be more expensive to have the inexperienced team do the project — but then again the inexperienced team can take their inefficiency into account and perhaps absorb some of their “learning curve” time themselves.
• Source Code – In my experience there seems always to be some source code which for one reason or another is among the “missing”.  Very often it has been replaced with another piece of source, but not always.  Sometimes it is source code developed as an add-on to the application by a third party who did not provide the source to the customer, for whatever reason.
• Analysis of Available Source Code – Recently I was introduced to a method whereby looking at the source code size (i.e. total bytes contained in all the source code) was used to help in the estimate.  What this estimator did was to take that size and apply a “factor” to it, which “factor” was the result of his years of experience with both the development environment and applications experience.  If an application has 1000 pieces of source code in most situations (ALL that I’ve been involved with), each individual piece of source is not going to get opened up and evaluated.  Another variation on the code size approach might be number of lines of code, as I’ve known that to be used.  The issue with lines of code is that establishing the number of lines of code may be too difficult to get.

My comments will continue in my next post.  Please stay tuned!

Cost Estimating Ideas for the Legacy Application Rewrite

I promised in my last post “Cost Estimating Rewrite of Legacy Applications” that I would be producing a list of considerations for preparing estimates for legacy application rewrites - this is the post!  The suggestions on my list are really slanted toward the independent developers who are apt to find themselves in many an unfamiliar territory.

• Is the industry using the application familiar to you or your development team?
• What is your / your teams experience with applications in the industry?
• Is ALL of the legacy app source code available?
• Can the legacy app “play nicely” with the new app — or must the new totally replace the existing  immediately?
• What is the ratio of data entry and processing to reporting?
• Are there existing interfaces to external functionality for which no source or documentation is available?
• What are the time constraints for the project?
• What is the total size of source to be recreated?  How many bytes?  How many lines?
• Relational database or non-relational?
• How many tables involved?
• How about relationships between tables?
• What might you NOT know about?
• Is the new application to start fresh (empty data files), or will some data transfer/cleanup/modification be required?

Each of the above considerations (listed in no particular order by the way) are especially appropriate to the re-creation of an existing legacy application.  I’m sure there are other considerations not listed, and I would welcome your comment and suggestions.  Also, as with all software development whether a brand new app or rewrite of an existing app, all the considerations of application purpose, user experience, industry expectations and the myriad of other design considerations should be added to the considerations.

In a future post I will expand upon the above list with additional comment.

Cost Estimating Rewrite of Legacy Applications

I have always found estimating a project to be a challenge.  Back in my early days as an independent developer I quickly learned that I had a tendency to under-estimate the time a project would take.  My error would more often than not be in accounting for the time it takes to “polish” the application.  My approach to that then was to produce my best estimate and then apply some factor to it, somewhat depending upon my “attitude” at the time, but always beginning with a factor of 2.  If I thought a project would take 40 hours I could pretty much depend upon it taking a minimum of 80, so I’d double my estimate! Continued »

Legacy Application to Windows - Challenge of design

I’ve discovered the greatest challenge of my application programming and design career,  (Hopefully I haven’t met my match!).  My latest project involves a rather large legacy character-based system which has evolved over the past 20 years or so.  The source code directory lists some 800+ pieces of source code, with close to 500 being actively used, and others that were basically copies of some “active” source with minor modifications - mostly in the screen layouts for entry programs, and header footer changes on reports.  In all, a lot of code to evaluate. Continued »