I'm listening now to a collection of short stories by Southern writers now which are mostly very good. The particular story that I'm listening to now is unusual for the collection in that it seems to be science fiction or fantasy. A man drives across the country in a U-Haul truck to meet his wife in an unnamed west-coast city, to which she has driven on ahead. The man, who is not wealthy, has made a deal with a mysterious "Mr. Griffen" to pick up a series of packages along the way and deliver them to him in the west-coast city when he arrives. In return for collecting and delivering the packages, the man will receive a large sum of money.
And the packages are in strange places--submerged and tied to a buoy floating in a lake, taped inside a dumpster, on top of a rest-top shelter, and must be collected at specific times. The narrator, afraid to be late, drives on without sleeping then finally crashes into a ditch. He walks the rest of the way. Is he alive? Is he dead? Is he dreaming? The story ends without a resolution, or perhaps it has one and I missed it. The name of the story is "Tired Heart" and the author is South Carolina's own Keith Lee Morris.
Yesterday while I was waiting for the chinese food that I had ordered I happened to pick up a paperweight that someone had left on the countertop. It was a clear cube of lucite with colored bars embedded within the plastic, forming a 3-D chart. Etched on the four sides of the cube were numbers in different scales. The top was clear. On the bottom was the logo of some pharmaceutical company. What a neat way to look at a 3D chart, in your hand where you can tilt it to different angles, peer in at the bars.
I like to develop software from scratch. I perceive a problem and the idea for a solution immediately begins to coalesce in my imagination. I think of the quidditch from the Harry Potter movies. A small, fast and hard to see idea flitting and darting while I try to trap it with visio diagrams and user interviews.
For example, a user came to me last week with a report. "Can you add a column for job order to this report," he asked. I looked at the report, which was dense with data already, and had a sense that this was not the first time the user had asked for this particular report to be enhanced with the adding of a column; my feeling was that he, a battle-hardened cost accountant, was using the report as a catch-all for materials-related problems.
"Why do you want the column?", I asked him. He looked surprised and annoyed, perhaps thinking that I was challenging him, doubting his need to modify the report. Seeing this, I continued: "What problem are you trying to solve? What issue prompted the need to modify the report?"
He described a scenario where variances of a particular sort arose. To identify and resolve the variances required that he and another accountant laboriously pour through screen after screen in our ERP system, comparing numbers shown there with those printed on another report. Having the numbers on this report would not eliminate the pouring, just the screens...
I could feel the spark: We could, I thought, with a query or at most a mildly complex stored procedure specifically identify the jobs where the variances existed so that the accountant no longer have to search line by line through 100 page reports for the culprit jobs. Moreover, we could make this a scheduled job with the report emailed on a nightly basis, so the accountant wouldn't even need to spot the variances--the system would automatically alert him when they were found. I was excited.
The necessary database query was already starting to come together in my head. Where do I find this kind of data, I was asking myself as I mentally reviewed the various ingredients that I would need.
Then my manager walked in. Quickly sizing up the situation, he asked the accountant what he needed. "Oh," he told us. "There's already an ERP report that does that. Come, let me show you," he told the accountant and led him away, out of the IT area and back to accounting.
Later, I told him about my idea for automatically identifying the variances and alerting the accountant of them. "It will save tons of time," I promised confidently, sure that there would be no rebuttal to that promise of increased productivity.
"But we would have to maintain it," my manager replied. "Let's pick our battles."
And, as Shakespeare might have phrased it, "therein lies the rub."
The initial idea, be it ever so good, is but a small part of the effort required to create a viable software solution to a problem. Even the effort required to implement that idea pales before the immense weight of a lifetime of maintenance.
See, what happens is that quick little solutions calcify over time. The original author, with his intimate understanding of the application's architecture moves on, and someone with a less intimate understanding is forced to make necessary changes; perhaps support for some new feature, or the changing of a business rule or even to update the application to be compatible with a new release of some new system on which it is dependent. The clarity of the initial architectural vision is muddied, the quality of the software degrades and it becomes more susceptible to defects.
So my IT manager looked this problem and saw that, sure enough, a simple application could quickly be developed that would elegantly address the cost accountant's issue. However, he realized, that simple application would almost immediately become part of the fabric of the company; would need to be maintained and modified as operating systems and database servers changed, would need to be enhanced to support the next version of the ERP system and the version after that, would need documentation and training so that future help desk personnel could support future cost accountants and would know where to go when the cost accountant didn't receive his email and submitted a help desk request.
And the packages are in strange places--submerged and tied to a buoy floating in a lake, taped inside a dumpster, on top of a rest-top shelter, and must be collected at specific times. The narrator, afraid to be late, drives on without sleeping then finally crashes into a ditch. He walks the rest of the way. Is he alive? Is he dead? Is he dreaming? The story ends without a resolution, or perhaps it has one and I missed it. The name of the story is "Tired Heart" and the author is South Carolina's own Keith Lee Morris.
Yesterday while I was waiting for the chinese food that I had ordered I happened to pick up a paperweight that someone had left on the countertop. It was a clear cube of lucite with colored bars embedded within the plastic, forming a 3-D chart. Etched on the four sides of the cube were numbers in different scales. The top was clear. On the bottom was the logo of some pharmaceutical company. What a neat way to look at a 3D chart, in your hand where you can tilt it to different angles, peer in at the bars.
I like to develop software from scratch. I perceive a problem and the idea for a solution immediately begins to coalesce in my imagination. I think of the quidditch from the Harry Potter movies. A small, fast and hard to see idea flitting and darting while I try to trap it with visio diagrams and user interviews.
For example, a user came to me last week with a report. "Can you add a column for job order to this report," he asked. I looked at the report, which was dense with data already, and had a sense that this was not the first time the user had asked for this particular report to be enhanced with the adding of a column; my feeling was that he, a battle-hardened cost accountant, was using the report as a catch-all for materials-related problems.
"Why do you want the column?", I asked him. He looked surprised and annoyed, perhaps thinking that I was challenging him, doubting his need to modify the report. Seeing this, I continued: "What problem are you trying to solve? What issue prompted the need to modify the report?"
He described a scenario where variances of a particular sort arose. To identify and resolve the variances required that he and another accountant laboriously pour through screen after screen in our ERP system, comparing numbers shown there with those printed on another report. Having the numbers on this report would not eliminate the pouring, just the screens...
I could feel the spark: We could, I thought, with a query or at most a mildly complex stored procedure specifically identify the jobs where the variances existed so that the accountant no longer have to search line by line through 100 page reports for the culprit jobs. Moreover, we could make this a scheduled job with the report emailed on a nightly basis, so the accountant wouldn't even need to spot the variances--the system would automatically alert him when they were found. I was excited.
The necessary database query was already starting to come together in my head. Where do I find this kind of data, I was asking myself as I mentally reviewed the various ingredients that I would need.
Then my manager walked in. Quickly sizing up the situation, he asked the accountant what he needed. "Oh," he told us. "There's already an ERP report that does that. Come, let me show you," he told the accountant and led him away, out of the IT area and back to accounting.
Later, I told him about my idea for automatically identifying the variances and alerting the accountant of them. "It will save tons of time," I promised confidently, sure that there would be no rebuttal to that promise of increased productivity.
"But we would have to maintain it," my manager replied. "Let's pick our battles."
And, as Shakespeare might have phrased it, "therein lies the rub."
The initial idea, be it ever so good, is but a small part of the effort required to create a viable software solution to a problem. Even the effort required to implement that idea pales before the immense weight of a lifetime of maintenance.
See, what happens is that quick little solutions calcify over time. The original author, with his intimate understanding of the application's architecture moves on, and someone with a less intimate understanding is forced to make necessary changes; perhaps support for some new feature, or the changing of a business rule or even to update the application to be compatible with a new release of some new system on which it is dependent. The clarity of the initial architectural vision is muddied, the quality of the software degrades and it becomes more susceptible to defects.
So my IT manager looked this problem and saw that, sure enough, a simple application could quickly be developed that would elegantly address the cost accountant's issue. However, he realized, that simple application would almost immediately become part of the fabric of the company; would need to be maintained and modified as operating systems and database servers changed, would need to be enhanced to support the next version of the ERP system and the version after that, would need documentation and training so that future help desk personnel could support future cost accountants and would know where to go when the cost accountant didn't receive his email and submitted a help desk request.
0 Comments:
Post a Comment
<< Home