
Ask HN: How do you draw the line between bikeshedding and design? - 719Ben
Hi HN,<p>I am currently working on a project with my co-founder. We will sit down and talk about the design decisions we want to make before we start to code anything up. We have been doing this for about 2 months now. Sometimes the chats feel like design talks and sometimes it feels like bikeshedding.<p>Where and how do you draw the line between application design and bikeshedding?<p>https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Parkinson%27s_law_of_triviality
======
angersock
My ex-cofounder and I sat down at a table and hashed everything out at the
interface level--what HTTP requests to make, how messages were handled, etc.
We didn't second-guess each others' implementations, because as long as the
interface was stuck to things were fine. That saved us a lot of bikeshedding.

I would say the line is generally "Are we both right given the current
business needs?". If the answer is yes, then you're bikeshedding, and should
just flip a coin and move on.

~~~
719Ben
I like this advice. You hit it right on the head. I am asking about programing
design, not interface design. We will start to flip a coin.

------
nostrademons
When are you getting feedback on the design? Real design is about adapting to
the users' needs, not the founders. You do need to put something out there to
get useful feedback, but you should spend the bulk of time implementing things
that the users would not have thought of by themselves.

As a general rule of thumb for the startup phase, if people are arguing about
it it's not worth arguing about. Pick one and show it to users, and usually
the users will resolve the question for you. The design decisions that matter
are the ones that everybody can look at and say "This looks off", eg.
including adequate margins and whitespace, picking a sane color palette,
making information easily skimmable, not forcing the user to perform extra
clicks or interactions. When they fail, it's usually because the founders
never thought about them in the first place rather than because they thought
of them and picked the wrong one of two equally-viable alternatives.

~~~
719Ben
We have yet to launch. I was talking about system design, not so much user
design but I will keep this in mind as we start to get more and more into user
design.

------
AnimalMuppet
Ask "how much does the customer care"? If the answer is "not much", waste very
little time deciding what to do.

Then, pay attention to when one of those decisions turns out to really matter,
and be willing to revisit it when actually needed.

------
a-dub
Two people, two months, zero built?

Bikeshedding is piping up on trivial issues to draw attention to yourself in a
group. There's only two of you? You should have enough mutual trust such that
nobody feels the need to show off.

I'd suggest putting a stop to any more design meetings. Get a prototype
working, iterate from there. What needs to happen will become apparent. It's
all smoke and mirrors in the beginning anyhow. Take a page from the Italians
and their fancy A-GEE-LAY methods.

~~~
719Ben
I worded this incorrectly. We have quite a lot bilt. We talk about code design
for each part before we build that.

------
spotman
depends on your project and its complexity.

perhaps one way to improve the approach is instead of thinking about your
design and if it's perfect, encourage thought along the lines of "how do we
build this so we can change how it works later?"

things always change. there is no perfect spec or style on day 1. the best
code is always written during refactoring, so design to make that part easy
and while your idea is new and not launched optimize to get it launched.

