How do I plan out my software development projects (talks about agile development)

agile good, for the most part

My VSCode Extensions:
- theme: material community high contrast
- fonts: Menlo, Monaco, 'Courier New', monospace
- errors: Error Lens
- extra git help: Git Lens
- tailwind css intellisense
- indent rainbow
- material icon theme
- prettier & eslint
- ES7+ React Snippets

[laszloekovacs]

I've on-off programmed as a hobby in the last 22 years and maybe managed to finish 2-3 projects. I wish there were more material on how to plan out projects.

[igor]

Hey man, just seen a few videos of yours and just wanted to thank you for them, just loads of value and insights I haven't seen elsewhere, great work :)

[Tyrone-Ward]

I think the "just code it" method is good if you know what you're doing, but if you're just learning, the flowchart method seems to work best.

[BarisPalabiyik]

Totally agree, I use user stories and ship the necessary steps as soon as possible. Move fast, break fast mindset is how many got ahead at the time.

[armandoleon]

Something I’ve recently learned is that a design you come up with is not the final one. Things change, requirements change, etc. for example, I learned about db migrations. I thought I had to have everything thought out for the db design, but thanks to db migrations, I can have the bare minimum or essentials in my design and use tooling to evolve its design as I build more features on the front and backend.

[chamsseddin]

Actionly, i love so much this type of content, Thanks bro

[markivkovic]

Love this. I'm always second guessing my build layout / structures etc. Especially if it's full stack.

[yousafwazir]

I agree but the diagram way is taught heavily in degrees. In mine they don’t even care about the code and care more about the diagrams

[brucewayne]

For me it's event storming (it gives you all the queries and mutations) the wireframe it gives you a whole idea about the app and the design + the bpmn process

[saliexplore]

I think just code and iterate makes sense when adding features to a an existing software system. Doing "some" planning is important if it's a new system you're building.

[sul-dev]

This video is so good. Has so much good info.

[leojohn]

Is it possible to create a video about this process in more detail please? I am actually this type which create a very large diagram every single time I create a project. For me, the problem of getting slowly futures to the specific project, is that sometime I forget which primary key will be in what table. It’s just an example.

[roddyib]

TBH, I think is base on your mindstructure, for me is really easy to creat big workflows and diagrams in a day. It's a good starting point to show what we will need. The mistake is more a mindset, to stick with the diagram, which is only a general guideline of what is needed. Building in isolated block based on what the user needs it's also a challenge and could be a deadend alley if the big picture is not clear. You can start building great walls and a beautiful door, buy you always need an idea of the project.

[DzintarsDev]

In most cases, you can just sit down and implement a feature. If you are working on a cat pic app. But... as soon as you go into realm of enterprise apps, like WMS, ERPs, etc... you just CAN'T sit down and implement. You really need to draw those ULMs to see all the entity interactions so that you don't create wrong behaving features. It all just depends on the context in which you are working. Imagine nuclear power plant which is operated by "just sit down and implement a feature" software... :)
But it's also true that you need to get UI tested quickly on a real users. It might not change the underlying structure or logic, ... so it is important to get UI ergonomic and you can test it just by shipping quickly. End users don't care much about the implementation. They care if the feature is easy to use. And... if you draw UMLs... get the right primitives, entities and what not... then later it's quite easy to just shift things around. But if you have no clear picture... and you "just implement" any feature with its business logic... I can guarantee... things will get messy. And imagine... your service is used by B2B customers... They will get mad at you! If those are just regular users and you messed up their cat pic gallery... who cares. You might loose some users, but... meh. But business customers are SUPER sensitive to any kind of mess up.
Context matters!

[judejeevanmahendran]

wow! I have been searching these kind of videos for long, Thank you for making this video! please make a video on "the process of developing a software" I mean, I want to see how the SDLC is executed and what problems might a developer face and everything. I wanted to see the whole process of making a software. from UI/UX design and everything, I don't know how to explain, I am just an amateur.

[dueft]

I totally aggree with your points. I recently caught myself overengineering in my project and now I always have to tell myself that if sth. is needed in the future, I'll implement it and don't need to care about it rn.

Doesn't mean the features shouldn't be thought through!
And a rough plan always helps - but that's it.

[mzfitness]

Love your content! Question, how do the code refactoring projects get picked? I recently finished a mern stack app with redux and I’m curious how to make it better and cleaner. Is there somewhere I can send it for consideration?

[noahwinslow]

I find the mocks annoying because I'm never the one making them, in my job I've had management make the mocks but management doesn't know how to code so it's like, do we build to your mock that you wasted three hours on or do we do mvp and iterate as needed?

[bndissanayaka]

As much as I appreciate the effort you ppl put into create these videos it is good if you can add a description something like TLDR; or separate the video into sections on timestamps so we can easily grab the overall idea of the content. Thank you 🙂

[--Arthur]

Being agile alone is worthwhile. I like the flow of 50% of work is producing it the other 50% goes to cleaning, documenting, testing.

However if you work with others, you have to be able to communicating strategies, ideas, flows. And truth be told, if you only stick to an "agile" mindset, you won't practice the communicational part of a job.

The good approach depends on your goals. For very small projects. Just smack some code.
For medium or large projects - consider maintainability as a priority. Coding in the long run is 80% reading and 20% writing. (A scaffolding/prototype project is a small project on its own where testing the idea should come as quickly as you can reasonably manage)