I’ll continue with my comments on the list I published in “Cost Estimating Ideas for the Legacy Application Rewrite“. In previous posts I commented on the more specific areas, where in this post I’ll become a bit more generalized in my comment. These comments might well be considerations doing any estimating for an applications project, not just a rewrite.
First off to consider in my opinion is how well (if at all), you know the client for whom you are creating the estimate. This becomes particularly important as you try to answer the question of “What might you NOT know about?”, and “What are the time constraints for the project?”. If I have a history with a client on a potential project chances are that based on that history I will at least have suspicions regarding what I might know about, as well as any time constraints. If your experience with a client has been that you are told no particular time constraints exist, and suddenly time becomes a factor — certainly it is appropriate to take that into consideration. I will often quote differently when a time constraint exists since I know that any delays along the way will mean “pressure” and extra intensity to get the job done. I for one prefer not to be working with the intensity.
I wrote in my list “Can the legacy app “play nicely” with the new app — or must the new totally replace the existing immediately? Some may not relate to this, however, I have found often that a great way to get a new project off the ground might be to take a smaller part of the app and have it work in conjunction with the existing app. For example, with Dataflex (my preferred development environment) it is possible to have a Windows, web and character-based front end all accessing the same set of database files – they “play-nicely” together. However, this approach does require potentially more complexity to accomplish, and of course that must be considered in creating the estimate.
In my next post I will provide more comments and a general wrap-up of the series.]]>
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.]]>
My comments will continue in my next post. Please stay tuned!]]>
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.]]>
Then there’s the cost of estimating. What is the best approach to take with that? If time is money, then time spent on an estimate is worth something – who should pay for it? Landscaper friends of mine were talking about the cost of estimating in their business when I was with them last week – we agreed that when a project appeared to be more than just a few hours of work, charging for the estimate is more than appropriate, it’s a must. I have worked on estimates that I have spent 20 – 40 hours (and more) on, not all of which that I was paid for, and NONE of which I received anywhere near a desired minimum hourly rate! The goods news for me has been that those “big” estimates for which I was paid have historically produced long-term, profitable work.
Legacy application rewrites I believe are especially difficult to estimate since over the 15 – 20 year span in which the legacy application has been in use there have been (most probably) many significant processing “bolt-ons”, each of which will require special handling. These added features I find would be treated completely different using today’s development standards and tools, therefore necessitating basically redesign as if producing the application for the first time. (Let’s face it, you really are!).
This topic of cost estimating has been very close to me at this time since over the last month I have had the opportunity to estimate potential projects involving rewrites of existing legacy applications into “fresh” graphical applications. Working with other associates of the Northeast Dataflex Consortium I have had the opportunity to approach these estimates with some new ideas and outlooks. In a future post I plan on creating a list of considerations that hopefully will help all independent developers with their cost estimating methods.]]>
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!]]>
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.]]>
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!]]>
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!]]>
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!]]>