Custom Application Development: Buy, Build or Ignore?:

Small Business Computing

May 7 2008   12:03PM GMT

Technology Sales Styles



Posted by: Joe Coley
Custom software development, Business Application Value, Software application development, Small Business Computing, IT Management

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 »

Apr 25 2008   5:42PM GMT

The Buy, Build or Ignore Decision



Posted by: Joe Coley
Custom software development, Small Business Computing, Business Application Value, Business process automation, Database application, Software application development, Database

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.


Apr 18 2008   4:48PM GMT

Custom Software Application Quality Takes Time



Posted by: Joe Coley
Development, Business Application Value, Custom software development, Software Quality, Software testing, Small Business Computing, Software application development

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.


Apr 9 2008   2:35AM GMT

Application Requirements, Desires, Business Value and Costs



Posted by: Joe Coley
Custom software development, Business Application Value, Business process automation, Software Quality, Small Business Computing, Software application development

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!


Apr 4 2008   4:44PM GMT

Of spreadsheets and databases



Posted by: Joe Coley
Custom software development, Business process automation, Small Business Computing, Software application development

I had a rare opportunity last evening to have a conversation with my brother-in-law and our conversation got me to thinking once again about the use of spreadsheets as databases.  It seems that my brother-in-law is quite the guru at using the Excel spreadsheet.  As our conversation progressed, I talked about a simple but powerful application that I had created for one of my customers.  He questioned why I wouldn’t just go ahead and create the application using Excel.  He said that he could do everything that my application did in an Excel spreadsheet, and I had to agree with him — to a point.

My first thought was that the application I was describing was designed from the very start to be a multiuser system.  The application user community I created the system for would not be tolerant of opening up the spreadsheet only to find they couldn’t change it because it was locked by another user.  I also made the point that users doing the data entry had a hard time handling columns and rows and where to put information into something such as a spreadsheet.  Of course, he said that forms to allow easy data entry into a spreadsheet can be created, if one is knowledgeable enough about how to do it.

Bottom line, our conversation once again pointed to the value and requirement of truly establishing the functionality desired from an application, and with those requirements in mind establish what tool to use to create the application.  There are so many variables to consider, not the least of which will include the prospective user group.  He did agree with me that there had to be some knowledgeable person able to create a spreadsheet that would duplicate my application.  My experience with the small companies I’ve worked with, is that there is no truly knowledgeable and experienced person on their staff to create the kinds of programs that a developer can create.


Mar 28 2008   8:00AM GMT

“Getting Real” is Un”Real”!



Posted by: Joe Coley
Custom software development, Web applications, Business process automation, Small Business Computing, Software application development

After my last post where I strongly conveyed my misgivings regarding on-line web apps I found myself looking at a few web apps to see if I were going to have to eat crow after my post.  While crow is not on my immediate menu, I have found that by looking into some of the referenced services included in the article “Work Smarter” that I referenced in my previous post I have found a VERY interesting book — available in on-line pdf or paperback, or just for on-line viewing — “Getting Real“. 

My title for this post indicates the general reception that I immediately gave this reading.  It is at the same time an excellent writing and expression of what I believe software “should” be, and also a controversial, helpful, destructive, right-on — OR totally Un”Real” approach to software development!  You decide!

Is this where application development is heading?  Is 37signals.com ahead of their time?  Do you agree with the concepts of this book? …partially agree?  Or perhaps vehemently DIS-agree?  Is “Getting Real” - “Real” — or Un”Real”?  As for me, I haven’t decided as yet, but I did sign up for one of their services to “try” the idea.  Time will tell I guess! 

…and I must admit that I was impressed with the user interfaces that I saw :-)


Mar 27 2008   6:30AM GMT

Web Applications, Small Business and Trust



Posted by: Joe Coley
Business process automation, Small Business Computing, Web applications

Work Smarter” is the name of the article I read in the April 2008 Entrepreneur Magazine which has prompted another blog post about web applications and their role with small business.  The whole idea of having my key business information and functionality in the hands of another company over which I have absolutely no control is frightful to me.  Continued »


Mar 18 2008   6:16AM GMT

Trustworthy Computing



Posted by: Joe Coley
Custom software development, Software Quality, Software testing, Small Business Computing, Security, Software application development

Since reading the white paper entitled “Trustworthy Computing” on the Microsoft link provided by reader Willie Robinson I have been thinking about the concept of “Trustworthy Computing” ever since, almost to the point of distraction — so I figured it was time to blog about it!

I first noted when reading that Microsoft paper that it was dated in the year 2002.  This prompted me to try a Google search on “trustworthy computing”, and I discovered a recent article posted on campustechnology.com entitled “Trustworthy Computing: Examining Trust“.  I found this article particularly interesting because very early on a reference was made to the fact that there is still a long way to go.

I have found myself wondering since reading the Microsoft White paper, just how possible is it to develop the same kind of confidence and trust in our computing environment that we have with our automobiles or telephone?  Computing, however, seems to be an area where there is an every day cat and mouse game being played between the good guys and the bad guys.  What happens when a good guy goes bad?  That has happened!

It seems to me that until the larger issues of global cooperation and trust are resolved, we will not see global trustworthy computing.  On the very first page of Microsoft’s “trustworthy computing” white paper, they state “…  Because computers have to some extent already lost people’s trust…”.  My experience would be that this is a gross understatement.  Significant data breaches have shaken the security foundation to its core, and significantly eroded trust that has been built up in recent years.

If this topic interests you, take a look at this most recent article that I’ve referenced above.  It also is a great read.


Mar 12 2008   6:49PM GMT

Measuring Application Value - Step 2



Posted by: Joe Coley
Business Application Value, Development, Business process automation, Custom software development, Database application, Software Quality, Small Business Computing, Software application development

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.


Mar 6 2008   2:27AM GMT

More Considerations for Application Value



Posted by: Joe Coley
Business Application Value, Development, Small Business Computing, Software application development

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.