I’ve often written here about software expectations.  In my experience end users are often looking for (maybe even expecting) perfect solutions to their software needs, but I believe that is not possible.  The expression, “one man’s junk, another man’s treasure” kind of applies here.  The definition of “perfect” among evaluators will vary as much as the individual personalities of the evaluators.  Marketers, of course, describe their “perfect” solutions with charm, grace and slick that defies logic.  Save us please!

The reality of software development and testing is that a series of trade-offs has been made to arrive at an acceptable, functional and apparently “bug free” application.  There will always be decisions made such as feature set vs cost to produce the feature set.  Sometimes software with “known issues” is released – possibly because of cost concerns, possibly because the need is so great that expediency is the driving factor.  (In those cases, however, it is quite possible that a work-a-round has been identified, or that the known issue exists only when a user goes down a path which they shouldn’t be going down to begin with).  Yes, in that case the software “should” prevent access to that path, but I’ve certainly seen many an instance where the time and cost to do it just wasn’t worth the effort when user training “should” take care of the issue.

This morning Bob Lewis of IT Catalysts once again caught my attention in his newsletter “Keep the joint Running“.  I’ve often mentioned his writing in this blog, and once again I am moved to comment here.  It was a simple paragraph within his writing that prompted me to immediately say “Yes!”, “Right On!”

He stated that “When developing software, or when designing business change even more, adherence to specifications isn’t the goal.  It can’t be, because each set of specifications is used only once, is open to interpretation besides, and usually turns out to be the result of incomplete thinking...”. (Italics added).  Bob’s statement quoted here is exactly the reason why I have such an “attitude” regarding most specifications.

My very first post in this blog “Please Hear What I ‘Really’ Need” was actually my way of stating what Bob says above.  My post is very much the story of a project gone wrong with the “incomplete thinking” of which Bob mentions.  Creating custom applications, specifying custom applications and designing custom applications is NO TRIVIAL TASK!  Don’t try this at home!

By “looking ahead” what I mean is that the developer might be working on a custom application with a particularly narrow functionality focus, yet be very aware that the functionality desired now will probably NOT fit the needs in the future, perhaps as soon as a few months.  While in the program where possible it may be desireable to build in the functionality desired for the future, but somehow “turn it off” for the current application iteration.  Doing this of course assumes a long-term commitment to the application and maintenance of it.

A common way to create an application which can be “flexible” in this manner is through the use of what might be called “switches” — or another term I’ve seen used is “parameters”.  These have proven to be quite effective — to a point at least.  There does come a point in time I believe that the value of “switches” is no longer useful.  I actually worked with some software where there were so many “switches” to be set (they bragged about having over 4000!), that a week of “training” in setup was required.  Unless the application is going to be used in a large environment with a dedicated IT department that would be (IMO) excessive.  Additionally this software had many dependencies built into those “switches” – i.e. if parameter 2003 is set to true, then 3014 and 4002 must be set to false.

As with so many things in software development, there are always tradeoffs, as well as a multitude of considerations.  I believe that the more of these types of considerations that are taken into account throughout the entire development life cycle, the better will be the resultant software.

It seems that in this case there were “updates” loaded onto the system which upon the reboot replaced the working versions of the dll’s with incompatible versions.  The “demo” program had been reviewed months ago, determined that it wasn’t desired, but left on the system anyway.  By the time of the system reboot the consultant called in to address the problem was of course told “Nothing has been changed!”  Yes, we did have to take the system down for an extended power outage — but it booted fine – “…no errors…”. 

It took a team 2 1/2 days to establish the cause of the problem – that being that at the time the “demo” software was loaded certain dll’s were being “used” and therefore would not be replaced until the next reboot of the system.  By the time that reboot happened nobody ever suspected that the “demo” software load was the cause of the problem.

Had the system been rebooted after the install the “issue” and its cause would have been immediately identified.  Months later, that wasn’t the case.  The shortcut? Not rebooting after the install.  The nightmare?  2 1/2 days of anguish with printing not working.  The solution?  Reboot after loading new software.

As an independent developer I’ve always had to be working with multiple projects at a time, and somewhere deep down in my being, I wished that I could just have one project to work – from start to finish!  The problem with that idea is that for one thing a custom application project never seems to end — mostly as the result of constant improvements being made to the application — or “tweaks” as one of my customers call them, so there is seemingly always something more to be done. 

However, coming back to a project can be challenging.  It can also be an indication to one as a developer of how much they’ve learned in the say, six months that a project sat without being worked on.  This is a good thing!  Whenever possible when I have identified that some previous work can be improved upon to simplify or somehow make the code more maintainable — if at all possible I make the change.

Another thing I have experienced after coming back to a stopped project is that very often I find that in the time lapse since last working on the project the needs of the user community for which the project is designed may have changed.  Certainly it is imperative that before going ahead with any stopped project there be clear communication with users or as a minimum the person ultimately responsible for the project from the business need standpoint.

Coming back to a project can be exciting — but it can also bring new requirements, expectations and challenges.

In a similar vein I also remember being in a meeting with our previous software vendor where, trying to make light of our “concerns” with the ever increasing software support fees which we saw as getting us nothing, this president quipped jokingly “…gotta keep up our cash flow you know!”  That statement was the opening of the exit door for that software and vendor — never forgotten by our company — and referenced many times over as the years went on.

While I don’t mean to suggest that either of these comments represent major attitudes of an application vendor to their customers, the examples above do point to an important attitude that (I believe) applications vendors “should” have — and that is “listening” to their customers expectations and really “hearing” how their software is, or is not, meeting the customer expectations.  I’ve blogged in the past about “hearing” in my post “Please Hear What I Really Need“.  This kind of active listening goes a long way toward managing software application expectations.  I highly recommend it!

I have been dealing with a couple of situations in the past weeks that fall into this category — and the end result of those questions is, and will be, a much “cleaner”, “user-friendly” and “efficient” program.  The change is good!  It seems that the longer an application is used the more “set in our ways” we get about the program just “being” a certain way – rather than challenging either the process or the program.  My clients are always encouraged to be on the lookout for potential changes to make their jobs easier, that’s just the kind of relationship that I’ve built with my clients, but it seems to take some dramatic change to elicit new requests.  In so many cases the changes are not necessarily extensive — often just a “tweak” here or there that over time makes a significant contribution to efficiency. 

The article for which I was interviewed is a well written piece which I will not try enhance.  (It is already full of my thoughts during the interview!).  I expect that readers of this blog will find it interesting.  The article entitled “The Beginning of the End: Defining Project Closure” is a recommended read.

Much is written about interface design. For years we’ve worked hard to provide intuitive “user-friendly” interfaces for our applications. Much has been written about visual presentation, and many options for changes to the visual presentation such as “skinning” have been introduced.

Perhaps, however, the most important of all the considerations for an application should be the application response time. I’m not aware of any user who doesn’t get impatient with poor response – defined here as a response time meeting their personal expectation! As more and more users (ADD or otherwise) become frustrated with either speed issues OR for some, the cluttered screen, it seems imperative that we as developers be constantly on the alert for signs of this frustration brewing. My experience would indicate that most computer applications used in a business environment are not being used by “computer” users, but rather by users who understand the task or job they are required to do, and (in some case, regrettably) must use the “computer” to accomplish the task.

Application design is no trivial task!

Myself, I look at these tough economic times and wonder a number of things — starting with “How will this economy affect my customers?”. (…and of course as a follow-on to that, any projects which I am doing for them — and of course in turn, their ability / willingness to pay for my services.) All of these questions are something which I cannot answer at this time.

However, each of my clients has committed to making their operations streamlined through the applications which I create for them. In each case for my clients, their gain is perhaps the saving of an employee expense that might have been to handle increased volume (…or maybe requirements), but is not needed as the result of the efficiencies gained through the custom software I create for them. In tough economic times when an operation is running lean and mean every efficiency gained becomes significant.

To meet the criteria needed to justify the expense in these times, projects probably will not be ones to “pretty-up” an out-of-date application, but rather introduce productive and new functionality. I believe that even in these tough economic times there will be new opportunities of this kind for independent developers such as myself. I certainly hope so!