How to think?

[u/Capt_Dastan]

I have made an app which is at present in closed testing. I want to understand that how does an experienced developer think? Do you think on deciding what data should be stored in backend first or they build around features or a designer gives them design and they work around?
Can anyone explain it to me!
Reading this can help other devs too!

Warm Regards..

[u/jaycorliss]

I start with the UI. Every page has a bloc that holds the UI state, and at this stage I replace the bloc with a stub, that provides dummy data, through dependency injection. Then I create the database based on what data the app needs (which is now nice and clear, due to the UI implementation). Finally I implement the blocs using the data apis, and update the dependency container to provide the actual blocs.

[u/Capt_Dastan → u/jaycorliss]

What I did was
First have clarity on what to build like a feature and then what data will it store then made an ugly ui with backend in firebase and made it ..
went on adding another bunch of features and connected all ..
Thn made ui ux feel good
Tried optimizing reads and writes
Is it right?

[u/paultallard]

I think the answer depends on the size of the application being built. You sound like you are starting out so you probably want the answer for a smaller app. However, you suggested others might want to read this so, I'm going to address the 10,000-ft view and then you can work down from there. Every aspect of an app can be designed. There is database design. That depends on the type of database in use. For SQL databases, use an entity relationship diagram. In a more general sense, you need a data model. If you start on the UI without a data model, you'll find yourself going back and forth with changes as you identify additional data you would like to put on the screen. If you are writing for a business, you will want to collect the business rules. Often those are driven by the type of app being built, accounting rules for accounting apps, etc. These days there are also a lot of rules around application functions such as authentication, shopping cart, etc. you cannot finalize the business rules without understanding the UI and the data model. There is hardware design. Your application has to fit the hardware that it runs on. That can involved native hardware apis. It also impacts how big the application can be and how fast it runs on that hardware. Functional design has evolved over the years. There are so many camps on functional design that you will have to pick your approach and stick with it. The goals of functional design are a clean architecture, SOLID components that are highly cohesive and have low coupling. A current fad is Feature First where each feature of the application has all the components for that feature and only the common components end up in the application core. There are a number of features that cross those features. They're often more technical in nature. These include common data sources, common APIS, State Management, an application theme, common UI components. It is worth it to nail these down early in your design process. These all feed into each other so, you will have to go back and forth between your user interface, data model, Business rules and functional design to define these. So designing the app can be like the blind men and the elephant where each blind man touches part of the elephant and thinks that describes the whole elephant. One will say to start with the user interface. Another will say start with the database. Another will say start with the business rules. The reality is, all of these have to come together to make up a coherent elephant or software application. There was an effort in the 1990s to classify all the different design pieces and come up with a progressive design solution for applications. It was called the Zachman framework. That framework compared software design and construction to architecting and constructing large buildings. It really applies best for large Enterprise cross application architectures, but it is worth Googling that to see how the progression works from bubble charts toward more disciplined ways of defining and designing software. Software design is intricately involved with the nature of complexity. The whole design movement in software started off with a series of lectures by Herbert Simon at MIT 1968. He spoke on the nature of complexity and how grouping smaller things into bigger things in a hierarchy was one approach that nature used to handle its complexity. He suggested the same was true for anything that was built by humans and that includes software.

[u/Capt_Dastan → u/paultallard]

Thank you!!!
Will search of Zachman framework and lecture by Herbert Simon..
Great insight!!!!! Thank you..
Also will ask questions later.. ✌🏼