Most companies tend to suffer from the "no problem" problem. Management bumps into a worker in the hallway and asks, "How are things going?" The answer is always "No problem." Of course, that’s not the same thing as "Things are going well," but the manager assumes that was what the worker meant and wanders off, content.
Of course, frequently there are problems. But if you’re the worker, you probably don’t want to tell management about them. First, there’s the concern that a problem will reflect negatively on you. Even scarier, there’s the fear that management will offer to help. If your manager used to be a developer, she might take up your time by making coding suggestions. And that’s the best that you can get. I reported to a vice-president whose response to every problem was, "Well, you’d better work some overtime." Come to think of it, he usually followed up those suggestions with solutions based on his experience in creating VSAM file-based batch programs in PL/1. Workers soon learn that the response to "How are things going?" should always be "No problem, no problem…."
Yet, as a manager, I always wanted to know when there were problems. I tried to always reward the messenger and never punish anyone for bringing me news that I didn’t like to hear. Still, I have to admit that I made my contribution to the "no problem" problem.
The situation was this: A major project had fallen through, and the president of the company suddenly realized that we had to convert one of our subsidiaries over to our existing manufacturing management system. His guess was that the whole thing would take three days. I suggested that, if we were lucky, we might get it done in a week. I, at least, was smart enough to turn the estimation problem over to someone who actually knew something: Pete, a member of the IS staff who’d been supporting the system for several years.
I asked Pete to put together an estimate listing all of the possible tasks that would need to be done. I asked him to estimate the tasks in minimum half-day units and to break any task longer than two days into smaller tasks. I told him not to underestimate ("No one minds if you come in early") and to make up a schedule in which he had faith. The next day, Pete came in with an estimate of three weeks.
I said, "WHAT!"
I couldn’t have done anything worse. With that one comment, I sent a very clear message: I didn’t like to see large numbers. While I told Pete to come up with a schedule that he could live with, my reaction indicated that I really wanted a schedule that matched my estimate to my boss. I calmed down, thanked Pete for his estimate, complimented him on doing it completely and quickly, and went up to tell my boss the news. I eventually got a call from the president that began, "So, tell me how this three-day task has ballooned out to three weeks"–not a good start for any conversation. I offered to come up and go over the schedule with him to identify any task that we could avoid doing or that he thought he could do faster, but he turned me down. Pete’s schedule stood. We delivered a week early because Pete beat most of his estimates and I was able to assign a second person to the task. And, by golly, no one complained.
Still, I wondered. After that "WHAT!", how many "no problem" problems had I created? As a manager and an independent consultant, I’ve learned that the stuff that goes on "around" the coding is as important as the coding itself. I was very excited, then, to be asked to sit on the editorial board for Pinnacle’s new newsletter, Information Systems Consultant. I’ll be writing some articles for the newsletter (one on getting the right insurance and another on maintaining your tax deductions are already in the works). What I’m really excited about is the opportunity to read the material that’s coming up in the newsletter. It’s never too late to avoid making new mistakes.
Coding remains my primary activity, though you wouldn’t know it from what I did to Chris Weber’s article in our January issue. In the process of working on an unrelated problem, I "borrowed" Chris’ code and mangled it. The code on page 15 should have been:
On Error Resume Next
Dim rst As Recordset
Set rst = Me.RecordsetClone
rst.Bookmark = Me.Bookmark
'check for BOF
cmdFirst.Enabled = (Err = 0)
cmdPrev.Enabled = (Err = 0)
rst.Bookmark = Me.Bookmark
cmdNext.Enabled = (Err = 0)
'check for BOF
cmdLast.Enabled = (Err = 0)
Chris’ code cleverly gets around the limitations of using AbsolutePosition by using the On Error Resume to handle error conditions raised by his various Move commands. By checking the value of the Err object, Chris can check for both EOF and BOF. Chris has also sent along a new, enhanced version of his routines, which are included in this month’s Downloads.