April, 2008

Desktop Software Revolution in the Making?

The hype around the use (…or rather non-use) of Vista continues to be in full swing as we close out April 2008, a mere 2 months before the “official” Microsoft mandated end date for availability of Windows XP on new computers.  Computerworld published an article on the web today “Vista ‘inevitable’ for enterprises, says Forrester analyst“.  The article has prompted numerous comments from a mixed variety of interested parties, with an equally mixed bag of thoughts and predjudices. 

I’m not really sure why there seems to be so much “fuss” around the article in question, or the Forrester analysts comments more precisely.  Personally, I took the view that Vista was inevitable for me soon after it was released.  As an independent software developer I have neither the desire nor the clout to demand how my clients run their business or their investments on hardware and infrastructure.  My job becomes providing them with what they need and desire to effectively run their business applications using the tools they choose - I just knew Vista would be a part of that.

Please do not misunderstand — I’m not necessarily an early adopter of new OS’s or technology for that matter.  In my opinion, Vista offers little for the average business user.  Looking at the fancy ribbon bars etc. that are part of MS Office 2008 I find pretty, but just too much.  They are pleasing on the eyes, but add little other than clutter and confusion for the casual user.  Vista vs XP is a similar story at the functionality level.

It seems to me that IF there is ever going to be  significant exodus from Microsoft Windows desktops it will be NOW!  I believe that Microsoft has never been so vulnerable — but I also see no real alternatives on the horizon other than perhaps Linux, which by its very nature as open source is vulnerable.  If so many don’t like Vista — it could be a long wait for the next Microsoft product.  What’s the alternative?  Does somebody know of the next disruptive OS that’s just waiting for the day to jump out and tell the world “I’m Here!” and have the world IT organizations gobble it up? 

Thoughts on the Career Software Developer

I just finished reading an excellent post by fellow TechTarget blogger Ron Richard entitled “The career, software developer (your comments appreciated)”.  His post is one which can’t help but spur its readers thoughts both into their past and their future, at least for me it certainly did.  The post ends by asking 20 questions — each of which is very capable of spurring significant discussion.

I immediately found myself wanting to respond with an answer to his question number 19.  His question?  “Will peer programming in the future involve a human and robot?”  Perhaps I’m somewhat old-fashioned, (my grandchildren have pointed that out to me in the past), but I just can’t get a picture in my mind of the software developer robot.  Perhaps it would be an interesting artistic effort to create one!  But that aside, I find myself questioning the use of the word “peer” in relation to a robot and a human being.  I just can’t envision that!

Our software development tools are getting smarter, they do think ahead for us in some instances as they fill-in the command it thinks we are going to use.  I cannot conceive of the robot developer understanding anything but the most detailed of application requirements.  The “artistry” of software development — particularly application software development — belongs to the human being.  I certainly CAN conceive of the human “guiding” the robot wizard as it creates the application”code” (…probably not understandable by the human at that point…) which runs the logic and UI.  Actually as I think about it, I could use some of that robot influence today!

Robotic software development I believe, and I hope is a long way off in the future.  By that point in time, I won’t be trying to earn my living as a software developer, and I can read all about it in the tech journals and be amazed.  Until then I can keep coding and dream on!

Custom Application Development and Creativity

Writing this blog is a creative endeavor on my part — in the past I’ve tried to avoid any extensive amounts of writing yet I felt pulled toward doing it, and I have enjoyed doing it over the last few months.  In a like manner I truly enjoy doing the application development work that I do, which like my blog writing, often times takes on a creative component.

In fact, I’ve found both the application development that I do AND the blog writing I do to often run along parallel paths - especially regarding creativity.  There have been times when I’ve sat down in front of the computer at my blog and just been mentally and creatively as blank as the form on my screen which is just sitting there patiently waiting for my thoughts.  It seems at those times that I have nothing to say - and with nothing to say even my continually improving voice recognition software can’t help me write.

There are also times that I find myself in front of my editor or other software design tool with seemingly nothing to say — there just seems to be a “block” in place that doesn’t want to let go.  Fortunately for me if I am blocked with my writing, I’m NOT blocked with my development.  I’ve had discussions with other developers who also find themselves at times with a block that doesn’t want to budge.

How does one get past the block?  I suggest moving on to something else.  Often I have used the times I’ve been blocked to catch up on that article I ripped out of the tech magazine a few months back — the one I wanted to read but didn’t have the time to dig into.  Physical movement helps too — a trip to the water cooler perhaps, a conversation with a co-worker.  It never ceases to amaze me how well even a short change of focus works to help get the creative juices flowing again.

Try it, you’ll like it!

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.

Thoughts on the Elusive “Bug”

My last post was certainly created in the heat of the moment, and displayed I’m sure a significant amount of the angst that I was feeling at the time.  The issue that I was having has now been resolved, but it really serves as an excellent example of some of the pitfalls that can occur when developing an application.  Let me explain.

I failed to follow one of the cardinal rules of development — that of changing too much at one time.  As I understand it the procedure that I usually follow could be classified as “unit testing”.  I was suckered in by the fact that the program was a very “simple” one.  Because it was so simple, I didn’t take the time to make a change and then test for that change.  As it turns out, that was a big mistake.

I also made the mistake — because I was feeling time constraints — of not taking the time to follow my usual step-by-step procedures.  Not only was I not checking incremental changes, but I was also dealing with a situation where I was integrating third-party software into my program.  What I had not realized was that by using some old code I was in fact negating some of the functionality I was expecting.  Since this was the first time I had newly integrated this Active-X component using the latest version of my development tool — Visual Dataflex (VDF) — I was caught off guard.

Moral of the story?  Make changes in increments, test frequently, and be patient.

In Search of the Elusive Program “Bug”

It happens sometimes, that elusive “bug” that just drives you crazy as a programmer.  I know I’m not the only one that this has happened to, as there are many other developers with whom I’ve spoken that relate similar stories to mine — that of spending hours looking for the solution to a problem that you know just shouldn’t exist.  As for me, I’d just as soon forget about today’s episode.  It was not a pretty sight!  Heck, it still isn’t pretty!

The fact of the matter is, the problem that has been “bugging” me all day has still not been exterminated.  And in spite of my best efforts to analyze, use every tool available to me in my efforts to find the problem, and even after reading the manual, the problem remains.  I hate it when that happens!

It all seems like it should be so simple, yet something has changed that I have not been able to identify.  As a result, the program is still not working, nor at this point is my brain working.  It’s really time to stop thinking about the problem — but it seems I just can’t get it out of my mind.  So, since I have this blog available to me I thought I would share a bit about my problems today.  Hopefully others who read this will be able to relate.

This was one of those infamous projects which was supposed to be “quick”.  After all, what I was doing was updating a pretty straightforward “simple” application.  The problem with this update appears to be that I am actually working with two updated versions of software.  During earlier beta testing of the software, the updates worked flawlessly.  Now that I have the final release of the program, I can’t seem to get it working.

I have tried everything I know of to help me keep a clear mind while addressing the problem — I’ve walked away from it, and then come back.  I took a few short walks!  As simple as the program is, I even started from scratch — with the same result.  It was at that point when I decided perhaps the change in versions may be the root of the problem.  That’s tomorrow’s project.

May your programming day be void of these issues — and if you’re NOT a programmer — be thankful and think of those who create the applications you are using.  It might just be that a lot of sweat went into their creation.  Not a marathon for sure, but seems like it when dealing with the elusive “bug”.

Custom Application Programing - Either a Feast or Famine

Perhaps I should take 16 day vacations more often, as upon my settling in after my return I realized that I have a very full plate in front of me.  Throughout my years as an independent software developer, this is what I have found.  When a developer is dealing with custom applications, it seems there is either a feast or famine relative to the amount of work that’s available.  Perhaps as a parallel to the old expression “…absence makes the heart grow fonder…” in a like manner perhaps “… absence makes application users think of new things for their application to do…”

Actually I’d rather think that the feast or famine is just a normal flow.  I have seen this cycle over and over again.  I’ve had people ask me before, what do you do with your time when it’s slow?  My answer to them is generally that I spend the time learning what I’ll need for the next time I have a feast of work.  By the way, not only do I provide the previous answer, but that’s actually what I do!

As far as spending the quiet times studying or learning new things that I may use in the future, I have become a firm believer in doing this.  It seems to keep me from becoming stagnant and set in my ways.  Sometimes, the research and new things that I try truly do pay off in the future — but there are other times that I learned what I do not want to do in the future.  That lesson can be of immense value also.

During a feast of work, it just doesn’t make sense to be spending time trying to learn something new.  In the famine times, I find myself hungry to check out the latest development tools and look at ways to improve my skills so that I can become more efficient.  This has served me well through the years.

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!