Front-end first or back-end?

Question

Hi I have to do a small CMS application in MS ASP.NET using WebForms. I do everything on my own: front-end and back-end and Data Base schema.

I know HTML and CSS quite well, but very little of .NET and SQL (I just finish study some books).

Now that I want to develop the site, I wonder if I should start from front-end first, or back-end.

Could you guys give me a list of steps I do better following to help to determinate what is the best order for developing my application?

Thanks once again for your time.

Answer 1

I would say that in many systems, the back-end is there to support what is needed for the front-end to work. If you don't know what the front-end needs, there is little chance of successfully designing the back-end. So I'd start off with putting at least a rough front-end in place first (if even just a paper prototype).

Answer 2

I usually write out what my requirements are first, if I need to use a database, I create that first, always. After my database I start working on front end that connects and uses my already created database.

I worry about the front-end last, can you can always change that pretty easily

Answer 3

I find it easier to develop the logic and back-end first, so that I get that right, then apply the interface to it. This way you avoid writing functionality based on what you think you need from the front end.

It is important to get a good scope of what you want to do/tackle, and try to implement that in the back-end first. Then wrap it in a nice interface!

Answer 4

You'll develop all tiers as you go most of the time

For some page you may first create database schema and fill it up with some dummy data and than work your way up.

For others you may start with a page itself and then write functionality that's needed to get it working. Especially when this page hasn't been envisioned enough. This is not bad nor good. It's just the way development tends to be.

Some considerations

Follow agile development

1. Write down some requirements in a form of user stories (and keep track of them), that don't give any info about page, data etc. Just something like As a user I would like to have primary navigation on my page. This kind of a story will permit later changes to code/pages without the story becoming invalid.
2. Don't haste into something fully functional at first. Don't over-engineer your code. Because you'll end up doing changes later = follow YAGNI. For instance don't fully design your DB at first. Do just as much as you need per story being developed. But do think of future things that you'll have to integrate into existing codebase.
3. Refactor existing code right away when you see something should be changed.
4. If you have someone to test your code, let them do it. Don't develop next stories before existing bugs have been fully resolved. You'll be grateful for this later.
5. If your code is semi-complex I suggest you write unit tests, so future code changes won't break existing functionality.

Most of all: learn as you go and change existing code while doing so. Since you're learning these technologies I suggest you stick to simplicity at first. You'll add more complex things when needed. Some of them won't get done at all. So in the end youl realise YIDNI (yep, I didn't need it).

Answer 5

I tend to approach all of my projects with a back-to-front approach for one simple reason - testability. Writing solid tests against a back-end early will will make it easier to work on the other tiers progressively. It also, as "bonus" helps to keep business logic out of places it does not belong.