Whenever anyone goes into a new job, or undertakes a new task that has to be done repeatedly, such as, for instance, a new teacher who has to teach some low-level class every semester, or a programmer who has been assigned to churn out an entire pile of little programs, all of very similar type, (the similarity aspect is not really pivotal,) there is a tendency to make little adjustments to the task, to make it easier on the worker.
Often, junior employees get assigned the less interesting jobs, because (for obvious reasons) the other jobs have been long desired by more senior workers, and they jump on them the minute they become available. Initially, the new worker takes on his or her new task with some enthusiasm, but fairly soon the tedium of it sets in, and presently all s/he wants to do is to get the job off his/her desk, get the item off the agenda, get the idiot kids out of his/her classroom. S/he'll never see them again, and good riddance!
But life is unfair, and one fine day, the employee gets to work on a new task, where the old work, shoddily done, suddenly reappears. "Who taught you guys Trigonometry?" You did, teacher. Or "Who wrote this crappy piece of code?", or Who passed this zoning ordinance? Or Who set this fracture? You never expected that shaving that little bit out of the unpleasant task long ago would affect your future performance.
It's not just that shoddy work is, well, shoddy, which is obvious. But rather that a new employee does not realize that shoddy work is not only bad in principle, but that it is a liability for him or her in an immediate way. A new teacher might fall back on tweaking the details of a course to make things easier for herself. But the consequences of the tinkering affect those who inherit the same students in future courses, that is, downstream.
The same principle holds, even if the tinkering is a well-meant improvement. In actual fact, the phenomenon is part of a larger picture and a larger problem: How can one improve an entire multi-step process, without precipitating a domino-effect serial catastrophe?
Most people are not familiar with the idea of computer programming, except in the most general way, but, you know, it is such a useful concept that it should interest everybody. Just a few examples will get the idea across.
A central idea of a program is the sequence of steps. Not every segment of code proceeds sequentially (one step, followed by the next step); sometimes the sequence has to be changed in response to some situation that crops up, and a good program anticipates these, and has these responses built-in. But ultimately, sequential code is the backbone of programming. Here below is an image of a pseudocode program that does something symbolic, I believe. (Many programming languages have a somewhat common design, so that generic programs in a sort of fictitious language can represent a solution to a programming problem. This language is called pseudocode.)
A junior programmer might only need to dash off a short program, and never see it again. But depending on various circumstances, the program may need to be tweaked. In fact, most experienced programmers will tell you: tweaking is almost all there is. By this they mean that the vast majority of programs need to be adjusted, either to improve efficiency, or handle outmoded hardware being replaced with new hardware, or obscure faults in the code that were never revealed for years (or many days, anyway).
Imagine a programmer staring moodily at a long program, which has to be modified to do the same job in a slightly different way. As you can easily see, changing the last few steps of the program is much easier than changing the first few steps. The downstream steps can be more easily changed, and in fact the code can be trial-run.
[Note: we are not advocating just changing the last few steps only. If the changing is to be done a little at a time, changing the last few steps first, and then checking that the whole program works, makes sure that at least that last segment is fault-free, after which you can go on to look at the earlier steps, incrementally, working backwards to the beginning of the program, or block of code.]
Another analogy. Suppose a school or college has decided to do away with a certain course. Before the course is actually removed from the catalog, it is best to modify the most downstream courses to respond to the planned removal. If you start at the lowest-level courses that depend on the course that is planned to go away (the upstream courses), the downstream courses must respond not only to the course targeted for axing, but the other altered courses as well! Particularly, if the changes are to be made one course at a time, you have to start at the highest level course. In fact, the highest-level courses can be changed without any domino effect, as is obvious. (Changing the highest-level course, the last course in that stream that a student is likely to take, could certainly change the overall effectiveness of the curriculum, but it will probably not interfere with the preceding courses.)
Now for something slightly different. A decision can be made on either theoretical grounds, or based on experience. Experience, of course, is the greatest teacher. If you lie down on the railway tracks, just for fun, and get run over, you're obviously never going to do that again. But we can be taught to avoid risky behavior, and that is what we call education. Education gives us a tool chest of theoretical principles that obviates the need for experience. Unfortunately, when it comes to making changes, the experienced worker is in a better position to figure out in what sequence changes can be safely made, because the theoretical analysis of the situation can only work if every possible factor is taken into account, something that an inexperienced worker will find very, very difficult.
An area in which it is very difficult to see all the factors that impinge on a decision is, surprise: local government. In fact, any sort of government. Suppose it is desired to save money by reducing the services provided to abused women. (Presently, at least in Pennsylvania, many counties provide temporary housing for abused women and their infants, until arrangements can be made for them to find secure homes for themselves.) If the number of shelters are gradually reduced, abused women in the future will need to live in the abusive relationship for lack of a place to go to, and if the abuse escalates (as it often does), firstly, police officers will be called upon, to defend the victims; secondly, hospital emergency rooms will see an increase in the incidence of battered women needing treatment, thirdly, school truancy officers will need to investigate whether children are not attending school for truancy or for a parent unable to get them ready for school. So it is very possible that a change intended to save money, actually results in an overall increase in costs, possibly placing more of a burden on other departments somewhere else. (Some politicians are perfectly satisfied with this Moving Expenses To Other Departments game, but it is foolish and immature, and such politicians must be removed speedily.)
Those of us who have no occasion to be familiar with these matters have no inkling of how, for example, issuance of zoning variances could affect the noise level in a neighborhood (of course, the plutocrats who can afford homes far from the industrial zone do not care, and they expend great effort to ensure that they control the decisions of whose consequences they are immune), or how industrial effluent can hurt fishing streams, unless it is carefully treated, or how rural roads can be degraded by heavy trucks going to and from the industry. The big picture is important. But some big pictures are really too big, because the smaller pictures are more complicated, but the big-picture dreamers are very intolerant of complexity. Some of the "small stuff" does need to be sweated.
Lots of things to think about.
Arch
No comments:
Post a Comment