Launching softly provides ability to “tweak and revise” easily — something that the “big bang” launch doesn’t provide.  I’ve experienced my “Big Bang” launch thank you, never want that again!  August 1, 1999 is permanently etched in my memory as the implementation from Hell, as it is with others I shared the experience with.

In the referenced post I absolutely loved the statement that “With custom on-demand projects, clients often fail to understand that meeting a deadline and completing a project on time is the responsibility of both customer and vendor …”  While I’ve never really thought of it in quite the same way, I’d have to say that the statement reflects my experience completely.  I’ve often commented to associates that when I first meet with a prospective client I’m interviewing them as much as they’re interviewing me.  There are prospective clients with whom I’ve met that I hoped would never call me back. In many cases I had perceived in our preliminary discussions either that they wanted something for nothing, wanted yesterday with no responsibility of their own, or were so set in the “way it has to be” that we just didn’t “fit”.

As for deadlines, they can sometimes be set as the result of outside factors over which one has no control such as buying a new company and having to replace their system which was under the control of another larger, remote entity — after a certain date it would no longer be available.  The deadline is very real, as opposed to arbitrarily assigned deadlines based upon nothing more than “who knows what logic?”, maybe just a “nice-to-have” idea.

IMO deadlines are NOT evil — unless — they are totally arbitrary and unrealistic, or so structured for adherence that a vendor will sacrifice quality or reliability “to meet the deadline”, or invoke any one of a multitude of other negative events to “appear” to have met the requirement.  Let’s face it, that many need a deadline to get anything done is not uncommon, but may that deadline not be life or death.

Agile Development Improves ROI – But RFP Processes are Stuck in Waterfall is the posting to which I am referring.  Early in the article it is stated that “The typical RFP process for custom software development is looking for a fixed bid, thinking this will provide budget protection and guarantee ROI.”  There are many pitfalls to this way of thinking, not the least of which is that it doesn’t really hold up in fact, in a large part due to inadequate requirements.

Then there is the “feature set” to be considered, an area which I commonly dig into with my clients — always using the “…delivery of valuable software” idea of the Agile Manifesto.  As for features, the post makes the statement that “…studies show that 45% of features built under waterfall are never used.”  WOW!  The common cry of “If its not broken, why fix it!” should be replaced with “If it isn’t used, then why have it?”  Many is the time that I have been with a client and seen that there are always areas which just don’t get used.  Unused fields in a database always seem to be asking the question – what am I doing here?  Sometimes it is a change in process that has made it obsolete, but more often than not I find it is a matter of some program area which “seemed like a good idea at the time”, but which just never fit what was envisioned, therefore didn’t provide the “value”.

As for preparing an RFP — I wonder about the effectiveness of most RFP’s, and the referenced article helps me identify why, it seems to demand a waterfall approach, and I’m clearly into an Agile approach to development.

While doing some “cleaning up” around the office recently I ran into a design spec that I had the misfortune to encounter some 20 years ago.  It was submitted as a “Preliminary Draft”, weighed in at about the birth of a child (…only kidding, but over 100 double sided pages of small print), and was supposed to describe (as an overview) the specifications desired for a new manufacturing and inventory control system.  The project was scrapped after a number of months as not “fitting the budget”, which come to find out really couldn’t possibly have supported much more than that design specification itself.  I kept the document around to serve as a reminder to me of how NOT to design an application.

If a picture is worth a thousand words, then I figure that had the specs been graphically portrayed in that specification document, rather than verbal, its birthweight might have been reduced to that of a rodent.  As a side benefit, it may also have been read (…resulting in understanding)!  What a concept!  Then there might have been more of a budget for actually getting the project off the ground!

However, at that time the powerful time-saving and graphical development environments we have available today were more a dream than reality.  While I knew of COBOL programmers who seemed to think in terms of 80 or 132 columns and 24 to 80 row grids, and thus could very quickly place items properly on screens and reports, they were a special bunch!  Todays tools very much support the ability to a certain extent, to “design-as-you-go”.  It’s a wonderful time for development!  Anyone ever wonder what we’ll be using 20 years from now?

Since I work mostly using Visual Dataflex my experience with these tools is limited — yet my interest in them is high, so I found the report particularly informative.  The report ranks the tools in over 15 areas such as “Ready to Use out of box experience”, “Sample Apps”, “Database Development Tools” and “Integration with Databases”.  There are also charts and comment on overall ratings by development platform.

The report is freely available from Evans Data — I’m sure many who read this will find it an interesting read.

OK, so you’ve now got a general picture of a design criteria — Keep It Simple Stupid!  Purchase order entry for this application has boiled down to finding the item in a lookup list, giving how many you want, and setting up a schedule for delivery.  There is no vendor choice as an item purchased is always tied to a specific vendor.  There are no field over-rides, no additional comments allowed, just how many and when!  Not even cost entry is allowed when creating a PO.

But oh those master files!  Only a select number of employees get to setup the data in the master files.  Throughout the application it is the design of the master files and the information contained within them that dictate the information which appears on any purchase order, manufacturing document, shipping or invoice document.  All the data integrity resides in proper setup by the few with authority to do it.   This is in place to maintain absolute tight control over operator errors.  (There is an assumption that a shipper/receiver can count).

That brings me to the transactional entry screen design.  The KISS approach seems like such a waste of screen realty — maybe 3-5 forms on an entry screen, some display only info based upon selections, and maybe a “Save” button — all on a 1024×760 monitor?  These highly simplistic entry screens lend themselves very nicely to an AJAX browser design approach — an approach not yet into design of this project for this customer.

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.

• 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!

• 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.