Ask HN: Do you start with a visual prototype or backend code?
7 comments
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.
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.
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!
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!
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.
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.
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.
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.
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.
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 :)
I build a visual framework first. It generates momentum for both me and the client.
I find it easier to understand how to hook up the backend code, once I know how the product should work visually.