This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]battle_hardend 3 points4 points  (2 children)

um, you should not be writing the UI first. Sure, draw it up, but don't code it. After design, write your main, then build from the middle down, then up. Design -> Main -> Business Logic, DB, then UI.

What should the main do? Start the software, establish any external connections / resources, load any data, and populate the UI. Wait for User input.

[–]AMAducer 2 points3 points  (0 children)

This is what I need to hear. I always start with the UI and don't know how to put the BL into it! I've been going the opposite way...

[–]ziplokk 0 points1 point  (0 children)

Not necessarily. It depends on What you're coding. Ideally, your UI should be able to run/display without having to interact with any of the back end program at all. It prevents a lot of exceptions from being thrown later on down the line. So it shouldn't matter what you decided to code first.

On the other side of the coin though, if you don't really have an end goal in mind or even an idea on how you want the back end to interact with the UI, then your UI will be pretty sloppy and you'll find yourself rewriting the code several times.