Wikimedia Meta-Wiki

Learning patterns/When things go wrong, just tell people

< Learning patterns
Translate this page
Other languages:
A learning pattern forreporting
When things go wrong, just tell people.
problemEverything has gone horribly wrong! Panic! Don't tell anyone, and maybe the problem will go away!
solutionTell people. They can bail you out.
creator• Isarra
endorse
created on00:32, 26 January 2019 (UTC)
status:DRAFT

What problem does this solve?

Has your project gone terribly wrong? Months behind schedule? Everything on fire? Your developer hit by a bus?[1] You promised a solution that turned out to be completely impossible, and now you're scrambling to come up with something else? You certainly can't admit to all this, now can you? It'll just make you look as incompetent as you're afraid you are!

What is the solution?

You're not incompetent.[2] This happens to everyone sometimes.[3] Just tell people and we can work it out. You need the resources to resolve the underlying problems, and they do exist, so the sooner you get to it and deal with the problems, the further these resources will go.

Things to consider

  • This shouldn't be happening five times in a row. If this is the fifth time in a row this has happened, consider telling someone about that and seeing if you can get some help with the whole management thing in general. Which is to say, just having someone else do that part at this point.[4]
  • If your lead developer really is dead and they were the only one who understood your codebase to begin with, you might have a problem, yes. But there are also workarounds - if the codebase wasn't totally awful, for instance, another dev can probably figure it out without too much trouble, given some extra time. And if it was awful, well, we do have some truly insane devs who actually specialise in that sort of thing, too.
  • If the wiki actually is on fire, people are going to notice, and it looks a lot better if you report it yourself and try to get it fixed yourself. So go do that. Right now.
  • If the problem seems to be a specific person, you might want to consider firing them. But first, see if you can find out whatever the issues really are. Go talk to them, too. It works both ways.
  • This doesn't necessarily apply if you expect you might be facing prison time, risk hospitalisation, or might otherwise put yourself or someone else in actual danger by bringing it up. In that case, consider simply abandoning the entire thing, changing your name, fleeing the country, and removing all evidence anything ever happened. Certain projects may have some useful advice as to how to fake your own death, as well.

When to use

Any time everything has gone horribly wrong:

  • We lost our entire database because we put off setting up proper backups for six years and then the hard drives failed. Fortunately once we got the word out, it turned out some random user had gotten into the server and copied over some local backups a few months ago, so we only lost a few months of data, as opposed to all of it. -- The imbecile keeping your site up 22:30, 8 March 2018 (UTC)
  • I got hit in the head with a flight of stairs and my entire project was delayed for two months. I just told people once I was betterer enough that that was what had happened and why I hadn't done anything in two months, and they were like, ah, that's cool, carry on, then. And then I went on holiday.[5] --A developer (ignored pull requests) 00:55, 26 January 2019 (UTC)[reply]

Endorsements

  • I wrote it. I'm not sure I should be admitting this, but it's a whole pattern about admitting to things, so here I am. -— Isarra ༆ 21:25, 28 January 2019 (UTC)[reply]
  • This is something which helped with the "shared variables" part of the AbuseFilter overhaul project. In general, I think it's vital to always admit it if something goes wrong. Failing to do so will usually lead to problems much migger than the original one. --Daimona Eaytoy (talk) 16:34, 25 March 2021 (UTC)[reply]
  • I am the project manager and lead developer of the Web2Cit project. During the first half of the project I was also finishing my PhD thesis, and it soon became apparent that it was taking me longer than expected. This was a source of frustration and stress, because I could no longer postpone writing my thesis, but at the same time I felt terrible that the development branch of the project was starting to fall behind. Finally, we did what we should have done from the beginning, which was telling the grant officer about the situation and asking for a two-month extension of the midpoint report due date. The request was kindly accepted and it was such a relief after that! I could write my thesis with much less pressure, and we met the midterm report goals on time with the new due date. Diegodlh (talk) 10:52, 28 March 2022 (UTC)[reply]

See also

If you have the opposite problem, and nothing has gone wrong, we can help you with that, too:

Notes

  1. ↑ Intentionally? Several times? By your other developer?
  2. ↑ Probably.
  3. ↑ Except maybe Tim Starling.
  4. ↑ Which is also useful because if it still goes wrong, at least at that point it's not your fault. It's theirs. They take the blame because they're now the management person.
  5. ↑ This one actually happened, and you know it turned out okay because now there's a report and everything.
Retrieved from "https://meta.wikimedia.org/w/index.php?title=Learning_patterns/When_things_go_wrong,_just_tell_people/en&oldid=24111368"