Custom software development

Thoughts on the Career Software Developer and IT

Ron Richards in his post “The career software developer…” alludes to the observation that “…it is not surprising to discover that there are more people scoping, managing, testing and supporting the work of software developers than there are software developers.”  I would have to say that I believe this is a sign of hope for software applications - or at least it could be, depending upon just how well those performing in these support roles can identify and communicate, or otherwise translate user and operational needs into the formats for the career programmer or software engineer to do their job most effectively.

I recall a situation a few years back where I was part of a group evaluating potential ERP systems designed for the particular vertical market of the business.  One of the biggest selling points of the vendor finally chosen was that their software didn’t originate from software development guru’s, but rather from the roots of key company players who were firmly entrenched in the vertical market for which the software was created, and through the years they had developed and enhanced their product to keep up with the needs of the market.  Sounds good, makes sense, but the reality was that much of their successive revisions and enhancements after their early years were more created to boost sales or meet changing technology requirements.  Hence their system rather than being updated with re-design was rather “patched” together as a patchwork quilt.

I don’t believe that the career IT professional needs to start out as a programmer of software developer.  What I DO believe VERY STRONGLY is that to be most effective the career IT professional MUST understand the business of their employer to a level I suspect very few do.  Perhaps I think as I do because my introduction to IT had its roots in software quality assurance, though it really was more like software evaluation.  The company developers hated to see me wander into their offices - they knew I probably had another “brainstorm” about a feature that should be added. 

I believe that the most valuable IT professionals are those with an understanding of the business, an ability to adapt, a keen eye for opportunity and a burning desire to make a difference to their organization.  These professionals are not necessarily the “guru’s”, and in all probability are not.  Of course, being a bit crazy also helps!

Are Users Really “Trainable”? Should they Need Training?

I have developed a reputation around the way I work with users that I am “training” and who display various levels of skill (or non-skill) with their computer system.  From executive levels to the warehouse user my reputation for telling a new user something like “…see - I told you you were ”trainable” has become noted.  Naturally this statement gets many different reactions, but it is always meant as a compliment to the trainees natural ability to use their computer as a tool for accomplishing their job which they “know” how to do. 

That said, in my opinion their “natural ability” to use the tool depends solely upon the application interface.  Should users need to be trained or should they just be able to use an application if they know how to do their job?  It is a lofty goal for sure to think that new users (who know the job they need to do) can instinctively sit down and be able to do their computer tasks without training — but one I believe in.

Now, let the record be set straight — while I may always strive for that in my program / interface design, I seldom achieve it.  But like users, I’m trainable — and that is where listening to and observing users comes in.  My users have very definitely trained me through the years to be more aware and observant of their needs. 

Probably the best example I could give regarding user interface would be the custom order entry system that I was building a number of years back.  I kept getting feedback from the primary users - the ones using it day after day - that it “just didn’t seem right to them”.  I heard their “complaints” initially as that it just wasn’t the way they used to do it.  However, after this went on for a few weeks I volunteered to fill-in for one of the users and do the job for a few hours myself, using my program.  WOW - did I learn a lot!

I learned that my idea of efficient and what they really needed were two different things - and the program was updated within the next few days, and that truly is the way I think it should be.  Yes, users ARE trainable — but I really don’t think any application user interface  should be so complicated that it requires the significant training often associated with implementing something like an ERP system.  Train for the job, the tool use should be instinctive.

Technology Sales Styles

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 »

Defining “Just Enough” Application Requirements

A little over a week ago an excellent tip was published regarding software requirements - “Approaches to defining requirements within Agile teams“.  While this tip directs itself to the needs of an Agile team, it serves as an excellent read for the software developer who is dealing with custom applications, and I believe applies as much to the custom development arena as Agile. Continued »

Desktops - User Interface - Simplicity of Design

I just saw a recent post that I just can’t let pass by - “Overheard: Hardy Heron flunks the girlfriend test“.  The cute title of course caught my eye right away — my love of the Heron and spotting the cute little graphic in the post also caught my attention — but then to read the post and realize that it related to my recent post about Microsoft being vulnerable on the desktop with its poorly received Vista was just too much to handle.  Continued »

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”.