Software application development

Coming Back to a Project

Regardless of the reason for a development project being delayed, coming back to a project which has been “on the back burner” for a while seems always to raise questions about the project.  For me the questions may start out with “Where was I on this before I had to leave it?”, to “Why on earth was I heading in THAT direction with this?” — or my favorite “What was I thinking!”   …usually an indication that I wasn’t thinking! ) .  Besides the “lost” time of re-aquainting oneself with the project, there have been many projects for which the longer they sat, the more I just wanted to start over again.

As an independent developer I’ve always had to be working with multiple projects at a time, and somewhere deep down in my being, I wished that I could just have one project to work - from start to finish!  The problem with that idea is that for one thing a custom application project never seems to end — mostly as the result of constant improvements being made to the application — or “tweaks” as one of my customers call them, so there is seemingly always something more to be done. 

However, coming back to a project can be challenging.  It can also be an indication to one as a developer of how much they’ve learned in the say, six months that a project sat without being worked on.  This is a good thing!  Whenever possible when I have identified that some previous work can be improved upon to simplify or somehow make the code more maintainable — if at all possible I make the change.

Another thing I have experienced after coming back to a stopped project is that very often I find that in the time lapse since last working on the project the needs of the user community for which the project is designed may have changed.  Certainly it is imperative that before going ahead with any stopped project there be clear communication with users or as a minimum the person ultimately responsible for the project from the business need standpoint.

Coming back to a project can be exciting — but it can also bring new requirements, expectations and challenges.

Software Application Speed and ADD Users

ADD — aka Attention Deficit Disorder — is, some say, an altogether too common ailment in today’s society, at least in the U.S. While I certainly don’t intend to debate that issue, a recent experience got me to thinking about how children with ADD do and will grow up to be computer application users. These thoughts in turn had me thinking once again about application interface design and user needs.

Much is written about interface design. For years we’ve worked hard to provide intuitive “user-friendly” interfaces for our applications. Much has been written about visual presentation, and many options for changes to the visual presentation such as “skinning” have been introduced.

Perhaps, however, the most important of all the considerations for an application should be the application response time. I’m not aware of any user who doesn’t get impatient with poor response - defined here as a response time meeting their personal expectation! As more and more users (ADD or otherwise) become frustrated with either speed issues OR for some, the cluttered screen, it seems imperative that we as developers be constantly on the alert for signs of this frustration brewing. My experience would indicate that most computer applications used in a business environment are not being used by “computer” users, but rather by users who understand the task or job they are required to do, and (in some case, regrettably) must use the “computer” to accomplish the task.

Application design is no trivial task!

User Experience, User Interface or Human Interface Design?

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!

New Applications - Taking the First Step

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.

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

Software Testing, Development and Music

I read with intense interest the “From the Editor” post entitled “Software testing lessons from music” on SearchSoftwareQuality.com this week.  The article caught my eye for its title uniqueness, but kept my attention as I read the theme of the Association for Software Testing’s annual conference - “Beyond the Boundaries: Interdisciplinary Approaches to Software Testing.”

Interdisciplinary approaches to software testing just seemd to be ”beyond the boundaries” for my brain to comprehend until reading the article.  A comment on the post was also particularly meaningful to me - stating a view that I have often been criticized for voicing myself.  “Testing, like designing and programming, is as much an art form as engineering.” The comment goes on to compare testers to choreographers and users to the dancers.  I personally love that concept!  It portrays a vision of software development which I have long had, and work daily to achieve - that is creating the perfect symphony that users can play beautifully.

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.

The Business Process — How Does It Get Complicated?

I wonder how many of the business processes which a company develops over time from its early days as a very small company to a larger organization become overly complex.  Of those processes, I also wonder just how many of them are the result of new demands on the process simply as the result of the growth of the company, and how many of them become “the way it’s done” out of habit or because of other requirements mandated by the business environment. 

I’ve worked mostly with smaller companies, often times businesses that have started off very small and grown to become multi-location operations.  As their growth has progressed the needs for tighter controls becomes increasingly apparent.  No longer can the business depend upon the memory of that one key individual who “knows everything” that’s going on — who knows the customers, knows the vendors, knows each employee.  As staff increases so does the “risk” associated with no longer having a close, trusted, personal relationship with employees, often co-founders of the company. 

Many of the applications with which I’ve worked were originally developed specifically to provide the growing organization a means to “get a handle on” information that many may need, but early on resided in the head of the “key” person.  The small company finds a way to get the job done - process is the least of concerns.  I believe that what happens often during the growth period is that as the need for defining the business process becomes clear, efforts to define the business process fail because there are “so many variables”.

Its at this point that I’ve found a company will generally make the buy or build decision for software.  Some will look at a vertical market package for their industry and decide that the “business process” required by the software is the way they should be running their business.  (Hey — it works for others - why re-invent the wheel?).  Others may find that they just can’t see themselves running their business “just like everybody else”, and they will choose to have a customized application.  Then there are those who choose that vertical market package, work hard to change their business processes to “fit” the software, and then find the “work-a-rounds”.

“Work-a-rounds” add a level of complexity to the business process that is generally not required.  If your business processes are too complicated - maybe its time to look at how much is a “work-a-round”, you may be surprised.

A Business Process NOT to be Duplicated

When an independent application software developer first meets with a prospective new client it becomes very much a meeting where each party is evaluating the other.  For the developer it becomes questions of “Is this an organization I can work with?  Can I provide what they are looking for?  Can they pay me?  Do I want to do the proposed work for this organization?”.  For the prospective client the questions become “Can I get what I want from this developer?  Is the talent there to provide the service?  Can I afford the service?  Can I work with this developer?  Do I want to work with this developer?”  All good questions - left generally unspoken.

In speaking with a fellow developer today I was reminded of this by a story he told of one such interview where he decided that he was NOT interested in doing work for the prospective organization — and the reason?  Basically it came down to the prospect being firmly entrenched in a business practice that was just plain poor.  The application in question was an inventory application - the problem to be solved was to have a system that kept inventory straight.  The “real” issue, quickly identified for the prospect was their practice of transferring inventory from store to store.  They used hand-written packing lists for the transfers.

There were 2 locations, each keeping their own separate inventory system.  Each properly received inventory, and inventory was in fact properly relieved by the sales function.  The system wasn’t used at all for the transfer of goods from one location to another — no surprise that inventory was off!  Since the system for each store was independent of the other, neither system “knew” of the movement of goods to the other location.  So, you had a system where goods were received properly, but not properly relieved at the location shipping the goods!

My developer friend thought it best to stay away from this potentially difficult situation, and suggested that the prospect find a developer who was willing to do the work as desired.  The moral of this story?  Not all business processes deserve to be duplicated.  In this case, the issue was not the computer application that was the problem, but rather how it was being used. 

The story also illustrates very well one of the situations that I always try to become aware of at a clients site when I’m there - “What are they doing manually that could easily be in an application?  Why isn’t it?”  The manual packing list is in my book a BIG red flag!  It signals stop, look, and be cautious. 

P.S.  My friend later found out that this company’s “new” inventory system didn’t work any better - at least until the business process was changed.