Learning patterns/When things go wrong, just tell people
What problem does this solve?
Has your project gone terribly wrong? Months behind schedule? Everything on fire? Your developer hit by a bus? 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. This happens to everyone sometimes. 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.
- 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. --A developer (ignored pull requests) 00:55, 26 January 2019 (UTC)
- 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)
If you have the opposite problem, and nothing has gone wrong, we can help you with that, too:
- A short guide to bad projects
- A fine selection of mistakes for organizing an international conference (and how to make sure you commit them)
- Intentionally? Several times? By your other developer?
- Except maybe Tim Starling.
- 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.
- This one actually happened, and you know it turned out okay because now there's a report and everything.