-4

Recently I was facing several situations where a colleague was expecting, or “figuring out” a problem that may arise in a process that is to be done and trying to solve it preliminarily although they could quite easily check that such a problem will not arise when they actually run the process. An online example: https://stackoverflow.com/q/38369438/711006

Is there a term for such an situation? Are there general instructions how to prevent it?

Improve this question
5
  • @JoeStrazzere I am mostly interested in the systematic description and instructions to prevent such situations. I am only asking for the term because it is the way to find them easier.
    – Melebius
    Commented Jul 14, 2016 at 10:15
  • 1
    There arent any, since People go to their Manager explaining their concern about how Person x spending his time or not at all. Other than this tell the Person in question nicely dont try to fix things which arent broken.
    – Raoul Mensink
    Commented Jul 14, 2016 at 12:09
  • Maybe you are looking for the phrase "overly cautious". e.g. My colleague was being overly cautious. He thought there would be a problem, but it turns out there was nothing to worry about.
    – Brandin
    Commented Jul 14, 2016 at 12:24
  • Is it impacting his performance?
    – Old_Lamplighter
    Commented Jul 14, 2016 at 16:24
  • This question is hard to understand. Perhaps you can re-word it a little. Basically a co-worker is working on a perceived problem by first demonstrating it - however remote that problem can occur. You feel that you can avoid such a problem altogether by ensuring your program only accepts the right problem. Overall its a broad question and more of a opinion on best approaches.
    – Dan
    Commented Jul 14, 2016 at 19:48

4 Answers 4

Reset to default
2

I would say that that is a very valuable activity, and the linked question (without going deeply into it) was a valid worry. With any system I design, or develop, I have to think about what happens if the process or program fails in a particular way, and what the system or code should do.

It can be overdone though. For example, if I'm writing a Trading System for some regulated commodity I don't worry about what will happen to the trades if the Trading Company using my software goes bust. (There are several things that have to happen to the Trades but they are not the concern of either me or the Trading Company.)

For the same system, it is totally legitimate for me to wonder about what should happen is e.g. a trade confirmation doesn't arrive in a reasonable time (process failure) or my code encounters an unexpected error trying to e.g. save data to the database (system failure: how to recover?), plus anything else I can foresee.

Improve this answer
4
  • 1
    We used to call it "brainstorming" or "Staying ahead of issues"
    – Old_Lamplighter
    Commented Jul 14, 2016 at 12:46
  • 2
    @RichardU: I used to have a colleague who hated the word 'brainstorming' for some reason. He was quite keen on having 'wide-ranging conversations' instead :)
    – simon at rcl
    Commented Jul 14, 2016 at 12:49
  • LOL! Gotta love corporate speak. "We need to be proactive instead of reactive because at the end of the day, the bottom line is that if we move the goalposts back, we can create a new synergistic paradigm which will empower our employees to upskill and monetize our new corporate vision."
    – Old_Lamplighter
    Commented Jul 14, 2016 at 12:53
  • blogs.msdn.microsoft.com/oldnewthing/tag/microspeak - Long-term Microsoftie blog (required reading for Windows Devs) filtered by entries about Microsoft corp-speak. Quite funny.
    – simon at rcl
    Commented Jul 14, 2016 at 12:56
2

If it's not impacting his work, it's not a problem. Sometimes engaging in hypotheticals, even if unrealistic, inspires thought and action to solve real problems.

This is especially true in IT and any branch of engineering where you have to be half artist in order to solve problems. This involves creative distractions such as hypotheticals, listening to music, going for walks and other actions that make it appear to someone outside the field that you are not working.

That said, if your colleague is not delivering, then it's time to act, but if he is, it's best off to leave him alone.

Improve this answer
1
  • I think it's a conflict of thought. The OP believes the problem could never exist and can be demonstrated by actually running the application. The co-worker believes that certain situations could arise, however remote it may be, without running the actual application. This sounds less of a problem within the workplace and more of a question on what is the best approach to problem solving.
    – Dan
    Commented Jul 14, 2016 at 19:51
2

Response depends on why the coworker is working on this task. If your manager assigned it then you need think no more about it. The coworker is doing what they are supposed to do even if you don't agree with some of their hypotheticals.

When I have done testing I always try and do the stupidest things I can think of. What happens if you click this button while holding down the shift key? What happens if I turn my computer off in the middle of a transaction? What happens if while using it I spill coffee on my keyboard and then wipe it off with a nonabsorbent towel? Whatever you can imagine some user is going to do so don't discount a test just because it does not seem likely.

If the coworker is not performing this work under manager orders, it should be quickly self correcting as he is asked why his real work is not being completed.

Improve this answer
0

General way to discourage this sort of thing, is to give the person real work, with real deadlines to meet. Then they don't have time to make up hypothetical fantasy worlds.

Improve this answer
7
  • I dont the op in question has the authority to give his colleague work.
    – Raoul Mensink
    Commented Jul 14, 2016 at 12:10
  • How do you know that? If he doesn't then it's not his problem what the colleague is doing, it's the managers
    – Kilisi
    Commented Jul 14, 2016 at 12:18
  • I doubt*, but i know that because he says colleague not one my Team members or someone under or I am his Manager ect :D
    – Raoul Mensink
    Commented Jul 14, 2016 at 12:21
  • OP asked for a general answer, I gave one, whether he has the authority or not, that is a solution. He just has to work out how to accomplish it.
    – Kilisi
    Commented Jul 14, 2016 at 12:24
  • 1
    I disagree with the answer, but it is still a good answer. +1 Caveat: engaging in hypotheticals can be real work. I usually end up using the answers later.
    – Old_Lamplighter
    Commented Jul 14, 2016 at 13:12

Not the answer you're looking for? Browse other questions tagged .