Posted by: SJC
Agile, Business process automation, Database application, Database reporting, Software application development, Software Quality
Contrary to what my blog may be showing, I have not been on vacation this past week, nor have I been sick, nor have I been tending to many matters other than the current projects I have on my plate. I could certainly use a vacation after this week!
It’s said that timing is everything. Well it would seem that my timing is off because I currently have two clients in the throws of new software implementations, and neither one has been without challenges. For one thing, the challenges at each have been as different as their respective organizations.
The main ingredient and common thread among these two implementations has been more along the line of user challenges than the technical issues of the software design or network implementation. You know how users are – don’t you?
Users — they want what they want — and as a developer I want to give it to them. However, as a developer I certainly am not without my limits. I still have not figured out how to clone myself so that I can be in multiple places at the same time! I also have not yet figured out how (at least in most instances) to give multiple users “their” way – I am still limited to creating software that somehow strikes a balance among the needs and desires of all users … and I have a standard which requires that I do whatever I can to program an application which helps to maintain data integrity. Functionality such as lookup lists help to minimize data input (…and therefore fat fingered entries), and help to maintain a consistency to data entered – even on fields where any value can be entered. Adding such functionality in an application takes effort – as does the “guessing” of what a user “might” do before they do it. These are challenges – and they probably aren’t in any specification for the application.
Then of course there are the ever present “resistences” to changing what has been. In one of these implementations there are users who can find excuse after excuse for not using the “new” application. (…the old is a single user dos app…the new a multi-user Windows app that “everyone” can use and read — possibly a threat here?) . The dos app is always recording history — probably at least 30 days after the fact — which is the reason for the “new” app which of course will be “real” time and always current! What a concept!
Now, one might ask, “Why are you as a developer involved in this?” — good question! I personally have never been one to be narrowly focused — I program, but I do not consider myself a “programmer”. Being back in the independent application programmer business from my IT department management function hasn’t changed my point of view. My goal is to rapidly deliver technology solutions that improve business processes and user effectiveness — and that means more often then not, I am involved in much more than the nitty gritty of program development. I like it that way – I always have, and perhaps it just might be because of the challenge that it is.
My other implementation “user” issue is more easily worked with. As I got deeper into the requirements which had been spelled out for me (pretty clearly I thought at first), I discovered that there was some requested information which just didn’t make sense to me. I had failed to establish what this user was “really” trying to accomplish with a given report. I had not had direct communication with this user, (…breaking some of the Agile rules here), but was able to eventually establish the “real” requirement for the user.
The other part of the previous implementation had actually fallen into the “technical” realm — and once resolved will serve me well into my future. I love it when a plan comes together!