Software Quality

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.

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 »

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!

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.

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!

Software Application Planning For Success

I often find myself wondering why I look at many of the newsletters and press writings that I do.  I was reminded again yesterday that the reason I do so is that I look for those jewels of information that apply not only to a large project or operation, but are as applicable to the small businesses that I work with as they are for large operations.  I am signed up for many weekly newsletters, and I go many weeks sometimes before finding one of those ”jewels” that I’m looking for.  I found such a jewel in a recent newsletter from Jennette Mullaney of SearchSoftwareQuality.com.

In her newsletter she makes reference to an article by Capers Jones Entitled “Software Tracking: The Last Defense Against Failure”.  This article is a must read in my estimation, at least for anyone involved in application software development.  Capers article concentrates “…on four worst practices or the factors that most often lead to failure and litigation…” — I believe these are applicable to all but the very shortest term software development projects, and even then there is some applicability.

Her article also makes reference to a couple of other articles which have recently appeared which deal with control of a software project.  Kevlin Henney in his article “Using iterations to help balance priority and risk” sums up software application this way “…Software development is a multivariable challenge. Estimates are estimates, not predictions, and there are many surprises…” — Thank you Kevlin for that wisdom!  I couldn’t agree more.

In ”Developing use cases that support business goals” Rob Apmann recommends “…to initially focus on the specific areas of value you want the system to provide…” — This is also a highly recommended read regardless of the size software development project you work with.

Trustworthy Computing

Since reading the white paper entitled “Trustworthy Computing” on the Microsoft link provided by reader Willie Robinson I have been thinking about the concept of “Trustworthy Computing” ever since, almost to the point of distraction — so I figured it was time to blog about it!

I first noted when reading that Microsoft paper that it was dated in the year 2002.  This prompted me to try a Google search on “trustworthy computing”, and I discovered a recent article posted on campustechnology.com entitled “Trustworthy Computing: Examining Trust“.  I found this article particularly interesting because very early on a reference was made to the fact that there is still a long way to go.

I have found myself wondering since reading the Microsoft White paper, just how possible is it to develop the same kind of confidence and trust in our computing environment that we have with our automobiles or telephone?  Computing, however, seems to be an area where there is an every day cat and mouse game being played between the good guys and the bad guys.  What happens when a good guy goes bad?  That has happened!

It seems to me that until the larger issues of global cooperation and trust are resolved, we will not see global trustworthy computing.  On the very first page of Microsoft’s “trustworthy computing” white paper, they state “…  Because computers have to some extent already lost people’s trust…”.  My experience would be that this is a gross understatement.  Significant data breaches have shaken the security foundation to its core, and significantly eroded trust that has been built up in recent years.

If this topic interests you, take a look at this most recent article that I’ve referenced above.  It also is a great read.