What are no-go's and rabbit holes in software development?

"No-go's" and "rabbit holes" are both terms used to describe issues that can arise during development that can cause delays or problems with the project.

A "no-go" refers to a significant issue that prevents the project from progressing. For example, a critical bug in the code or an insurmountable obstacle in the design could be a no-go issue. When a no-go issue arises, the project cannot move forward until the issue is resolved.

A "rabbit hole" refers to a situation where a developer spends an excessive amount of time investigating a particular issue, often at the expense of other important tasks. The term "rabbit hole" comes from the story of Alice in Wonderland, where Alice falls down a rabbit hole and ends up in a strange and confusing world. Similarly, when a developer goes down a "rabbit hole," they can become lost in a complex and time-consuming investigation that distracts them from other important work.

Both no-go's and rabbit holes can be costly in terms of time and resources, and it is important for developers to be aware of these issues and try to avoid them when possible. Good project management, clear communication, and a focus on priorities can help minimize the risk of encountering no-go's and rabbit holes.

Comments

[Bad Request 400]

Depending on the scale of the project ofc there could be a huge number of pitfalls or "no-go's"/rabbit holes.

If we talk about general Project scopes its easy to go down the rabbit hole of "we could use this feature" or "this last 1% feature is a blocker so we cant move forward".

What i've learned from, brutal brutal mistakes on my part is:

• Focus on the MVP (minimum viable product) aggressively
• Put features that are absolutly not neccesary but nice to have in a separate bucket
• If you handle new tech in this project and its in the MVP Bucket, sprint to it as fast as possible. Try to get hands on (this should be your number 1 prio) with it asap (you need the practical experience)

If you are the or one the Project leads:

• Do a pre Mortum:
  • I usually on the second Meeting (1st is the Kick-Off) do a pre-Mortum
    • In this meeting the whole Project Team should tell me where the project could go wrong
      • I also encourage them to not wishy wash their talk, if they wanna say "The DB Team couldnt make it in time" then they should say it. No personal insults ofc but its good the get these things out as soon as possible.
• Communicate early what your central documentation place is. I've seen (and done) it many times that there is documentation in a wiki, in git, in confluence in Ticket Systems and in Excel or Word Files on some Share no one will ever find or use
• If it is a big Project (5y + for example) identify your Top performers early. Monitor them bc they will stumble upon things that could be problematic early on. Also keep them happy they are the one who will go the extra mile for you if the project has problems making a milestone
• Plan your milestones in a way that allows 1 Meeting after every Milestone to meet up and recap and also to just relax. Project Work can be really demanding and you often develop an "me me me" personality bc you always see the other ppl just in a stress enducing and often times number driven environment. If they have a way to interact with each other in a laid back and more relaxed manner it will help to strenghen those bonds bc the next problems or (fcked up) milestone will come.

If we talk about purely coding i would say the biggest rabbit-hole is absolutly "Tutorial Hell".
Seen it a million times, done it many more times. Imo its more important to find out how you learn best. I learn best when im getting thrown into a situation where i need to know how to do stuff. So for me what always worked best in the end is starting and stumbling my way to Version alpha 0.1.

And in terms or No-Go's i would say choosing a Framework or Tech to show off how good you are. I've done it in the past where i got super cocky and ended up doing something purely to show that i could. That always bites you in the behind later on.
If you wanna use new tech go for it but do it for a better reason than "bc i can". Like i said, done it, been there. Sucked in the end.

so long