Which is better to do first, design the interface or write code?

In a 开发者_运维问答one-man project (webpages or desktop applications) where you're both the designer and the developer, what is better to do first, design or write code?

By interface I am guessing you mean the user interface, as opposed to an API. I always design the interface first. When I'm coding I'm lazy -- I do whatever will get the job done with the least effort. This leads to interfaces that don't make any sense just because that was the easiest (or cleanest) way to do it in the code. But before you have written the code, you are unbiased and will make better decisions about what a good interface will be.

However -- they will still be bad decisions. You may think you know what feels natural, but you don't. Test it on people! Watch what they do, how they try to use your software, ask them questions and adapt accordingly. If you are doing this often, then it doesn't matter if you design first or code first. This is the way to make a top-notch product.

I think that by saying "designing the interface" you mean the graphic interface. As PNL teaches, you will handle better things you already see, so visualization helps a lot in the design of a new project.
That's why I start projects following my first visual idea by drawing the mockups of the pages I exactly know how are going to function, with pen and paper (I am happy to read that many esteemed colleagues also do that).

This allows me to conceptualize the application entities (which are likely classes) and functionalities (which may directly be translated into methods).
At this point I write the programming interface, which for me is the most important part of an application both when starting from scratch or for future rework.
Usually it is not a completely new programming style, since many programmers have their preferred patterns and syntax and code to reuse or are driven to some solutions by the framework/environment they have to work on, but anyhow I deem it a pivotal task.

Before writing the code I also design the DB, which use is also delegated to lower level methods used by the interface methods I already wrote (the 90% of projects I worked on was DB-dased), putting down every idea comes to my mind about attributes or side-tables which may better complete the information handled by the application or improve functionalities.

When I have time, I also make some tables and diagrams using Excel, defining the whole CRUD tasks for each table (obviously not every table may need all the CRUD tasks).
This allows me to write in a few time also the general SQL queries, which also reduces the work of writing code, avoiding to switch the attention to other SQL dialects.

I start writing code as the final task, and at this point the work is done.
Writing the logic of the application with the background explained allows me to only think and write in the main language(s) chosen to realize the project, which usually is PHP for server side processing and JavaScript for the client GUI.

I experimented the truth of a phrase one master used to say frequently: a good work is 90% planning, 10% carrying out.
I deeply agree: when a good planning is done, the rest is simply packaging all the pieces.

Happy coding and a lucky new year! :)

From a common sense perspective I'd say a mockup design (think pen and paper) is best to start out with. Define what you want the program/site to do and how it should look without going into details. If you have a clear set goal from the start concerning functions and design on a smaller project implementation order shouldn't be that big of an issue.

I however must say that I always do the code before the design, and I rarely create mockup drafts. Also I never follow my own advice.

This is I think a common step by step approach:

• Find out what the requirements are.
• Make mockup of the application and show it to clients or colleagues.
• Create a global technical design. List technologies to use and high level overview of the components to be made.
• Then start coding or make a more detailed design.

First design UI, that will give you a clear picture of what your system will do, what type of data it displaying, and how users will interact with it.

I usually design the project on the paper (or with diagrams tools), then write the core part and finally the user interface. GUI is the last. So you can make tests first with the logic part of the program and only afterwards with the presentation part.

Let's say the direction of development seems like going from the centre of an onion to the outer part.

I suggest that you make a blue print of your user interface then simultaneously do the coding and interface. It'll be better since you can get the output instantly if you like and can change it too.

This is sort of like HTML page testing.