Read also
Peters editorial on  Faith

Most companies tend to suffer from the “noproblem” problem. anagement bumps into a worker in the hallway and asks, “Howare things going?” The answer is always “No problem.” Of course,that’s not the same thing as “Things are going well,” but the managerassumes that was what the worker meant and wanders off, content.

Of course, frequently there are problems. But if you’rethe worker, you probably don’t want to tell management about them. First,there’s the concern that a problem will reflect negatively on you. Evenscarier, there’s the fear that management will offer to help. If your managerused to be a developer, she might take up your time by making codingsuggestions. And that’s the best that you can get. I reported to avice-president whose response to every problem was, “Well, you’d betterwork some overtime.” Come to think of it, he usually followed up thosesuggestions with solutions based on his experience in creating VSAM file-basedbatch programs in PL/1.  orkers soon learn that the response to “How arethings going?” should always be “No problem, no problem….”

Yet, as a manager, I always wanted to know when therewere problems. I tried to always reward the messenger and never punish anyonefor bringing me news that I didn’t like to hear. Still, I have to admit that Imade my contribution to the “no problem” problem.

The situation was this: A major project had fallenthrough, and the president of the company suddenly realized that we had toconvert one of our subsidiaries over to our existing manufacturing managementsystem. His guess was that the whole thing would take three days. I suggestedthat, if we were lucky, we might get it done in a week. I, at least, was smartenough to turn the estimation problem over to someone who actually knewsomething: Pete, a member of the IS staff who’d been supporting the system forseveral years.

I asked Pete to put together an estimate listing allof the possible tasks that would need to be done. I asked him to estimate thetasks in minimum half- ay units and to break any task longer than two days intosmaller tasks. I told him not to underestimate (“No one minds if you comein 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 onecomment, I sent a very clear message: I didn’t like to see large numbers. WhileI told Pete to come up with a schedule that he could live with, my reactionindicated 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 itcompletely and quickly, and went up to tell my boss the news. I eventually gota call from the president that began, “So, tell me how this three-day taskhas ballooned out to three weeks”–not a good start for any conversation. Ioffered to come up and go over the schedule with him to identify any task thatwe could avoid doing or that he thought he could do faster, but he turned medown. Pete’s schedule stood. We delivered a week early because Pete beat mostof his estimates and I was able to assign a second person to the task. And, bygolly, no one complained.

Still, I wondered. After that “WHAT!”, howmany “no problem” problems had I created? As a manager and anindependent consultant, I’ve learned that the stuff that goes on”around” the coding is as important as the coding itself.   was veryexcited, then, to be asked to sit on the editorial board for Pinnacle’s newnewsletter, Information Systems Consultant. I’ll be writing some articles forthe newsletter (one on getting the right insurance and another on maintainingyour tax deductions are already in the works). What  I’m really excited about isthe opportunity to read the material that’s coming up in the newsletter. It’snever too late to avoid making new mistakes.

Coding remains my primary activity, though you wouldn’tknow it from what I did to Chris Weber’s article in our January issue. In theprocess of working on an unrelated problem, I “borrowed” Chris’ codeand mangled it. The code on page 15 should have been:

Sub NavButtons()
On Error Resume Next
Dim rst As Recordset

  Set rst = Me.RecordsetClone
  rst.Bookmark = Me.Bookmark
  Err.Clear

  'check for BOF
  rst.MovePrevious
  rst.MovePrevious
  cmdFirst.Enabled = (Err = 0)
  cmdPrev.Enabled = (Err = 0)
  Err.Clear
  rst.Bookmark = Me.Bookmark
  cmdNext.Enabled = (Err = 0)
  Err.Clear

  'check for BOF
  rst.MoveNext
  rst.MoveNext
  cmdLast.Enabled = (Err = 0)
  Err.Clear
  rst.Close

End Sub

Chris’ code cleverly gets around the limitations ofusing AbsolutePosition by using the On Error Resume to handle error conditionsraised 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, enhancedversion of his routines, which are included in this month’s Downloads.