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!
I have written quite often over the past year about user interface issues. One of my blog posts worked with the question of whether the interface should be busy or sparse. I also provided a link to a fellow developer white paper which dealt with some simple ideas regarding layout of fields on an entry screen. The user interface has always been something of interest to me, since the users I deal with are looking for simplicity — yet simplicity with powerful functionality.
As a result of reading a post in one of the newsgroups which I follow regularly, I discovered of all things a new (to me) acronym — UX. Now my definition for UX up until today had been UNIX, but now I find it is being used for user experience. (…proof once again that you learn something every day — IF you “show up”). The post which I read had a link to a detailed article named “Label Placement in Forms” –and this article in turn introduced me to a new website www.UXmatters.com. Readers of this blog may find the article, and the website of interest.
Anyway, no matter what you call it, design of an application interface is critical. Not only must an application be fully functional for the task to be performed, but it is important that it be visually functional as well.
I know various developers who from time to time can very quickly get on a soapbox regarding interface design preferences. In my explorations today I found an interesting blog regarding user experiences — “The user experience soapbox“. Enjoy!
Don’t you hate it when an update fails? I had the experience just yesterday while doing an update on my Microsoft Vista laptop. The updates appeared to be going correctly, but at the very end I found myself in an endless loop situation. The situation was not pretty and upon further investigation in the web a Google search pointed me in the direction of a workaround. I wasn’t sure that was the right direction, but this was not something that was unique to myself. The work-around worked!
I was fortunate. I only lost about an hour in my struggle to find the answer to take corrective action. However, others were not so lucky, many losing countless hours before recovering — or not — their system. My investigation to this point indicates that while this has happened on an occasional basis for some, Microsoft has been apparently quiet regarding this problem. This was an update that I expected to work absolutely perfectly since a fellow developer friend of mine said he never liked Vista until he had installed service pack one.
It seems that on August 12 of this year VMare issued an update which caused issues regarding the licensing. The problem prompted an open letter to VMware customers from VMware’s president (…see letter). This appears to be a fine example of software quality assurance going wrong — just how this embarrassing situation occurred is certainly under investigation by VMware.
As I see it, these two examples of updates that failed are very different. In the case of the VMware issue a fix was readily found, as the issue was the result of a programming error. A quick fix of the error and the problem was resolved.
As for the Microsoft issue. I see the problem as somewhat different in that while the problem has occurred for some, there are many for whom it has not occurred. This represents a much more difficult issue to resolve. As a result of the very nature of personal PCs, testing for this error becomes much more of an issue. I can almost forgive Microsoft for not having a solution to it.
Yes, I’ve had perhaps more than my share of failed updates. I find that I am much more upset with programming or testing errors than with errors which occur as the result of network or hardware issues which I cannot duplicate. Regardless of the cause, there is no such thing as a good failed update.
Social networking in business has been receiving quite a bit of press lately with many differing views on just what should or should not be allowed, or how to use various social networking tools now available. I ran into an interesting read in an article “Social networking in business: Avoid the ‘Kumbaya Zone‘. Now, the ‘Kumbaya Zone’ is a new term for me, and the article refers to it as “…the place where social media is ultimately a time-waster and has little business value”.
Now I don’t want to get into any do’s or don’ts about social media – nor do I think that it would be wise for me to do so — but what I do want to address is that perhaps many of us have seen applications which appear to become time-wasters with little business value, I certainly have. They may be the “old” application never replaced, or they may be an application for which users have developed so many work-arounds to have it fit that there is much time wasted. Either way, the application has little business value.
The referenced article ends with the statement “Get comfortable taking that first step, and see what works along the way. That is way different from the software model we’re used to.” Now, I certainly agree with the first sentence concept of getting comfortable and seeing what works – and while the article specifically is talking about social media, I would posit that this is an approach worth considering for any new application. As for being a different software model than we’re used to, I must say that working with my customers we’ve been able to create an environment where we do to a large degree follow the concept – it doesn’t have to be “…way different…” than we’re used to.
Early this month when I first read about Google’s release of it’s “Chrome” browser my first thought was “Why do we need another browser?”. I then pictured the Google page I now use as the home page on all of my systems, www.google.com. It meets my standard for a “clean and simple” interface. This in turn led me to investigating “Chrome” to find the answer. I was pleasantly surprised I must admit.
Google also has posted an interesting comic book type presentation about its development which I found very interesting (…although a bit long and eventually too detailed for my interest). This comic can be found here.
I was pleasantly surprised that once I installed the browser I was able to do a high percentage of the work I do from within a browser – all this from an initial public release of a new product — quite impressive I must say!
Perhaps its age, perhaps its my “artistic” flair, perhaps its that I do not like clutter either on my schedule, my computer desktop or my surroundings. I must say I like what I’ve seen in Google Chrome – hopefully they will keep to their simplistic design as the product matures.
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
It was September 18th a year ago that I made my first post in this blog. At the time, I really didn’t know much about blogging, only vaguely knew that when one had a blog to voice their thoughts on a topic, that they would almost inevitably find someone who shared their thoughts – someone who could relate to their experiences – and perhaps even their “views”. This seemed to have some strange appeal to me so I created this blog, choosing the title “Custom Application Development: Buy, Build or Ignore?” because at the time I was deeply rooted with clients actively making such decisions – and I figured that I could draw on that experience to provide material.
Once I got started with the blog I realized that it would be somewhat of a challenge for me to write posts which I thought would be interesting to many, and at the same time provide as a minimum an enjoyable read, and perhaps something to stimulate ones mind on the topic I chose to write on. With each post that I’ve written I’ve learned something more about things that are important to me. I hope that along the way perhaps I’ve touched upon a topic that you also consider important or interesting.
There hasn’t been much activity on this blog in the last few weeks as the result of injury to a family member for whom I’ve had to take on primary care for — an intense and exhausting addition to trying to service my customers in the manner that I’ve trained them to expect. (…and that I expect to provide them!) .
Fortunately as the healing has progressed and I have become more efficient at providing the needed care I once again see my way clear to spending the time I’d like to with this blog. I am looking forward to writing regularly again, and hopefully you’ll be reading. It’s certainly been a pleasure for me.
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”.
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.
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.