Should I start with GUI or Code Logic?

[u/Gloomy-Floor-8398]

I am planning to make my first executable since I am getting sick of just writing scripts. The plan is to use mySQL for the db, python for code logic, and pyqt6 for the gui. So my question is as the title says, which would be best to start out with or does it even matter and its only preference?

[u/kindredsocial]

When starting a new project, I find the most value with starting with the data. Once you know all the data queries and transformations your project needs, everything becomes much easier. The data requirements can come in various forms like an openapi spec, graphql spec or even a list of functions and classes.

How do you figure out the data requirements? This is where I think starting with the GUI makes sense. The GUI will determine the UI/UX of your program. Each page will have its own set of data points to display and different buttons will have data transformations. I recommend drawing out a simple flowchart of all the pages/screens of your program. Then for each page, list out all the bits of information needed to render that page. Once you see everything laid out like that, it'll be easy to design an interface that will connect the frontend and backend.

[u/Gloomy-Floor-8398 → u/kindredsocial]

thank you bro this helped a lot.

[u/polymorphicshade]

I approach stuff like this using the following rough template:

• Model - data the code will work with (i.e. PlayerModel)
• Service - a tiny "app" that does some specific job (i.e. PlayerService, get players, save players, interact, etc)
• Controller - logic that ties the UI to services by passing models around
• UI - displays models based on what the controller provides
• Tests - simple unit tests for my services and controllers to make sure everything works as expected (also acts as a sandbox to play with your solution as you build it)

I usually start with models and services to build a rough proof-of-concept of ideas I'll use in my solution.

Then when I'm comfortable with my proto-solution, I can easily slap on a UI (or web UI, or CLI, etc) to finish the job.

[u/rocco_storm]

Start with the user perspective. What du you expect your app to do? Model usecases and events and what data is needet for those. Based on that you can start with your first usecase, build the api that is needet for this usecase, model the data structure and a user Interface. And then add one usecase after the other.

[u/lockcmpxchg8b → u/rocco_storm]

Product manager here. This is the right answer. Your program is meant to do something for a user. Start with what your user needs. There is no universal method to get a good design for front-end and back-end. Incremental addition of features will give you something you can go get people to review/comment on, and that can guide UI refactoring.

[u/DesignatedDecoy]

The biggest e2e app issues are that your front end and back end need data presented in different ways if they aren't planned in tandem. The front end might require model X to be the primary focus but the backend has designed it as being a relation of a relation so the querying will be completely backwards.

I would start with wireframes to mimic what you expect the front end to look like. This is what your app hopes to accomplish. It can just be rough sketches, however this is important because it helps you realize how your data is related to itself. It also will hopefully let you see some decisions on efficiency, scaling, or design really early on.

Next I would probably take those design elements and translate that into models and create your DB structure. This will get your data layer ready to accept data and your models some structure and fields.

From there I'd likely do front end/back end on a feature related basis. I'm not as strong at front end so I'd likely create an api endpoint to accept in the values I expect and handle it through BE validation and persistence and then I would write a front end GUI to consume that api. Rinse and repeat for each page. Doing the reverse is fine and both have their own share of gotchas or rewrites based on discovery during this phase.

If you're part of a team where you aren't doing everything, a backend stub for fake responses or fake data would help alleviate the wait time between backend development and the front end being able to add their dynamic parts.

[u/DoctorFuu]

I start with the most minimal version of what my project is supposed to do. So never with the gui. I may list the features of the gui that I will want so that I can make sure to get easy access to the data needed for display, but I never start with the gui (output the results to terminal or to a text file).
Essentially, I want to waste as little time as possible programming something that may not work. So I'm trying to get a PoC as fast as possible. Once I have a PoC, I'll either restart from scratch or tune the code (tuning is not necessarily faster) to get cleaner code (in that data piping from source --> database --> processing --> output is well in line with what I want to get out of the program) and easy access to the outputs I want.

I'm biased as I'm not a dev though, there are probably contexts in which starting with the gui is not a bad idea. But as I either am doing solo projects (in which fancy display can wait) or working at my job on programs that will be only be used by people inside our team (and programming is just a tool for another job, not the end goal), we never build GUIs there.

[u/Pretagonist]

I'd say it very much depends. There isn't one single right way to do it.

Personally I usually start with some kind of user interaction that I want to sort of get a grip on what's needed. And then I'll use that to start building some models and how they relate and interact with each other. Then I'll build some scaffolding code that generates some models with plausible values. Then I'll write some apis or controllers that can send the data to the frontend.

Once my models start to stabilize I'll get to work on adding the db layer. Once I have some services or more than basic logic inside my models I write some tests. Then I start fleshing out the gui, see what works and what doesn't.

I used to try the way that I learned in school where you should first draw diagrams of the data but in reality I find that you never know enough about your domain until you actually start writing code. To model the data you have to make a lot of assumptions and some of them will be wrong. Quickly slapping something together that you know will have to be replaced or modified a lot let's you get a grip of the structure much faster and better than a lot of planning and drawing.

Also keep a list of thoughts, plans and todos at all times and whenever you think about some pitfall, feature or fix you add it.

[u/maxthed0g]

Design your database. Implement it, and test it with the sql browser. Then modify your code to issue database queries and what not through the python-to-SQL API. When that works, do the GUI.

[u/carminemangione]

To me... Kind of a top down, bottom up approach. What are your use cases. State them simply (should fit hand written on an index card) customer creates a new account with acceptance criteria. If you are in the exploration phase these can be more vague and bigger (not hitting edge cases) but the general goal is to create a narrative on how you are going to exploit the data or a new approach to a problem to provide value.

Now, you go to the data. If you have legacy data you are approaching, now you focus on if you have the queries and data integrity to answer your questions. If you cannot find a closed solution (data is in BCNF or 3rd normal form with protections) then consider statistical methods to create driving insights.

Focusing on the data will tell you how much of your business goals you can easily achieve or which ones will require some kind of machine learning.

The analysis I listed should take no longer than a week. You can do it our you can't. You can figure out what people are craving or you can't. Too many people focus on details that are irrelevant if you simply can't do it.

For me, the trickiest part is figuring out a compelling way to present your data / product to the user but that is cause I suck at UIs. See, you need to return to the original use cases and ask how you will compel your users to use your program when there are millions of others.

Now you have a frame work for creating the business tier: the valuable logic that will set you apart,

Notice: i have selected no technologies, no languages, no engineering approach. Your design and execution should be the emergent property of your requirements.

Personally, I find your stack problematic. However, my perspective has been saving companies that used an inappropriate stack who have a great product but it is buggy, non scalable and non extensible. If you just want to get noticed then stack does not matter but understand when the shit hits the fan if you are successful, you will be under the gun to rewrite it and so it right.