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!