Balmori Software Inc.

Share on

Photo: A.C.A.C. Reyes

    

Once in a while an application user will approach the application developer (the programmer) and ask for a "slight change" in the application. Let's face it: right off the bat, those are already fighting words.

If you've lived this experience, you already know it can be stressful and frustrating for both. The frustration comes from differences in perceptions and assumptions. The customer sees his request as "such a small, simple thing." The programmer looks at the request and says, "Sorry, simple it's not." So right there the two parties are already seeing things differently. And so the seed of potential misunderstanding is sown.

Here's a simple framework that will help both parties see each other's imperatives with more mutual understanding.

DATA ALREADY CAPTURED? This "slight change" being requested... does it make use of existing data that the program already captures? If so, then effecting the modification is relatively easy. Relatively. The requested slight change may call for reorganizing a report format or a writing a small change into the algorithms.

Mind you, the work involved can still be substantial, but less so than the other possibility described below.

DATA YET TO BE CAPTURED? Does the "slight change" require the capture of new data that the software is not currently collecting? Ah, then, you can no longer call the changes "slight." If this is the case, then, a programmer will have to do some pretty serious hard-coding in at least the following areas:

Photo: A.C.A.C. Reyes    

First, the programmer will have to amend the user interface to capture the new type(s) of data.

Second, the programmer will need to revise the validations operating on data inputs. (Validations are mostly invisible to users, but are crucial to data integrity. They include filtering rules that nip absurd inputs in the bud. For example, mis-characterizing a male as being in the third trimester of pregnancy. Or allowing a below-60-year-old to avail of the senior citizen discount.)

Building validations into the software accounts for a lot of programming that laymen don't know about and don't worry about. And that's why laymen tend to think that their requested change is so simple when it's not so simple at all.

Third, the programmer will need to overhaul the software's underlying algorithms so that they in fact assimilate and process the new data being captured. Because the world is complex, phenomena interrelate and interact in exquisite and infuriating ways.

This is no less true in the world of business, where the vagaries of competition, laws, government regulation, marketing, taxation, and what have you, all conspire to make behaviors - and therefore algorithms - complex. Therefore, expecting a piece of software to digest the newly captured data will usually require, not just adding new algorithms to the software, but also adjusting many of its existing algorithms as well.

Fourth, the programmer will have to create a data conversion utility. You need that to make the old data compatible with the new data structures. Because of course you don't want to reinput four years worth of old data everytime you enhance a piece of software.

Obviously, you can expect the latter type of software modification to cost more, to be much more difficult to set specs for, and to take quite a bit longer. rsr

<<< Back to top >>>