How do you avoid bikeshedding?

Good q. Personally I had to redefine bikeshedding as it appeared in different contexts, as part of a lessons-learned approach to wrapping up work days spent with projects.

For example, I found that some of the bikeshedding was a healthy and fun mental exploration, a very zen use of natural gifts that take very little energy and are more like meditation. So I was more hands-off about it being an issue when that was the case, and instead tried to capture more of the value from what I had done, so I could reuse or leverage it in the future.

In other cases the lack of a useful framework for getting up to speed is a really beautiful setup for the more frustrating form of bikeshedding. I had this happen once with contracts, because a client changed their scheme for coming to contract. God the amount of stuff I learned about LibreOffice while spinning my tires in the mud! In that case I developed a completely speculative framework for navigating contracting method changes, after all was said and done. It helped a lot later.

Prioritization is also more variable or modular to me now. I prioritize most often depending on ease of access to tasks, rather than importance.

Good luck, I hope some of this helps.

I kind of have a timer in my head. Or a sense of restlessness after a while - a sense that "this is taking too long for what it's worth". When that timer/alarm/restlessness/whatever triggers, I know it's time to try another approach. If it's a meeting, it's time to try to get everyone back on track. If it's a problem I'm trying to solve, it's time to question my approach or ask for help.

No, I can't tell you how I developed this. I had it at least by the time I was in university. (It came in really handy during tests - it kept me from wasting too much time on a wrong approach to a problem.) So, unfortunately, I can't give you any actionable advice. (Unless you get that feeling also, in which case the advice is, when it triggers, don't ignore it.)

Be clear about what problem your project solves.

Strive to keep that problem statement small, focused on the highest ROI problem.

Break the project down into milestones. That will tell you what to work on, and what not to work on. Set achievable deadlines to keep yourself accountable and laser focused on forward progress.

If a bikeshed question arises, ask whether it can be deferred and easily changed later. If so, defe9r it.

If the bikeshed question cannot be deferred, build consensus with the _key_ stakeholders. Try to keep that set of people small (just those with relevant expertise, and those with authority) and don't worry about pleasing everyone, trying that will be wasteful. Don't worry about the outcome, if its a small part of the overall ROI.

Projects don't have to solve all problems, just effectively improve the status quo.

I avoid bikeshedding by spending most of my time yak shaving.

I view technical debt as a meta-game. At the beginning of a project you want to take out lots of technical debt. Paper over stuff with easy choices, use other frameworks, try to make something bad that barely works.

A lot of times somewhere in the middle you declare technical debt bankruptcy by moving on to a new project and you never have to pay down any technical debt.

Other times the product grows and scales and you have to manage paying down the technical debt. Here you can even use the cheesy financial advice you hear on the radio about paying down debt. Considering what might be most likely to compound, what debt you might be able to later write off and avoid paying it now.

There is a constant push and pull of how much technical debt to take out, when to pay it down, and when to write it off.

I follow standards unless there is a very good reason. Usually if I do something nonstandard, it's because the standard thing isn't as suitable for automation, or just isn't reasonable at all.

Like, literally, if I have to make an arbitrary choice, I'll look at everyone else in the space and see what they're doing.

I'm not developing standalone projects, I'm developing plugins, for an imaginary suite that consists of all the other software in common use.

Like, plaintext vs database. My first factor to consider is Git, syncthing, and other such tools. Git likes plaintext. If it's something that should be versioned, synced, partially updated, etc, I'll probably use text files.

Coding style? Use the official one for the language. There isn't one? Use whatever is most common in your top 10 favorite libraries.

Choosing a framework? I look at what's mature and still popular and doesn't seem to have lots of people migrating away from it. I'm looking for stuff that will be around in 10 years, and where questions can easily be googled.

Totally arbitrary API structuring choice? If 2 or 3 other people do something similar, why not do the same?

There's enough value in standardization that it doesn't make sense to give it up for no reason.

Elegant beautiful stuff is still stuff you have to maintain and document and explain and argue about. Follow existing standards, and you can just point to PEP-8 and say "We use that" or "Our API is based on X, if you want to add something see that for a reference".

I have one big to-do list for a project. The list is organised by topics. If a new idea comes up in the context of something else, it is put on the list instead of being implemented immediately. (Exceptions are made for important quick fixes or very low-hanging fruit.)

From the big to-do list a selection is made for a short work-in-progress list, largely in consultation with the project client. I only work on the items on the work-in-progress list.

The work-in-progress list itself is roughly ordered by importance, but may be shuffelt around a bit according to new circumstances, insights or favourable opportunities (such as implementing one thing on the side when I am actually implementing something else).

If the work-in-progress list becomes too long because the client or myself think some new ideas are really urgent or important, some other items from the work-in-progress list have to be moved back to the big to-do list. Following the Pareto principle, this may also happen for items which have not been completely but sufficiently implemented.

From time to time the work-in-progress list will be completely revised.

My guiding adage is: You can only work on a single thing at a time; always pick the most important.

Honestly, mindfulness. Being aware of when your focus has deviated from your intentions and being able to bring it back can help to not go too far into rabbit holes.

I’ll propose that we modify to term to be “bicycle lifecycle management “ which could probably even be turned into a cool new term like. “Bi/life-cycle Mangement”

Then such a new conception would lead to an inevitable finality that just simply dampens any latent bikeshredding tendencies

Wrong approach. You really need to feed the trolls. With an important proposal always be sure to add an obvious bikeshed argument, so that that the trolls have something unimportant to argue about forever, so that the real meat can survive.

put a limit on granularity of finished product criteria.

-it has 4 wheels attached, task is done.

vs. bikeshedding

-what is the tire pressure? is the tread thickness even everywhere, is the static torque on wheel bearings uniform.

Chain it to a lamp-post