33

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
Improve this question
5
  • 2
    Related question: Can it be useful to build an application starting with the GUI?
    – Péter Török
    Mar 8, 2011 at 8:40
  • 2
    smh, this is the reason why I tell people I am a Software Developer vs Web Developer.
    – pllee
    May 30, 2012 at 2:38
  • 11
    What do these generalizations about front and back end devs have to do with the question?
    – Erik Reppen
    Sep 28, 2013 at 16:38
  • Front End Dev != Back End Devs , although most the time ,transitions b/w them keeps on going.
    – Abhinav Gauniyal
    Dec 9, 2014 at 2:19
  • I think the only valid answer here would be 'It depends...'
    – Oliver Weiler
    Mar 18, 2015 at 11:06

8 Answers 8

Reset to default
51

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.

Improve this answer
6
  • I think thats a more concise explanation. But would it be better to make the back end first coz i think its easier to create the front end if you have a well structured back end.
    – drexsien
    Mar 8, 2011 at 8:59
  • 5
    If they think the front end is everything, you could mention Google...
    – l0b0
    Mar 8, 2011 at 12:22
  • 2
    That's why you should build a mock-up GUI which you show to the client and say "Is this what you want the program to do?", and once that's settled you throw it out and start building the backend.
    – gablin
    Mar 9, 2011 at 9:53
  • 2
    +1. @andsien: If you already got your opinion, why did you ask? To my experience, Paul is right, feature-driven development is almost always the better strategy.
    – Doc Brown
    May 29, 2012 at 21:16
  • 6
    @andsien: "it's easier to create the front end if you have a well structured back end". IMHO that's a dangerous misunderstanding. The problem is: You don't know whether your back end is well-structured until you have used it to build features for the frontend.
    – sleske
    Mar 18, 2015 at 9:52
9

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.

Improve this answer
7

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.

Improve this answer
7

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*

Improve this answer
1
  • My only regret is that I can't +1 your question more than once. It's a shame that I had to scroll down 2 answers to this question to finally find the one where it's stated that asking about the order in which front and back and should be developed is the wrong question to ask. I also agree with your opinion on the CS Degree. And the final "late bloomers" remark.
    – Shivan Dragon
    Sep 27, 2013 at 14:55
1

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.

Improve this answer
3
  • 1
    the problem in starting with the front end (based on experience) is that when you forget some functionalities, it can mess your back end and could end you up circling around trying fix it
    – drexsien
    Mar 8, 2011 at 9:04
  • 1
    @andsien - are you talking about designing or building? I wouldn't start building a front end without designing the backend first.
    – JeffO
    Mar 8, 2011 at 10:13
  • ops my fault im thinking of building...thanks for that jeff.
    – drexsien
    Mar 8, 2011 at 10:34
1

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.
Improve this answer
1
  • I will add that, not just api but also the data/data format api returns, so both team can have mock data to work with.
    – Qiulang 邱朗
    Jul 23, 2021 at 9:51
0

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.

Improve this answer
4
  • Sadly it's what clients want, typically, but I think such behavior should be discouraged. Don't get them hung up on the visual and stick with your prototype looks until they're able to verify they're getting the basic behavior they wanted. Clients are often unable to separate eye candy from useful feature and they will have you waste a lot of time on the less important stuff only to blame you when the app fails at its ultimate intention in the long run.
    – Erik Reppen
    May 30, 2012 at 0:18
  • @ErikReppen I have had that experience many times -- I wanted to show the client "the user will enter data in a text field" and the client sees "the form field will be exactly 400 pixels wide and the page will have a pale blue background with Arial 11pt text..." But I still think it's better than never demoing a front end. Otherwise it's possible to build an entire system that conflicts with some unstated assumption in their main use case.
    – octern
    May 30, 2012 at 0:25
  • You can demo a front end but keep it plain and simple. Get them away from the photoshop exact foolishness unless that's how they demand it be sold to them. And therein lies the problem. It's what they've come to expect but they're more often than not too damn stupid to prioritize pixels from "actually makes our customers do what we'd like them to do."
    – Erik Reppen
    May 30, 2012 at 0:32
  • errr, isn't that why we have CSS? (although I do feel your pain). I always & deliberately have an ugly, but functional, FE & make plain that we are discussing Use Cases, workflow ... & can prettify it later. (but the true answer is requirements-> database->FE)
    – Mawg
    Mar 18, 2015 at 9:19
0

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.

Improve this answer
5
  • "you can't design a FE to manipulate a BE without first designing that BE". Oh yes, you can - that's called a "prototype". It can be a valuable first step when starting a new system.
    – sleske
    Mar 18, 2015 at 9:57
  • what is it prototyping? No flame-war, it just popped into my head. I do understand what a prototype is, but maybe because I came from a different field, I just always see it as : get the requirements, turn them into use cases & design. If you don't have your d/b nailed down then you will do mucho mucho unnecessary rework, so get that sorted first, then figure out how to manipulate it (as per the requirements). YMMV ... continued ...
    – Mawg
    Mar 18, 2015 at 10:04
  • It's arguably not black & white, else the question would not have been asked, but BE first, always, IMO. In fact, I am doing one that way right now for clietns who have only a vague fuzzy feeling in place of requirements (I should never have touched them, but that's a whole nother story :-)
    – Mawg
    Mar 18, 2015 at 10:05
  • 1
    My experience is that user requirements should come first, and architecture should follow. But of course this depends on the technical details, some things are indeed hard to change later. At least it's important to be aware of the tradeoffs.
    – sleske
    Mar 18, 2015 at 11:02
  • I suspect that we might be saying the same thing in different ways (+1)
    – Mawg
    Mar 18, 2015 at 13:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.