Small Business Computing

Holiday Madness

As we in the U.S. approach our annual Thanksgiving Day celebrations I am reminded once again of the importance of setting priorities for work-life balance.  This came to my attention as I found myself “filling-up” on “things”  (business related) that I could do during the time that my clients won’t be “…disturbing me…” about problems, new ideas and requirements or any such items.  YUCK!

I know that I am not alone in this custom development, IT consulting or independent developer arena in my ability to find more areas to fill up a holiday weekend than there are hours to fill up!  I’ve seen it over and over again how easily a potential change-of-pace weekend turns into just another few days — filled with events that frustrate and leave me feeling that I “lost” my weekend!  (Which of course I DID!).  It is even more disturbing to realize just how often the problem has been caused 100% by me!

While it is true that (sometimes) there can be “real” requirements to work on a holiday weekend, such as when a long weekend is the “only” time that such things as a major database re-structure or hardware upgrade can be accomplished.  Let’s face it, IT is a demanding (as well as rewarding) career, and sometimes that does require some “odd” hours.

My hope for this post is that someone out “there” who reads this will have a better holiday weekend because I posted.  To all — best wishes for your Thanksgiving weekend, and if Thanksgiving is not a part of your tradition I wish you a weekend of freedom from the stress and strain of your IT involvement, whatever that might be.  May your weekend be truly recreational for both body and soul.

Business Changes, Personnel Changes and the Custom Application

There’s nothing that I can think of to “shake up” business processes and the custom applications used to support those processes more than a personnel change.  This is most clearly apparent in the small company applications used by a handful of key users in the company.  If for whatever reason one of those key users is not available for an extended period of time and others are doing what was “their” job, questions are inevitably raised about “Why is this like this?  Why are we doing this this way?  Wouldn’t it be better to…?”  In my experience while changes in business needs can elicit those same questions, by far the most dramatic and in-depth questions come from the change of personnel doing a job. 

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 Economy and Custom Programs

Well, the DOW reached a record loss for one day of trade — we’re in a credit crunch (…so say the “experts”) — home values continue to drop in most areas — and in short, the economy is a mess! One of my favorite on-line writers (Bob Lewis) has posted a couple of great reads once again in his “Keep the Joint Running” page, articles written of course in the style of Bob’s which I find so entertaining. His posts of 9/22 and 9/29 are interesting “lessons” for IT in these questionable economic times.

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!

What keeps an out-of-date application in place

I had the opportunity recently to make some minor changes to reports originally created in the late 80’s. The application is a character-based app running on an “old” version of SCO Unix, and hardware that has been kept alive by some clever mix and match combination of “old” components taken from servers long ago taken out of service.  To say this is out-of-date is being kind - let’s say it owes nothing.

My first thought when I posed the question “What keeps an out-of-date application in place?” was that of course — it’s money!  While that jumped into my mind immediately, I began also to consider what else would be keeping the app alive.  For one thing, there is the fact that it is basic, lean and mean (read that fast response), and works well for what it was designed to do.  The issue here is that it wasn’t designed to do much of what the modern business requires it to do in 2008.  It is also difficult to support, although it doesn’t require significant support.

So what else might be keeping it going if money isn’t the real issue?  How about fear?  With any new implementation there is always a fear factor that has to be overcome.  What if the wrong application has been chosen?  What if it doesn’t fit as expected?  What if, what if, what if???  You can probably think of dozens of scenarios which might cause an organization to avoid replacing an application, but none of them would exist on any of the “best practices” lists.

It just so happens that in the history of this company there was a failed implementation of software which at the time was thought to be a good “upgrade” for the company.  Many thousands of dollars were spent on equipment, software, support and consulting fees for the project which never got completed.  It seems that the business processes that needed to change in order to get the desired results from the software were just too much.  The company was sold during this time.  Go figure!

(…although I don’t remember the year that took place, I’m pretty sure it was over 10 years ago

Information Overload

Information overload is a topic which has seen enough blog and article time to provide a generous amount of information overload on its own!  As an example, I searched Google for the term “information overload” and it returned the first 10 of approximately 2,160,000 “hits” (…but who’s counting?   :-)   No wonder we need data warehouses!  I figure that is probably a bit more information than this modest man can (or wants) to handle - yet of course as I scanned that first page of “hits” I had to check out a couple of them.

One of the hits that I followed in particular caught my attention and prompted me to both chuckle to myself and to think about my own habits.  A blog response from Noam Chomsky  really started me thinking — in response to a question about tips for handling information overflow he replied:  “I wish I could answer sensibly. I just can’t. You should see the room in which I’m working. Piles of books, clippings, manuscripts, notes,… All sorts of lost treasures buried in them.“  Sound familiar?

His response really brought home to me that my habits of saving information, whether it be printed material, sound clips, email or internet links encourages my sometimes overwhelming “buried” feeling - information overload is alive and well in my life, as well as “…all sorts of lost treasures…”!

Now, to get to the real point of this post — as a developer I believe that it is in my clients best interest to support them in providing the information they need to forward their businesses -  whatever that is.  It is very easy for me to provide them with too much information (…some say there can never be enough) in the form of reports, graphs and miscellaneous on-line “views” of their data.  However, I believe that it is a “key” responsibility of mine to constantly be aware of the tendency toward “information overload”.

User Reluctance to Application Changes

Some things just never seem to change, and user reluctance to application changes is one of those situations which it seems, is always present - regardless of the form of change.  Sometimes I’ve found that even changes which had been requested by users, and that they kept looking forward to, once made, the changes are received with grumbling and every excuse possible being used to avoid incorporating the changes into their routine.

The question is, what do you do about it?  What does it take to bring the user around so that rather than condemning the changes, they embrace them with enthusiasm?  The answer is actually quite simple, although time consuming — it’s one-on-one training.  My experience with providing “training” applications which the user can access on their own to learn new application features has been highly ineffective since the users do not spend the time needed.  A “classroom” kind of setting also has been ineffective for my clients since often it is key people in the company that need to use the application, and they have a business to run!  (…read this as they’re TOO busy for training!)

However, the 1-on-1 approach has proven effective consistently since it provides the capability to work with the reluctant user with “real” information, in their setting (…always do 1-on-1 at their desktop!),  and your presence allows for instant answers to questions and concerns as they come up in the session.

This kind of training can also provide valuable feedback for further development of the application — for one thing, it allows for experiencing “real issues” for users “IF” such issues exist.  Certainly as developers we hope that there will be no “real issues” with our pride and joy of application, but I’m sure we all have experienced them.  Seeing exactly how the application performs for a user is important - many a “little issue” that I’ve seen when working with a user 1-on-1 has led to better the next iteration of the application.

Independent Development Business

My work day started today with the usual quick scan through the multitude of emails that I receive daily.  I have always found this activity a gentle way to start my day (which generally begins somewhere between 5:30 and 6:30 AM).  I’ve also found that at times my attention is directed to particularly poignant articles relating to some facet of my business as an independent software developer.  This mornings find is just such an article.

My find?  “The myth of being successfully solo in business” is a brief article that caught my eye and started me thinking about just how dependent an “independent” software developer is.  Let me explain a bit without (hopefully) you not reading the linked article.

The article explores what is described as “…the myth of the successful solopreneur…”, and explores also how “…we can’t do it ourselves”.  Now, THAT is something I’ve realized over and over again through my years as an independent software developer!  However, my memory gets pretty short with certain learning I’ve noticed, and especially when faced with this myth!

The impossibility of doing all the things yourself that are provided for you when you are an employee seems to escape many of us self-employed, and often we think we’re some kind of super human who CAN do it!  I’ve personally had one of those reminders recently as the result of my wife’s broken ankle back in mid May.  Since the time of her injury, ALL of the household responsibilities AND the income producing responsibilities have been on my shoulders. 

Fortunately, I don’t have an office out of the home that I have to go to - but I do have the occasional visit required to my local customers.  All of these activities have at times been very much overwhelming — and certainly indicative that I “can’t do it” solo.  Through this period I have met with exceptional understanding from my clients and considerable help with meals prepared by friends and shared with us.

While what I refer to above might seem more personal than business related, I call it to your attention in light of the referenced article, and as another indication that being an independent software developer still requires others.  Professionally I’m a part of the Northeast Dataflex Consortium, a dedicated group of professional developers who support each other in many ways.  Those of us who are independent software developers are also dependent upon our vendors, customers AND indeed all of those around us in some way.

Sometimes the Obvious is Missing

We developers need input from our users!

This became very clear to me once again last week when I received an unexpected request from a user to add a simple lookup function to a field in their order entry program which has been in use (…and regularly enhanced) for over 5 years.  When I first received the request I was shocked to discover that such an obviously beneficial function would be missing.  In fact, my first thought was something like “How could [the user] miss it?  Of course there is a lookup there!”  Then, upon further investigation and review going back numerous iterations and versions I discovered much to my surprise that it NEVER was there — an obvious omission.

All of this led me to recognize once again the value of having a close relationship with my user community.  Working with the small & medium size companies that I do, it is generally commonplace.   This incident also pointed out to me that user and software developer/designer alike can easily miss obvious functionality enhancements.

P.S.  The program now has the desired lookup!

Choosing the Best Application Design Approach

Sometimes it isn’t clear when designing a new application just which of a multitude of possible approaches to the design represents the “best” approach.  Sometimes it may not just be the application design itself, but also choosing the “right” tool to accomplish the task(s) to be executed.  Sometimes it may be deciding something as different as whether to create the application as a web application or client application.  Once some basic design choices are made, like web or client, the designer may also then be presented with multiple possibilities for accomplishing the task at hand.  Choosing the best approach for accomplishing the task isn’t always clear.

Of course, there are those projects which are mandated to be web or client, design tools may be mandated, and of course there are the talents of the design/programming team to consider - which sometimes will restrict design to a particular method.  However, in my experience, there may often be many choices to accomplish a given task - that is to say, choices in how to produce a certain end result.

In reading a new ITKE blog Taming the Wild, Wild Web  I thought of a common example of what I am referring to.  One can choose to code a web page, for instance, using in-line HTML and specifying literally everything to be included on a page — OR — they can choose to incorporate CSS for example to accomplish the “look and feel” desired.  While an argument can be made that using CSS has many advantages — IF one has limited time and little knowledge of how to use CSS well the developer isn’t going to stop and learn CSS and then do the page.  (…at least that’s my opinion!).

There will always be pros and cons about a particular method to accomplish a programmed task.  Many times the “best” approach to accomplishing the task will be the method best known to the developer.  At other times the “best” approach may be the one that executes most efficiently - and at yet other times the best approach may simply be the approach that produces the desired end-result for the user, on-time and on-budget.

The Business Process — How Does It Get Complicated?

I wonder how many of the business processes which a company develops over time from its early days as a very small company to a larger organization become overly complex.  Of those processes, I also wonder just how many of them are the result of new demands on the process simply as the result of the growth of the company, and how many of them become “the way it’s done” out of habit or because of other requirements mandated by the business environment. 

I’ve worked mostly with smaller companies, often times businesses that have started off very small and grown to become multi-location operations.  As their growth has progressed the needs for tighter controls becomes increasingly apparent.  No longer can the business depend upon the memory of that one key individual who “knows everything” that’s going on — who knows the customers, knows the vendors, knows each employee.  As staff increases so does the “risk” associated with no longer having a close, trusted, personal relationship with employees, often co-founders of the company. 

Many of the applications with which I’ve worked were originally developed specifically to provide the growing organization a means to “get a handle on” information that many may need, but early on resided in the head of the “key” person.  The small company finds a way to get the job done - process is the least of concerns.  I believe that what happens often during the growth period is that as the need for defining the business process becomes clear, efforts to define the business process fail because there are “so many variables”.

Its at this point that I’ve found a company will generally make the buy or build decision for software.  Some will look at a vertical market package for their industry and decide that the “business process” required by the software is the way they should be running their business.  (Hey — it works for others - why re-invent the wheel?).  Others may find that they just can’t see themselves running their business “just like everybody else”, and they will choose to have a customized application.  Then there are those who choose that vertical market package, work hard to change their business processes to “fit” the software, and then find the “work-a-rounds”.

“Work-a-rounds” add a level of complexity to the business process that is generally not required.  If your business processes are too complicated - maybe its time to look at how much is a “work-a-round”, you may be surprised.