Networking

The IT Worker Telecommuting

Somehow or another in spite of my best efforts to escape computer-speak when I’m not actively at work it seems that even my personal “life” is laced with computer and IT geeks.  Of course, as I’ve blogged about previously, I don’t really try to separate my “life” into a “work-life” and “personal” life — but I find it interesting that so many of the new people that I’ve met in the past year are associated with computing to some extent or another.  (Of course living in New England with its high concentration of “techies” probably contributes greatly to my experience!)

At any rate, I found myself engaged in a couple of interesting conversations this weekend about working from home, the economy, job environment and IT careers in general.  Of particular interest in those conversations was the subject of “the home office” and “working from home”, and in particular the challenges that are presented with the “home” environment.  Not all of us engaged in the conversation were currently working from home, but a number of us have had the experience and could easily relate to the “stories” and experiences of others.

One of the topics which constantly came up (with associated “stories” ) was the experiences of the “worker” with their “family” during “work” time.  The number one issue that came up was related to the need when “working”, to be left undisturbed, as if they had driven off to an office somewhere.  Of course, for this to truly work for all of the relationships concerned, telecommuting from home cannot be a 24/7 operation.  Clear boundaries have to be set.

However, this is more easily said than done it seems.  Many of the participants in the conversation were feeling especially insecure about their current employment status — and the general consensus is that with such insecurity in the background, there is a tendency to try to work 24/7.  This does not work!  It was suggested by one participant that he thought perhaps that was what the company hoped for when they allowed him to telecommute!

Having employees who work from home certainly can save a company money.  The full-time telecommuter doesn’t require office space, the part-time telecommuter can often share office space — less office space required, less expense.  If on top of that savings the employer then gets greater productivity from the employee - it’s a win!

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.