I just spent some time writing an entry about the local village festivals, and how they are marred by parking and traffic problems and trash nonlocal sidewalk vendors, and how it would be so simple to make them much better. Then I realized I wasn't really writing about the festivals, but about my frustration at seeing things that could be better, but being unable to do anything about it. There's a lot more traffic and a lot more people than even 10 years ago, when I first moved here, but the format hasn't changed at all. The same people run these things every year, and they've done it the same way every year, and if you dare to suggest any change they get all pissed off. The reaction to any criticism is "Look, I volunteered for this, and I'm doing the best I can, and if you don't like it, YOU do it! (slamming the folder on the table.)" I'm not paranoid. That's from the newspaper. Sigh.
The Hardscrabble Day festival was 9/11. I wonder if there was anyone on the committee who wondered if maybe another date might be better, and what the reaction to that suggestion was.
So anyway, I deleted that whole entry, and now I'm writing about what my REAL frustration is.
Part of my frustration stems from some conversations I had recently. I was frustrated by some things happening (or more accurately NOT happening) in the local Mensa chapter, and brought them to the attention of one of the officers. (One of my concerns was that the activities calendar on the official website hadn't been updated in two months. I discovered it when my copy of the newsletter was late again, and I went to the website to find out what was on the schedule.) His response was "the same thing we tell people at work", that if I wasn't willing to step forward and do it myself, I shouldn't complain that it's not getting done. Huh? I do not think that was an appropriate response.
He works for the "large computer manufacturer" I used to work for. That response was typical of lower level managers in that company. You were not allowed to point out problems unless you also provided a solution. If you don't have a solution, shut up. We don't want to hear it, no matter how serious the problem. People who warned of dangers without a solution in hand were accused of "Eeek-a-mouse". You didn't want to be branded an eeek-a-mouse.
One of my friends used to be my umpteenth-level manager in said company (before we knew each other personally). She "owned" our product, one of the big-iron software systems, and is now retired. I mentioned to her the response I had got from the Mensa officer, and that it was so typical of the reaction you got in the Company. She asked for examples, and I gave her several.
The most frustrating for me was the time we were working on three releases all at once. Usually, we worked on one release. We'd use the prior release of the system as a base, and add "line items" (new functions) to that base. Line items were tested individually as they were developed successively, and when they passed all their functional tests, they were not specifically tested again until eventually, toward the end of the schedule, all the line items were retested together on the completed integrated system. Sometimes during the integration test, the new line items interfered with each other, and tests that had worked fine against the earlier individual line items choked when run again with later-developed items added in. Example - a later line item changed a control block (think "specific location in storage") which an earlier line item used. Conflict. Thud.
For some reason I forget (probably having to do with hardware availability dates) we found ourselves with three separate releases all in development and test at the same time (well, in rapid succession). We'd never done that before.
To explain what was happening, let's call the base (old) version "O", and each of the new releases "1", "2", and "3". All the releases in development were being built on a Release O base. Let's say there were 10 new line items in each release. As each line item completed its individual functional testing successfully, it would be "promoted" to the next release base(s). Remember that additional line items were being simultaneously developed on all three releases. So when line items A, B, and C from Rel 1 finish testing, they would be "slipped in under" items M and N on Rel 2, which themselves have already completed functional test, and Rel 1 items A, B, and C and Rel 2 items M and N would be slipped in under Rel 3 item X, which has also completed functional test. And so on, as items are developed and tested. Sort of like shuffling one deck of cards into another deck. Note that item A has never been tested with B installed, let alone with M, N, or X. But (bell goes off in head) line item X has never been functionally tested with A, B, M, or N installed. Only the last item to complete functional testing on any one release has been tested with all the previous line items installed.
Now, I'll bet anyone reading this can tell me already what the problem is. You may have had a growing sense of horror reading it. If you still don't know, go back up to the paragraph that begins "The most frustrating..." and reread from "Sometimes during the integration test...". Now think about the integration test for Rel 3.
Normally, all the line items in a release are functionally tested on a solid base. Rel 2 and 3 line items were functionally tested on a fluid base! Worse, there was no procedure in place to ensure that on-the-fly fixes to earlier line items got "bubbled up"! I was absolutely horrified to discover that the functional tests for A would not be rerun on Rel 2 or Rel 3 until the end of their respective schedules. By then, Rel 1 would be already headed out the door.
That was due to oversight, lack of manpower, and adherence to old one-release procedures. Also, there was a different manager for each release, and they all had tunnel vision (as in "Not My Problem").
At the time, I was a lowly Senior Associate Programmer in a test department. I started with my own manager, and eventually went to every development, design, test, and planning first-line manager. They all said "Holy @#$%!!" They each agreed that this was BIG trouble. Without additional people to run additional functional testing, there was NO WAY Releases 2 and 3 could make their schedules, and there was no way they were going to get additional people. Not one of them took it up the management line. I think they all planned to just blame it on someone else. They kept looking to me to come up with a solution. "Whadda we gonna do! Whadda we gonna do!" I said we could head off some of the problem by ensuring that fixes got bubbledup, by perhaps building bases dynamically. So a department was scraped together to do just that. (Later, the guys who implemented it got awards. I didn't. I was blamed for the necessity. Sigh.)
The danger to the schedule was never "taken up the line" probably because no one had a solution, so they knew there was no point. "Eeek-a-mouse!" Maybe they hoped it would all be a false alarm. So upper management was taken completely by surprise when Rel 2 slipped the schedule badly, and Rel 3 completely blew it, badly. Bad scene all around. Everybody blamed everybody else, and they all blamed me. Kill the messenger.
__________________________
Each entry in the AOL journals is limited to 25,000 characters, including HTML, and they don't bother to give a running count, so rather than chance losing anything, I'm going to break here and continue in the next entry.
No comments:
Post a Comment