

Ask HN: Do you start with a visual prototype or backend code? - duckitch

I&#x27;ve started working on a project from a visual prototype before I get into the backend code. I wanted to find out what approaches others use.<p>I find it easier to understand how to hook up the backend code, once I know how the product should work visually.
======
RollAHardSix
I've always built front to back, and yet every job I've worked starts with the
database schema's when starting a new project.

To me, everything makes more sense when you work front to back and it's easier
to de-couple things when requirements change.

Everyone else seems to enjoy working from the back to the front for some odd
reason. I really think it's a if you started with databases you prefer
databases or if that's what you've worked with longer you prefer that. I also
think it has to do with databases being easier for upper management as they
age and move away from programming.

But then again I just spent an hour figuring out a complicated function being
used to parse a semi-comma delimited list being stored in a single field by
someone with '10 years SQL experience'. AKA SQL anti-pattern 101.

No-one really knows what they are doing dude. Things evolve too quickly. Some
people are really great, they end up outside programming. Some people are
really good, but age and time still get you. You fall back on what you know
intuitively even if it may not still be best practice from 2-3 years ago. It's
like CSS. Things just evolve and shift so quickly, it's hard to keep up even
with the amount of professional study we do.

------
bjourne
Good question. I firmly believe that beginning with the visual prototype is
the right thing to do. That way it becomes much easier to hash out the
requirements with the client (they _always_ change) and let "what is it you
want to accomplish?" questions decide how the system should be implemented.

Crappy programmers always start with the frontend first because they don't
know anything better. Good programmers often start with the backend, and
specifying a huge database schema. In my experience that invariably leads to a
rigid system with way too many complicated relations and features no one need
or asked for.

One concrete example I've seen a million times is someone making a feature for
advanced access controls, privilege levels, user accounts, who can edit this,
who can see this etc... And in the end it turns out all users are using the
admin account anyway!

------
lugg
I attempt to keep the two separate. Designing your back end while keeping the
frontend in mind will tend to create tightly coupled code that is hard to
maintain.

Even if you're not creating an api, treat your back end as such to avoid that
tight coupling.

That's how I approach it anyway. Generally works, there is always exceptions
but for the most part it works out ok.

------
kinj28
I prefer visual prototype, to clear ideas and check if representations match
with requirements. This is the case when there is requirement from client. But
when we are building new products from scratch.It usually is backend code but
front end visuals keep changing with each iteration.

------
determinant
It really depends.

In one case, I started with the back-end because I figured that, to make money
with the product, I could coast with a minimal front end for quite some time.
Then, in another project, I thought the front-end was the selling point so I
went with a minimal back-end.

------
NicoJuicy
I used to build the backend first (for my own projects), but now i create the
frontend as fully as possible before any backend. You'll encounter the same
problems while building the frontend, you just don't have to alter the backend
every time :)

------
jesusmichael
I build a visual framework first. It generates momentum for both me and the
client.

