Beginner here. I wanna go full stack, and I learn by doing (and not following a tutorial).. so i define a problem i want to solve, then i think what i need to do (logic) to solve it then i search how i accomplish that in the language i'm working
when i try to just start coding my idea there is a lot of back-and-forth because in the middle of the code i realize I should have done that in a different way..
I need to have an overview how things should work (a plan!) and not just start coding..
i tried mock ups, writing down a document explaining how software should works and have tried UML (actually just read about UML, found it boring so didnt tried it)
didnt liked any of this option (or they just dont work for me)
And im having this problem 'working' alone. i imagine how this can work in a team where two or more persons are coding different sw parts and these parts works together..
how do you plan software?
Top comments (4)
Here's how I plan an app, or system. In the initial design I try to stay away from UML or any computer type CAD program, I stick to drawing components on paper. List the requirements, list available libraries/frameworks. In the beginning think very broad without getting into the specifics of classes/methods/libraries. Think how major modules of your app will interact with each other.
The most important aspect of your app the core of it, can be designed first, and prototyped to see how well does it work, from there you expand in/out. Building piece by piece.
There might be back and forth as you wrote, and that is fine and can be dealt with when refactoring code.
As Juha-Matti Santala pointed out using user workflow can be very powerful to assist in what you need to implement in the code.
In the end don't overthink it too much, you have to have some sort of prototype to see what works and what doesn't. Designing just comes with experience as all things. Google is the best helper when trying to figure out patterns, and StackOverflow for specific questions don't be afraid to use those resources.
First of all, don't worry too much about that since you said you're a beginner. We've all been there before. That said, software planning or design is a step by step procedure and requires a bit of going back and forth. For me personally, I start by preparing a specifications document listing all the features my app needs. Then I tackle them feature by feature. For each feature, I first identify the classes I need to write in order to get a particular feature working. You can easily do that by translating the nouns that pop up in your specification document to classes. Note however that you may need to break down some classes down further. Then identify what each class has to do. You can then use UML to describe the relationship between the classes so you get a fair idea how the classes interact with each other. Develop the feature, test it to make sure it's working as intended. Move on to the next feature if you're satisfied with the result. Repeat the process for all features.
What kind of factors made you not like the options you tried (mockups, documentation, UML)?
I tend to design my software by crafting user stories. In a nutshell: As a I can , so that .
I don't start by thinking about the technology nor the architecture. I start by mapping out what my users do, how they feel at certain moments of the flow, what data is required to be present or saved or sent somewhere. After I have a good basic understanding of what the user journey for a particular feature or collection of features look like, I start with one of them.
Once I know roughly what I want to build and how I want it to work, I start thinking about the technology: Does this feature require a database? Does it work best as a mobile app, web app or an offline desktop app? Do I want to learn new tech for a side hobby project or do I need to take into account business decisions like getting stuff done fast and choosing tech that is easy for the client to keep maintaining on their own? And dozen of other things.
Early in my career I would focus way too much on the technical side and create things that had horrible user experience. So that's why I found that for me, starting with the user experience and their flow forces me to think that first and then fit the technology to serve that. Your mileage might vary.
The basis to all systems is there is some sort of desired output and some sort of available input. Finally there is some type of processing required to get from the inputs to the outputs.
This is how you should begin, before using any tools, making mockups, or anything else. OIP.
Output - list all desired outputs from the system
Input - list all available inputs
Processing - determine (at a high level) how you get to the outputs from the inputs. You should be working in "reverse" order. This is crucial as it will help determine if there are any unnecessary inputs on your list or if there are more required inputs you hadn't thought of
Once you have your OIP for the entire system, you can begin breaking the system into smaller chunks and re-perform the OIP assessment on each piece. Each piece should produce output required for another piece as its input.
Follow this design pattern with any tools that you can easily wrap your mind around. My personal favorite is pen and paper. When I feel like I have a pretty solid idea I will use something like draw.io to make it more permanent. Don't get stuck on any particular format (unless it is required by an employer) as long as it is easy enough to understand. Boxes and arrows go a long way.