There have been a number of posts made commenting about a recent post on 37 Signals blog about “Why it’s wise to launch softly“. I always love to see my thoughts in print by others, or to see approaches that I believe in being touted as “good” methods. Such is the post I refer to, I could have written it myself if I weren’t beaten to it. (…and had thought of it). Myself, I always want to launch a project softly — get feedback — know what will work, and what users don’t like, or what is perhaps “clunky”.
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.
“Do You Really Need a Deadline?” is a post I found interesting in the light of my current “deadline” pressures. Related to the post, I also found comments on the post to be interesting, such as this one which said “I NEED deadlines to work. If I don’t have them, I don’t get anything done. The worst thing possible for me is to be given time.”
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.
My posts last month generally consisted of comments, suggestions and difficulties with preparing cost estimating of legacy applications. Recently I had the opportunity to come accross an interesting blog post which relates to “the other side” of the coin, that of preparing the RFP. While the post doesn’t directly relate to an RFP to replace an existing legacy application, certainly there are points of comparison.
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.
Yes there is ladies and gentlemen! End of story, NOT end of post!
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?
So many development environments to choose from, so little time to work with them! You may see something about an environment of interest to you, but wonder just what is working with it really like? Well, I stumbled upon a recent report of interest from Evans Data Corp. on the top software development platforms. Their report is loaded with useful information about the products evaluated: Eclipse, Delphi, Rational Development Tool Suite, IntelliJ, Visual Studio and Tools, NetBeans, Jdeveloper and tools, and Sun Studio.
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.
In these days of exceptionally “busy” screens within which operators can usually choose many options (…and sometimes ones which they shouldn’t), I have been placed in a position where I am being asked to create an application with minimal functionality entry screens! This design approach reminds me of the very simplistic (…also efficient, lean and mean) entry screens of the character-based applications I was designing in the 70′s and 80′s. No surprise here since the application being designed is truly a system based upon that early design approach and technology — and my customer describes himself as a “control freak”, and describes a co-worker as “even more of a control freak” than he is!
OK, so you’ve now got a general picture of a design criteria — Keep It Simple Stupid! Continued »
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 »
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.
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!
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.