custom application development

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.

Legacy Applications - What Keeps Them Running?

It can be a huge leap from the highly customized legacy application (which for many have been in use double digit years), to the newer graphical point and click or web based AJAX type application.  So my question today is “What keeps them running?”,  or perhaps a better question is what is it about them that keeps them in place for so long?  My questions arise once again prompted by a vist with a new client now running their legacy character based system well into the double digit year mark. Continued »

Applications - Why User Documentation?

I’ve stated before that my goal with applications I create is to provide an application so intuitive that if one knows the job for which the application was designed that the interface be so intuitive that no training would be required.  This is a lofty goal for sure — and not one easily achieved.  It might be better to set the goal to be more like 95% of the time “…the interface be so intuitive that no training would be required…”, or 98% or something like that.  My first answer to “Why User Documentation?” would have to be that it is what covers the shortfall percentage of design that just doesn’t measure up to the lofty goal.

Secondly I believe that most applications will have those activities which are only seldom performed, or performed only as a “fix” to something gone wrong.  The infrequently performed operations which just don’t fit into the everyday flow of the business function, and therefore also not of the business application should be documented for users.  Of course, any documentation available will be only as good as its availability.

Ready availability of documentation for an application, or more explicitly documentation specific to a particular operation is crucial.  As long as I’ve been around applications this has always been an issue.  First off, creating good user documentation (read this as usable user documentation), is not an easy task.  It can also be a costly task.  Ineffective and it won’t get used, unavailable and it won’t get used, confusing and hard to find answers and it won’t get used!

More often than not what I’ve seen is an attitude of “Why document - nobody ever looks at it anyway”, or, “Document the obvious, don’t worry about the details - let them (users) ask!”.  Personally I think application users deserve more respect than that.

Data Rot

Here in the Northeastern U.S. it is snowing outside and I found myself starting my day browsing through the myriad of industry emails I watch regularly.  Now, I’ve blogged previously regarding my thoughts on the “paperless office” (See “The “Paperless” Office –  Myth or Real Possibility?).  But this morning I found the article “Paperless office? Ha! How about a paperless life?” — and of course I just had to check that out!

While mulling over the “…paperless life…” idea I recalled how yesterday while watching TV in the morning I was introduced to the term “Data Rot” in a CBS news story.  I’d never run into the term but I immediately could relate to the terminology, as well as the concept of data formats “going away”.  (I was enthralled with the “wire recorder” and “reel to reel” recorder when I was in my ‘tweens!). 

Anyway, “Data Rot”, the “paperless office” and “paperless life” all are interesting topics, and looking back at what I’ve seen for changes in my life, I can’t help but wonder what our lives will look like in 2080?  One thing I’m sure of, however, death and taxes - not necessarily in that order!

Rambling Thoughts on These Times

Yesterday I had the opportunity to exercise my Massachusetts civic responsibility by reporting to a county courthouse for possible selection as a trial juror.  Having been before I knew something of what to expect, i.e. long idle periods of wait time, a quick video explaining the responsibilities of the jurors, and the distractions of being in the company of some 20 strangers, each of whom had “better” things to do, and none of whom was completely comfortable in the environment of the jury selection room.

For myself, one of the distractions I brought with me was the latest issue of Entrepreneur magazine.  Entrepreneur is a magazine which I like to scan through to extract “tidbits” to stimulate my brain and I will often find items which relate to something I’m either working on, or which I think will be useful down the road.  Yesterdays “scan” was no exception.  Heres my “tidbits” and comment:

• On Innovation — ref Entrepreneurs Innovate every day - Two points in particular caught my eye here.  For the self employed developer, or the small development group the ability to “Ask better questions” can be invaluable - try it, you’ll like it!  In “Seek Feedback” the statement  “Your main goal is to benefit your customers…” couldn’t ring any more true - especially in these times. 
• On starting a business as a “mature worker” - Not Ready to Retire? - be prepared to get honest with yourself when you answer the question “Am I really a self-starter?” — What?  You haven’t an answer yet?  Then, in my opinion, you probably are NOT a self-starter!
• On frugality - Frugality is back - ‘Let’s look at how we get work done and see where we can make changes.’ - this statement caught my eye immediately!  If as an application developer you have an opportunity to participate in this activity it may provide an opening for changes to or new innovative applications.

Changes, Users and Resistance

Let’s face it, software development and design is complex - even when it’s simple

There are some areas where it seems that no matter what is done there will be unhappy users - at least for a while.  I found myself in that category last week when it was announced by Data Access Corp that their beloved newsgroup forums were going to be moving away from the “old fashioned” newsgroup format to a new web-based format for their Dataflex and VDF (Visual Dataflex) groups.  Almost immediately the resistance began showing - and I was surprised to see myself as one of those initially disappointed to see the move.  I had a lot of company!

Once I realized my resistance I immediately recognized my behavior as like that I’ve experienced from users of my custom applications.  “If it ain’t broke…” - you know the rest!  I realized that I had become very comfortable with the status quo - after all, it had been in place for many years, was reliable, and known.  I have become proficient working with it, using it in the way I most needed to - it has been serving my purposes just fine.

However, as with the rest of life, change is inevitable.  While we welcome some changes, it is our nature to be disturbed by others - we get to make the choice of how we make the most of it.  The reasons for change may vary greatly, but through my rose colored glasses I find that most are made for good reasons (…though not always reasoning that I agree with ). 

I suspect that once the changes are made to the Dataflex newsgroups I will become comfortable with those changes, but until then I’ll be one of those grumbling.  Hopefully it will help me to tolerate better those resistant to the changes in applications which I make.

Beware of the “By the Way”,s

They often start with the statement “By the Way…”, or another flavor is the “While you’re here…”, or maybe the “I was thinking…” flavor — they are in a class of communication sometimes laced with peril, sometimes opportunity, and sometimes just a lot of work — but ALWAYS revealing!  In my experience I find that after a barrage of “By the Way”,s at a clients it takes me a bit to recover.  “What just happened?” is running through my mind, followed by “Did I get everything done that I needed to?” Usually I need to reflect upon the “By the Ways” after a period of decompression.

Today I spent 5 hours at a client site and since I was prepared for the inevitable “By the ways” I was not taken by surprise when they came.  One thing I love about “By the Ways” is how the question or comments following them reveal the needs or desires of the client user community!  These expressed “By the ways” may indicate shortcomings with the network, application or processes themselves.  Regardless of their nature on any given visit, it presents an opportunity for the service provider who is keyed into hearing the needs of the client their servicing.

A provider can leave a “hero” — who wouldn’t want that?  For the developer hero they may provide new work as the “I’ve been thinking…” becomes a “Let’s do it!”  Perhaps a better title for this post would have been “Be Aware of the “By the Way”,s

Data Normalization - Know Your Data

A post here in these ITKnowledgeExchange blogs that recently caught my eye was this one written by Stephen Harris entitled “Data Challenges Can be Solved With Business Intelligence“.  It is a rather lengthy post touching on several points about data challenges and BI.  What I immediately latched onto in his post was what he refers to as a motto - “Thou shalt know thy data“.

While I have never phrased my firm belief in knowing your data in the way he does, I certainly agree that knowing your data is an absolute must.  Furthermore, his reference to cleansing, auditing, securing, managing and refreshing data is also an essential ingredient toward any meaningful reporting - never mind the special requirements for an effective BI implementation.

Once again I find myself “down sizing” information and ideas I read about to the needs of the businesses which I service, the small ones.  I’ve blogged recently about reporting requirements in these economic times, and certainly “…having information about your business at your fingertips…” is critical, not just a “nice to have”.

Reporting, BI and data “cleanliness” all depend to some extent upon the normalization of the data.  I can’t imagine trying to normalize a database without knowing your data.  If you would like a quick introduction to the topic of normalization I found “Introduction to Data Normalization: A Database “Best” Practice” to be an excellent place to start. 

As with so many areas in development there are multitudes of tradeoffs which come into play with the design of a database.  It is absolutely critical that the developer know and understand the data pieces (fields) and how they relate, but just as critical is that the developer understand the reporting requirements and other characteristics of the data, the database itself, the network and hardware platform, and “how” data will be queried.  Many speed issues can actually be caused by a database which has been normalized to such an extent that in order to provide the reporting required in an acceptable time span many extra steps are required to prep the data for the presentation sequence desired. 

The more up close and personal a developer is with the data the greater the opportunity there is to evaluate the data quality.  After there have been a number of changes in the form of additions and subtractions to fields or tables in the database it is a good practice to review the design again to determine if there are changes that should be made to further normalize the database.  My experience indicates that often changes are desired.

Identifying Potentially Valuable Custom Applications

Without fail, in my experience as a developer any potentially valuable custom application project has been the result of identifying some area of operation which:

• Has become unwieldy, requiring too many steps or multiple data entry
• Has become more and more demanding as a result of increased volume
• Always seemed to be behind time - trying to play catchup and not succeeding
• Required information availability not currently or effectively available
• Just “seemed” to take too long to accomplish

My post Application Value is an excellent example of creating a custom application because of unwieldiness.  Another application which I designed that provided for scanning and categorizing of tax exempt certificates was an application which solved all of the issues mentioned above. 

Availability of information is a key factor in identifying value - i.e. An operation may be required to maintain original records  to produce during audits, yet, that same information may also be required at out-lying locations.  The choice can be to maintain a file at each location (trying to keep it up-to-date at all times of course), or somehow provide the means to quickly access the information via a custom application.  “Scanning and Cataloguing” such information can provide the ready access required to solve the problem - and there probably isn’t an “off-the-shelf” program to help!

Bottom line to identifying potentially valuable applications — Review operations closely to identify any of the categories listed above.  Once identified - it’s time to get creative!