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.
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.
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.
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”.
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.
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.
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!
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.
I had a rare opportunity last evening to have a conversation with my brother-in-law and our conversation got me to thinking once again about the use of spreadsheets as databases. It seems that my brother-in-law is quite the guru at using the Excel spreadsheet. As our conversation progressed, I talked about a simple but powerful application that I had created for one of my customers. He questioned why I wouldn’t just go ahead and create the application using Excel. He said that he could do everything that my application did in an Excel spreadsheet, and I had to agree with him — to a point.
My first thought was that the application I was describing was designed from the very start to be a multiuser system. The application user community I created the system for would not be tolerant of opening up the spreadsheet only to find they couldn’t change it because it was locked by another user. I also made the point that users doing the data entry had a hard time handling columns and rows and where to put information into something such as a spreadsheet. Of course, he said that forms to allow easy data entry into a spreadsheet can be created, if one is knowledgeable enough about how to do it.
Bottom line, our conversation once again pointed to the value and requirement of truly establishing the functionality desired from an application, and with those requirements in mind establish what tool to use to create the application. There are so many variables to consider, not the least of which will include the prospective user group. He did agree with me that there had to be some knowledgeable person able to create a spreadsheet that would duplicate my application. My experience with the small companies I’ve worked with, is that there is no truly knowledgeable and experienced person on their staff to create the kinds of programs that a developer can create.
After my last post where I strongly conveyed my misgivings regarding on-line web apps I found myself looking at a few web apps to see if I were going to have to eat crow after my post. While crow is not on my immediate menu, I have found that by looking into some of the referenced services included in the article “Work Smarter” that I referenced in my previous post I have found a VERY interesting book — available in on-line pdf or paperback, or just for on-line viewing — “Getting Real“.
My title for this post indicates the general reception that I immediately gave this reading. It is at the same time an excellent writing and expression of what I believe software “should” be, and also a controversial, helpful, destructive, right-on — OR totally Un”Real” approach to software development! You decide!
Is this where application development is heading? Is 37signals.com ahead of their time? Do you agree with the concepts of this book? …partially agree? Or perhaps vehemently DIS-agree? Is “Getting Real” – “Real” — or Un”Real”? As for me, I haven’t decided as yet, but I did sign up for one of their services to “try” the idea. Time will tell I guess!
…and I must admit that I was impressed with the user interfaces that I saw