Front end first or Back end first. Of the two which is a Good system design pratice?

Question

I have a client right now requiring me to develop a school enrollment system. Now this is the first time im having this kind of challenge. Most of the past software that i created are not that complex.

I know most all of you have created complex softwares, i just want your advise on this. Should i design first the front end or back end?

thanks!

Here's a conclusion of an article I found in the internet a while ago. Just whant to share

http://www.skitoy.com/p/front-end-vs-back-end-developers-my-take/157

Front-end vs. back-end developers (my take)

My personal take

Again it’s a matter of training, some broad stroke generalizations:

Front end developers

• Typically don’t have a CS degree, or have a CS degree from a 3rd tier school.
• Work in languages that similar to basic (see PHP is Basic)
• Have a visual skill in converting photoshop documents to CSS/HTML/etc.
• Have a high tolerance for iterative programming, due to type free languages

Back end developers

• Have a CS degree or lots of experience
• Tend to me more systematic in their problem solving approach
• Don’t mind spending days finding the one object that is leaking
• Try and build tools to solve problems

Answer 1

If you start at the back, and go forwards, you run the risk of misunderstanding the client. As you will be creating things that they can't easily see and comprehend, they can't participate very easily in verifying whether you meet the requirements. This means that you might waste a lot of work.

If you start at the front, and go backwards, you run the risk that the client will think it's almost done, when all you have done is draw a simple form on the screen. They may then question why it's taking so long, since you had it mostly finished in a few days. You also run the risk of painting yourself into a corner, when you realise that you have to do some complicated work to marry the front to the back, when a more suitable front-end would have been simpler.

IMO, you should work on it feature-first. Write the front and back end together, for each feature in the system. This gives the client greater visibility of progress, and it gives them the opportunity to say "no, that's not what I meant", without causing you too much distress.

That said, if this is a very large project in which you need to consider the server hardware or the capabilities of any software you rely on (e.g. which database you are using), then you should probably have a good think about that part first.

Answer 2

There are many dimensions to software, therefore, an overly simplistic front-vs-back is a poor question and is very, very difficult to provide a sensible, useful answer to.

One view is the static structure of the data. There are at least three dimensions on this view: architectural layers ("front-to-back"), use cases and actors, as well as costs or risks of implementation.

One view is the dynamic structure of the processing. There are at least three dimensions to this view, also.

A third view are the architectural components, which fall naturally into layers, support use cases, and have costs and risks.

I could go on, but the point is this.

Front-end vs. back-end developers (my take)

Is approximately the least useful way to look at the problem. The actual developers -- and your opinions of them -- matter very, very little here. What matters are

• Use Cases and Actors

• Logical data model to support those use cases

• Process that's done as part of the use case

• Components you'll use to build that logical and processing elements of the use case.

This is why most folks say that you need to decompose your system by user story or use case.

Not make broad stroke generalizations about people who will be doing development.

Answer 3

Neither. What does your app need to be able to do? Make sure the hot valve delivers hot water, the cold valve delivers cold water, that the water flows in the first place, that you can extend pipes wherever needed and then worry about implementing actual plumbing to all rooms of the house or what the house will actually look like exactly.

The front end is just a mask with some switches and levers on it. The back end is just a thing that receives requests to retrieve and process data. Get to a point where you can rapidly implement both in any desired combination first.

But whatever you do, don't let the design of one dictate the design of the other. That way madness lies.

Get the tools in place to let your devs build whatever the heck they need for your client, regardless of how many times they change their mind. Then build it to specifications and rejigger it until the little cusses are finally happy.

Also, comparing front end devs to back end devs in 2008 is a long time ago in web years. For the sake of fun, I'd like to correct/add a few things to that old chestnut since we've linked it in the question, but also (hopefully) embed a few tips within:

Front end developers

Typically don’t have a CS degree, or have a CS degree from a 3rd tier school.

Show of hands. How many people with CS degrees have been taught best practices on the front end? Or how to not make a mess with JavaScript? Or how to handle CSS problems from IE6-IE9? The textbook industry, which runs academia, is too fat lazy and bloated to handle constantly shifting technology so it has received very little 'serious' attention in colleges. This has been excellent for late-bloomers like myself.

Work in languages that similar to basic (see PHP is Basic)

Because PHP is client-side technology? Or because JavaScript, which was inspired primarily by Scheme has more in common with Basic then Visual Basic which is now no longer a going concern on the front end and never really was but is still available for back end .NET web applications? The blog compares self-taught open source web developers with CS grad web developers using corporate-popular tech at this point I think. I've run into insufferable and competent in equal shares on both sides of that particular fight but he's still way OT there.

Have a visual skill in converting photoshop documents to CSS/HTML/etc.

More attention to detail than "visual skill" which is a bit broad. Not all of us have any aesthetic design skills whatsoever. But yes, most of us have to learn this stuff at the Jr. level and it's actually quite thoroughly critical to writing good UI that doesn't use JS hammers when CSS scalpels will do.

Have a high tolerance for iterative programming, due to type free languages

This is why you want the pieces I mentioned earlier in place first. We pass on the buttons pressed, you produce/retrieve the goods. We package and deliver them. There is no reason for these things to in any way be tightly bound to each other. Also really, strict typing should not interfere with an iterative process if you don't suck at OOP which most people who like to get haughty about a language not technically having classes, in fact do, typically. But even if they do stink, the front end only needs a predictable point of access and you can do whatever the heck you want on the back end as long as you don't do something silly like dynamically write JavaScript that isn't JSON or tightly bind successful back end behavior to HTML structure being "just so." *cough* java devs */cough*

Answer 4

There is no single right answer to this. Either approach can be good (and bad) in certain situations.

I recommend you consider the TDD approach, where one is lead by (acceptance and unit) tests.

Start by putting together a skeleton of the system: the basic infrastructure, with the absolute minimum functionality. This is just to show that your concept works and the different components are able to work together. This also includes a bare bones UI (if applicable), just enough to actually do and/or show something minimal.

Then you flesh out the details, feature by feature: write an acceptance test for a specific feature/scenario, make it fail, then write code to satisfy it. This makes you work inward from the outside: the system receives some input message, so you need to handle/convert that message, do something with it, then propagate the results back to the UI. On the way you will discover the domain concepts and represent them with new classes, from the UI towards the domain layer and back.

For this approach, a recommended reading is Growing Object-Oriented Software, Guided by Tests.

Answer 5

API first

Engineers from both teams should work together on the API between the front-end and the back-end. Then both teams can start working based on the designed API. This has the advantage that another front-end team can also start the work (maybe mobile, after web client) besides the obvious advantage that teams can start working in parallel.

Combine with an iterative approach and should look like this:

1. Design a simple API
2. Both teams develop and test based on the API
3. Integration test
4. Show to client and receive feedback.
5. Enhance API and repeat.

Answer 6

Start with the frontend, but first, why can't they find an application that already exists? This would give some more insight on this project. Do they have some unique requirements or do they think you can build cheaper?

Get a full grasp of their security expectations and what the law requires. Not sure what type of school this is, but student information usually requires some confidentiality.

If the potential students are entering the data on a website, the graphical design is going to be more of an issue.

Based on their requests, draw mock ups of the front end. If you think the gui is not straight forwward, you may have to make something functional, so they can see it in action. They may see the enrollment as some type of 'wizard' that branches off in different directions based on the data entry.

Then you can start getting information persisted to the database.

Answer 7

Yes I realized the OP asked a while back. Start at the back end but MOCK UP the front end to allow the user to see what you envision. The front end, for all it is worth, is just the bells and whistles. The back end is where the money is, and once you have that straight, the FE is just the gravy over the meat.

Answer 8

Expanding on my comment:

First gather requirements, then turn them into Use Cases & design.

First comes a detailed database definition. I don't care if the client doesn't fully grok it, I force them to sit down & look at it - and sign off on it (possibly then forcing then to realize that once of their more tech savvy guys ought to do so), before proceeding.

How can you start with FE, without BE? FE for what??? Define your database!! That’s what the FE manipulates.

Ok, there will be problems & later tweaks, and I do agree that it is good to get a simple, sample, GUI in front of the client ASAP, since that particular tip of the iceberg is what most most understand.

However, I 1) stress that this is only a rough mock up, for discussion porpoises, and 2) deliberately make it ugly, but functional, so that those who don't understand can nitpick & tell me to make that input box exactly 400px wide & the background light-blue.

I fell that most answers here (and I have followed them) tend to focus too much on the customer, but, from a purely s/w point of view, I contend that you can't design a FE to manipulate a BE without first designing that BE.