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
drexsien
  • 441
  • 1
  • 4
  • 6

8 Answers8

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.

Paul Butcher
  • 2,817
  • 1
  • 18
  • 18
  • 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 08 '11 at 08:59
  • 5
    If they think the front end is everything, you could mention Google... – l0b0 Mar 08 '11 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 09 '11 at 09: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 '12 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 '15 at 09:52
  • Old answer, but would you please explain the last paragraph a little bit more? "_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._" You mean on large projects they don't take the features-first approach (the one you've suggested)? How do they proceed then? – aderchox Jun 25 '22 at 06:45
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.

S.Lott
  • 45,264
  • 6
  • 90
  • 154
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*

Erik Reppen
  • 6,243
  • 31
  • 34
  • 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 '13 at 14:55
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.

Péter Török
  • 46,427
  • 16
  • 160
  • 185
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.
Random42
  • 10,370
  • 10
  • 48
  • 65
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.

JeffO
  • 36,816
  • 2
  • 57
  • 124
  • 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 08 '11 at 09: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 08 '11 at 10:13
  • ops my fault im thinking of building...thanks for that jeff. – drexsien Mar 08 '11 at 10:34
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.

Fabasard
  • 11
  • 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 '12 at 00: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 '12 at 00: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 '12 at 00: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 says reinstate Monica Mar 18 '15 at 09: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.

Mawg says reinstate Monica
  • 4,142
  • 3
  • 33
  • 51
  • "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 '15 at 09: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 says reinstate Monica Mar 18 '15 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 says reinstate Monica Mar 18 '15 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 '15 at 11:02
  • I suspect that we might be saying the same thing in different ways (+1) – Mawg says reinstate Monica Mar 18 '15 at 13:12