Independent software developer

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 »

Fighting Shutdown during Slowdown

Certainly these are trying economic times for us!  We’re all seemingly “trying” to keep our heads above water economically, or at least minimize our losses.  We’re “trying” to make sense of an economy gone into a spiral, and “trying” to maintain balance during all the turmoil.  These “trying” times can also make us “trying” to be around as we’re not fun to be with as a result of letting the “trying” times get to us!

Even the most high-energy type “A” personalities can appreciate times of slowdown as they may provide an opportunity to not be “pushed” or to “push oneself”, but rather provide an opportunity to slow the pace down, smell the flowers or just work to live rather than living to work.  Slowdowns not affecting ones economic security and well-being can actually be nourishing.  Welcome to 2009 and economic insecurity!

So now what?  Some of us will completely destroy any economic security by upsetting the work-life balance so drastically as to destroy relationships with spouses and children.  This seems to be one of the first changes that I’ve seen workers make (…voice of experience here…) — they’re gonna’ work longer and harder — the better thing to do would be to work smarter!  (…easier said than done I agree! )  Now that I’ve mentioned working smarter you might wonder just how you can work smarter - what might working smarter look like for you?  I’m glad you asked.

I believe that for the independent developer working smarter might just look like finally getting into the “project” that has been dwelling in the far recesses of the brain for a long time — something like perhaps “..learning how to …”, or “…re-writing something to make it more manageable” — that kind of project - something for yourself and your own peace-of-mind.  It may not bring about any immediate income, but a project like that can provide peace-of-mind, confidence and some sense of security as it strengthens your own sense of capability.  It can also help you shut out the negative “voices” trying to get you to despair.  Heck, it may open doors never seen before - areas that you can eventually delve into profitably.

In my opinion (I get to voice it here as this is my blog ), the most dangerous of all ways to handle the times we’re all going through right now is to shutdown.  Don’t shut down!  Shutting down just gets one deeper into the spiral, the black hole so to speak.  Keep active, strengthen your relationships, be creative.  These are times to become creative if you are not naturally that way, or to activate your inate creativity to its fullest!  “Yankee ingenuity” isn’t only for us Yanks!

Software Development, Security and Programming Errors

Within the last few hours quite a buzz has been created by the release of the CWE/SANS Top 25 Most Dangerous Programming Errors list.  USA Today posted an article on the list with an insert about The Importance of the Flaws List.  Early today the BBC News posted Dangerous Coding Errors Revealed.  Certainly the buzz will continue!

There is much to be said about security, and certainly the independent developer needs to be just as mindful of potential flaws as the corporate developer in a team environment.  This list is for every developer to consider.  I was amazed to find a couple of practices in the Top 25 that I have, at one time or another, been guilty of doing.

The list categorizes the top 25 into categories of “Insecure Interaction Between Components“, “Risky Resource Management” and my personal favorite, “Pourous Defenses“.  The errors themselves are related to a “CWE”, or Common Weakness Enumeration which is described in detail on the CWE website.  For example, one of the Top 25  in the “Pourous Defenses” category is identified as CWE-259 Hard Coded Password.  Reviewing the entry regarding the CWE-259 I believe begins to reveal the significance and usefulness of this Top 25 list to ALL developers.

Personally, to be honest, I might not have paid much attention to it had it not been called to my attention by my son who has been involved in the project for months.  I hope readers of this blog find the material useful themselves.  Oh yes, it is estimated that some 85% of the criminal activity on the internet have resulted from these Top 25 “NOT best practices!” in coding.

A New Year - A New Application

Other developers may not experience this, but for me it seems that leading up to the end of a year I become very busily engaged in “tidying up” or putting some “finishing touches” on an application (or two) that I’ve been working on.  Then, as the New Year begins, I find myself in somewhat of a lull - perhaps looking at what’s next, evaluating the previous year’s work, or if I’m lucky - even being able to work on a project for myself!  That is what I’ve been doing to start 2009.

After spending so much time in the past months with maintaining and “tweaking” existing applications I have been able to actually start an application “from scratch”, and it has been wonderful!  My development environment of choice, Visual Dataflex (VDF), is in pre-release of its latest version and I have begun working with their latest pre-release distribution and have been using it for my “new” application - which is designed 100% for my personal purposes.  (I’ve decided that this developer is going to give himself the gift of a streamlined custom program for record-keeping, something he’s not particularly efficient at, and generally dislikes!)

In doing this I have been able to learn how to use new features provided in VDF, and also have been able to free myself of my “old ways” which were developed through years of using Dataflex.  I have found this experience to be a great opportunity to “think” in ways that I haven’t in the past, ways that will help me become a better developer producing better applications more quickly. 

As an independent developer it is always a challenge to take time for learning “outside the box” of an existing application.  There is always a tradeoff when considering “billable” hours vs “learning” hours.  During these difficult economic times some developers may find that they just do not have the work they would like to have, and I’d suggest that they take some time to “play” as a way of learning.  There is so much to learn, and so little time to do it!

Goodbye to 2008

I don’t know about you, but this year has simply flown by for me!  It has been a year of challenges personally as well as professionally, I guess that means I’m “normal” after all

At the close of each year I truly like to take a look back at where I was at the start of the year, and where I am as the year closes.  At the close  of last year I posted A Developers New Year Resolutions  never thinking at the time that it would be useful a year later to look back at it, but it has been.  The year started off with a bang, and I was genuinely embracing each of the resolutions and taking them on with enthusiasm.

In May, however, my personal “life” had to take front and center as the result of a family medical issue.  The resulting detour was immense, taking its toll physically as well as emotionally.  Some residual effects linger as the year closes, although they have nowhere near the impact as that period from May through October had. 

As an independent developer and basically single person business such an event has significant consequences.  There is a hugh impact in ones ability to service customers well — an absolute priority to me.  I certainly wasn’t ready for the energy drain it would take on me.

As for my resolutions — for most I grade myself at a C or C+ for the year.  Not by nature being a planner, I grade myself as a “D” however.  My resolution list said “I Will Plan” — testing — my work.  Shortcuts were taken with my testing on agreement of my major client who themselves picked up on testing more thoroughly than usual, knowing that I was shortcutting.  That was a situation that we made work.

Goodbye 2008!  Thanks for the memories!  I’m looking ahead to 2009 embracing those same resolutions I posted a year ago!

Weekends and the Independent Developer

There’s an old saying that goes something like “There is no rest for the weary!” to which I have been known to rephrase to “There is no rest for the independent developer!”.  The intro to my blog states “This blog deals with the questions and challenges of providing users with quality “custom” software programs…”, and over the past 15 months of writing this blog I’ve worked hard to stay at least somewhat on-target with that stated objective.  This weekend has actually made it easy for me to write my last blog post for this month — having provided me much in the way of “subject matter” to substantiate my “There is no rest …” statement(s) earlier.

This has been a weekend filled with activity for me — and opportunity to correspond via email(s) with clients for whom I’m working.  Now, while I have had plenty of communication with said clients, the good news is that because all of the communication has been via email, it has truly been un-obtrusive and no threat to my efforts in creating a work-life balance that works for me.  In each case, the issues communicated have not been of a nature requiring an immediate response — hence they have not been disruptive.

Truly in this day and age of technology and ever-present communication channels, we who are independent developers working from our homes have to fight hard to maintain work-life balance.  It is very easy to be suckered into working through a weekend, holiday, anniversary — you name it!  However, we do not have to be a slave to the communication when it comes in the form of emails — I think of them as a quitely soft arrival (I keep sound turned off so that I don’t hear them arrive - unless I’m willing to know).  I look at them only when I’m ready to — some weekends I never look, most of the time I see them within a couple of hours after receipt.

I, like many other independent developers I know, seldom are not working on a weekend — and our client customers (many of whom are also working on a weekend) know it.  Using email as an un-obtrusive means of communicating works – and the end result is a high service level and opportunity for work-life balance that works.  Seems like a win-win situation to me!