June, 2009

Application Launching — Softly Please

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.

The Application Delivery Deadline — Good or Evil?

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

Custom Application RFP Process Approaches

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.

Application Over Design — Is there such a thing?

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?

Software Development Platform Comparisons

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.

Application Design for Tight Operator Control

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 »