Custom software development

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 »

Can applications be too Automated?

As a custom application developer working mostly with small businesses, users often look at “Why can’t the program do this?”, or “How about having the program add this, subtract this - when it’s this, then add a percentage…” yada, yada, yada.  Perhaps you recognize the pattern.  There can be arguments for doing much in the way of accommodating the requests, but in my opinion there can become a time when an application is too automated. Continued »

Simplicity is Power

Seems like I’ve expounded on this topic ever since my first encounter with software and software development.  Keep it Simple (Stupid) - aka the KISS approach is, I believe, always appropriate when looking at development of a business application.  It has always been my goal that users of applications which I’ve developed not need any “training” in the use of the application, but rather (assuming they know the job which they are expected to do) they just get into the application and start using it. 

I’ve written before about how simplicity at the interface and user level does not necessarily mean simplicity behind the scenes at program core, but that in fact many times it adds to the complexity behind the scenes, putting more responsibility on the developer.  Certainly consideration must be given to the complexity behind the scene as well that it not become a tangled, unmanageable mess of what has been dubbed “spaghetti code”.

Todays emphasis on simplicity has really been brought to the forefront as the result of checking out a book recommended by Avery in a previous post reply.  The book,  Getting Real by 37 Signals triggered my mind into over-drive thinking about how strongly I believe in simplicity of design.  You might want to check out the link for yourself. 

Actually, it seems that I made reference to Getting Real in my post a year ago entitled “Getting Real” is UnReal!.  (I knew I had remembered something about less being more!).

The Illusion of Perfect Software

Perfect software doesn’t exist - that should be “…elementary my Dear Watson.”  Ok, so starting with that assumption where does one go with their quest for the “perfect” software, or perhaps the “perfect” tester, or the “perfect” whatever for that matter!  A couple of weeks ago I bookmarked a post that caught my eye entitled Book gives managers a software testing reality check.  It was right at the beginning that my eye caught the “…perfect software doesn’t exist” statement in the post.

I’ve often written here about software expectations.  In my experience end users are often looking for (maybe even expecting) perfect solutions to their software needs, but I believe that is not possible.  The expression, “one man’s junk, another man’s treasure” kind of applies here.  The definition of “perfect” among evaluators will vary as much as the individual personalities of the evaluators.  Marketers, of course, describe their “perfect” solutions with charm, grace and slick that defies logic.  Save us please!

The reality of software development and testing is that a series of trade-offs has been made to arrive at an acceptable, functional and apparently “bug free” application.  There will always be decisions made such as feature set vs cost to produce the feature set.  Sometimes software with “known issues” is released - possibly because of cost concerns, possibly because the need is so great that expediency is the driving factor.  (In those cases, however, it is quite possible that a work-a-round has been identified, or that the known issue exists only when a user goes down a path which they shouldn’t be going down to begin with).  Yes, in that case the software “should” prevent access to that path, but I’ve certainly seen many an instance where the time and cost to do it just wasn’t worth the effort when user training “should” take care of the issue.

The IT Worker Telecommuting

Somehow or another in spite of my best efforts to escape computer-speak when I’m not actively at work it seems that even my personal “life” is laced with computer and IT geeks.  Of course, as I’ve blogged about previously, I don’t really try to separate my “life” into a “work-life” and “personal” life — but I find it interesting that so many of the new people that I’ve met in the past year are associated with computing to some extent or another.  (Of course living in New England with its high concentration of “techies” probably contributes greatly to my experience!)

At any rate, I found myself engaged in a couple of interesting conversations this weekend about working from home, the economy, job environment and IT careers in general.  Of particular interest in those conversations was the subject of “the home office” and “working from home”, and in particular the challenges that are presented with the “home” environment.  Not all of us engaged in the conversation were currently working from home, but a number of us have had the experience and could easily relate to the “stories” and experiences of others.

One of the topics which constantly came up (with associated “stories” ) was the experiences of the “worker” with their “family” during “work” time.  The number one issue that came up was related to the need when “working”, to be left undisturbed, as if they had driven off to an office somewhere.  Of course, for this to truly work for all of the relationships concerned, telecommuting from home cannot be a 24/7 operation.  Clear boundaries have to be set.

However, this is more easily said than done it seems.  Many of the participants in the conversation were feeling especially insecure about their current employment status — and the general consensus is that with such insecurity in the background, there is a tendency to try to work 24/7.  This does not work!  It was suggested by one participant that he thought perhaps that was what the company hoped for when they allowed him to telecommute!

Having employees who work from home certainly can save a company money.  The full-time telecommuter doesn’t require office space, the part-time telecommuter can often share office space — less office space required, less expense.  If on top of that savings the employer then gets greater productivity from the employee - it’s a win!

Factors Against a Custom Application

My previous post pointed out a few of the reasons why one might choose to create a custom application.  For this post I’d like to further the discussion to review some of the reasons (valid and otherwise) for NOT creating a custom application.  I would include in this category:

• FEAR - Many a story has been told about the “dream” development project that became a nightmare - obviously what there is to do here is to carefully select developer(s)
• It will be “Too Costly” - It doesn’t have to be in most cases
• “Standards” won’t allow it
• Too big of a commitment
• No “New” requirements are on the horizon
• Suitable “Off-the-shelf” software for your industry is available and within your budget range
• Your operation is running efficiently, programs being used suit your needs
• Users are getting what they need from the existing system
• Existing system is technically “up-to-date”

 Certainly if the last four points above hold true for your operation one would be hard-pressed to create a valid case for a custom program - you just don’t need it!  As for the standards issue there’s not much I can say about it.  I have seen companies that have struggled with exceptionally ineffective and inefficient software - only because a proposed app won’t “fit” the “Standard” - I have to seriously wonder about this decision.  In some instances it seems to be that the “Fear” or “Too costly” or “fear of commitment” arguments come into place.

Next Post — “Identifying Potentially Valuable Custom Applications”