Business Application Value

Technology Sales Styles

A recent article that I saw in a Computerworld email caught my eye and my interest.  The article “The six most infuriating tech sales styles” had me salivating at the very thought of the possible content contained in the article even before I opened it up!  The way I figure it, most of us that have been in IT management and around the “tech sales” arena can identify many of the types referred to in the article, I certainly can.  Heck, some of us might even BE one!

The article states “…That IT salespeople just don’t listen is a familiar refrain from technology buyers…”, and that “…too few of them act as honest advisors and problem-solvers…”.  Isn’t THAT the truth!  Just thinking about the recent experience that I’ve had trying to find proper RAM for an older server has brought at least 3 of the “infuriating” sales types into focus for me.  Continued »

Defining “Just Enough” Application Requirements

A little over a week ago an excellent tip was published regarding software requirements - “Approaches to defining requirements within Agile teams“.  While this tip directs itself to the needs of an Agile team, it serves as an excellent read for the software developer who is dealing with custom applications, and I believe applies as much to the custom development arena as Agile. Continued »

Application Code Maintenance vs Re-Creation

Which would you rather do — maintain an existing application’s code or create (maybe re-create) an application from scratch?  Obviously, it would depend upon the complexity and size of the application, and perhaps the tools used to create the app — but I believe that at some point after an app has been in service for a while, it reachs a point where I’d rather re-create rather than do maintenance to bring it up-to-date.

It has been my experience that somewhere in the 5-10 years of use range between hardware changes, O/S changes, functionality additions, “bug” fixes and patchs for the various changes — it becomes time to “rebuild” the application.  Again in my experience, what I have found is that the code appears to resemble more a patchwork quilt than that of a logical program by that time.  This fact appears to be one of the best “selling” points to use when approaching the idea of re-writing an application with the management that will have to pay for it. 

Our off-the-shelf software creators take care of this for us — we get what they want to give us — like it or not.  I won’t go off on a rant about application “bloat”  (…which I am very capable of doing!).  With our custom application programs we DO have an opportunity to evaluate and re-design according to the latest techniques, and add functionality (or not) in an orderly - maintainable - fashion.  I don’t suggest adding functionality “just because you can”, yet if it “fits”, if it adds to the useability of the application, then consider it.

There is many a program which I have re-written as the result of a re-evaluation of the application.  Particularly I will choose to re-write when the application has become a “bear” to maintain.  Sometimes the user sees no change, yet an application which can be easily maintained and is up-to-date with the technology is (at least in my book) always preferable.

The Buy, Build or Ignore Decision

A recent visit to a doctor’s office this week channeled my thinking once again toward the simple applications that can save time in any environment.  As I was checking in at the registration desk, it was noted that they did not have the latest copy of my insurance card.  I gave the receptionist my card, and card in hand she walked to the back of the office to the copier, where she leisurely made a paper copy of first one side and then the other.  She then walked back to the front of the office and passed my card back to me, adding the two 8-1/2X11 mostly blank sheets of paper to my file.

This was one of those times when I wished I had a stopwatch in my pocket.  Yes, it has become just a part of her daily routine.  It seems like nothing, but this is a very busy office, and the receptionist figures she makes that trip at least 20 times per day.  I know that this journey of hers took approximately 1 minute, and used two sheets of paper.  Anyone care to estimate the cost of doing this on a yearly basis?  Monthly? Daily?  It certainly adds up!

Now, what might it take to create a simple application to scan and electronically store this information?  Recently the most requested functionality I’ve been adding to my custom programs have involved scanning application integration.  One can get as complicated or as simple as desired — and a high level of integration can be costly.  However, a simple database coupled with a scanner can be a powerful addition - even if only a temporary one.  It wouldn’t take much time before the cost of such a simple solution paid for itself.

Anyone else see inefficiencies easily and cost effectively addressed (even if incompletely)?  I see them all around me — but maybe I’m the only one :-)  I suspect not however.  I commonly hear from clients that they’ve tried the idea of scanning “…but it was too complicated…”.  It needn’t be, but scanning applications like so many others have fallen prey to the “bloat” we have unfortunately become accustomed to.

Custom Software Application Quality Takes Time

After returning from a 16 day road trip, I found myself immersed very quickly in “issues” at a client’s site, much to my dismay.  Fortunately, the issues that greeted me upon my arrival were not those of the custom programs being run by this client, but rather network and server issues.  Certainly this was another indication to me of just how inter-related the software that I develop is to the network and server environment that it runs within.  I understand that many developers do not need to deal with any of these sorts of issues.  However, since I’m dealing with small businesses, there are those times that I do have to be involved with their server and network issues.

I was also reminded that one of the components of software application quality is that it runs consistently and reliably.  In spite of the issues they have been dealing with, it was encouraging to see that “my” application has continued to perform as designed and desired.  The situation has also served to remind me that producing a quality software application requires significant advance planning.  The process takes time.  Given the tools that I work with, I find that I spend much more time with the design considerations and testing, than I do with the actual coding of an application.  While I’ve never measured, I suspect my design/testing time probably accounts for three quarters of the time I spend on a new application.

I find that software maintenance and updates seem to take about the same amount of time.  I believe that one must carefully consider what it really takes to get what you want from a custom application prior to starting on a project.  It has been my experience that too often there is not enough consideration paid to the fact that it will take time to get the application to where it achieves maximum efficiency.  Certainly this plays a big part in choosing to create rather than buy.

Application Requirements, Desires, Business Value and Costs

The title of this post indicates one of the most critical areas, I believe, that needs to be addressed when considering custom applications software.  Most non-IT persons seem to have difficulty separating what is truly an application requirement and what is a desire for an application.  Naturally, a real requirement versus a desire has significant impact on the business value of an application, and of course its costs.

Of course, there are the users who are doing their job day-to-day and don’t really see anything as a requirement for an application.  They get their job done!  What is the advantage to them of doing it in a different manner?  Some potential users of a new application quickly see an advantage to having a new system, or changes made to an existing system. These users seem to instinctively understand the value of what is proposed, or the value of changing the system.

Change is difficult for most application users.  When faced with a new application it always seems to be the worst thing that could have happened to them.  They like the “old” way that has worked — tried and true.  (..yes, the same one they’ve complained about for years!).  But generally speaking, give them a period of time, maybe as little as a week, perhaps two to three weeks, and suddenly the new system is the best thing that ever happened to them.  Many have excellent ideas whcih they are glad to give.

Within a small business, at least businesses of the size I often deal with, what really exists is a collection of users each with their own unique idea of what a system should do — which is based upon their specific responsibilities.  In most instances my experience would say that they have no idea what it takes to computerize what they’re looking for.  That’s truly where the talent and experience of the analyst comes in.  The analyst must ask many questions, and they must be carefully phrased in order to have a meaningful answer returned.

It’s up to the analyst to sort out the true application requirements and what is a desire  — it’s the responsibility of the analyst to talk with the business owners or other knowledgeable management to establish what the business value of the requirements and desires is.  Then, of course, it is also up to the analyst to establish the cost.  This work is not trivial!

Software Quality and Ethics

Not many articles come along about which I feel I could become a cheerleader.  However, yesterday’s news on SearchSoftwareQuality.com featured an article entitled Test Driven Development and the Ethics of Quality – that is just such an article for me!  [Imagine a smiling, clapping Happy Face Here!].  I have been a believer in producing quality software since my early days of software development in the 80’s.  I must say that I never thought of software quality as an ethical concern.

Within this article, associate editor Jennette Mullaney uses a number of quotes from Robert Martin, who is the founder, CEO and President of Object Mentor Inc.  I really can’t say enough about this article — as it would appear that Mr. Martin and I are completely in agreement.  He thinks the way I do — which some might say is bit of a scary thought — for Mr. Martin that is!

I have been saying for quite some time that this is a fantastic time to be doing software development.  We as developers have multiple tools and capabilities available to us which greatly enhance our capability to produce quality software.  I believe that our customers have every right to expect nothing short of quality software from us as their developers.  This article makes reference to such topics as unit testing, agile development and test driven development(TDD).  If you are a developer and want a boost to help you commit to quality — read this article.  I highly recommend it!

Agile development methods and application value

An article entitled “BT adopts agile programming” came to my attention today, and had me thinking about how the development method used for a project can have a significant effect on application value.  BT as perhaps you know is the British telecommunications group, and they have seen significant productivity as a result of using agile development methods.  They began using agile development methods back in 2005.

The article I have referenced indicates that using Agile development methods they realized software development cycles which were a minimum of four times faster.  Given the size of BT, it takes no stretch of the imagination to understand how agile development methods have had such a significant impact on the application value.

Since a part of application value is established by the cost of developing the application, certainly the cost savings as realized by BT have a significant part in establishing application value.

I highly recommend this article as a good read.  In addition, there is another article that also makes reference to how BT utilized agile programming.  “Agile Delivery at British Telecom” is also an excellent read.

Measuring Application Value - Step 2

In my previous post on measuring application value, I stated that the first place to look in establishing application value, is to complete application requirements definition.  Once you have clearly defined what the application is to consist of, and what value you expect the application to provide — you understand the business process that the application addresses and understand the value of having that business process improved.

With the requirements clearly defined, the next step is to establish, as a minimum, some key milestones that need to be met in order to accomplish the task at hand.  A project management tool can help in this endeavor.  One can get as detailed or general as required by the specific project, but with these milestones in place it provides a basis for creating a timeframe within which each task can be accomplished.

Once the timeframe has been created, it is a relatively easy task to then assign a dollar value for the time given an estimate of the individuals to be working on the project.  This approach can work as well for a large project as for a small.

Your work is not done however, because a thorough examination of your milestones will be required in order to determine the proper approach to completing the project.  That proper approach may take into account the particular development tools to be utilized, the pool of talent available for the development, or perhaps also require you to re-evaluate the steps to be taken as the project progresses.  Establishing a clear approach to the problem will go a long way toward establishing and measuring the application’s value.

More Considerations for Application Value

It was with great interest that I read a SearchSoftwareQuality.com editorial written by editor Michelle Davidson entitled Don’t Shrug off Buggy Software. In her article, Michelle writes how often, software development teams are in fact, working with projects that can have a life-and-death effect on people. She states , “If something is not done properly, not tested or not fixed, people could actually die. Software defects on planes or automobiles can cause deadly crashes, defects in air traffic control systems can leave pilots unable to fly safely, and defective software in medical devices designed to help people could actually hurt them.”

Talk about application value!

Once again, I find myself wondering - how would one establish the value of such an application? I seriously doubt that any of us would say it’s not a job worth doing right, or that it doesn’t have value. Just how much is a life worth? I’m sure you’ve experienced with each visit to your doctor, the increasing use of computers, and thus software. My Dr. has been dedicated to the latest of technology well before the time that doctors began to recognize the value of computer systems, and networks for small offices tended to be a nightmare.

I’ve had an opportunity to speak with him about the application program which he has been using for the last two or three years, and interestingly enough, the software he uses was originally designed by a doctor during his internship. He was particularly impressed with the software because it just seemed to provide him with everything that he wanted at the time.

Designed by a doctor, for doctors. I believe this is a software ideal not only in the medical field, but also for most industries.