I just discovered the power of planning before coding.

Wheew.

Welcome to the Planning-Zooone ^^

@TylerDDevRant Softarch <3

How do you usually code?

@billgates probably winging it as the project develops

On this subject though, are there any good techniques, frameworks, views or standards you use to plan the software architecture?

.... Or just lash together a few UML views into a Word document?

Can you tell me what exactly do you do, because I have troubles with this too..

@ozelentsov google

Merise, uml, prince2, rtfm
=D

@gnulinuxer4fun lol, don't you mean WTFM??

@nzeetee (as in WRITE The F-ing Manual)!

@ozelentsov

Make a list of requirements. Split list into granular tasks. Tiny tasks!

Try to describe what is necessary for each tiny task ("add column x to database", "install package for parsing dates", "create post route", "add validation class for field x").

Take a big marker. Highlight all problematic steps, things like "I don't know which package is best for parsing dates" or "what text should be displayed if a user enters an invalid date".

Break up problematic points into "clarification" and "research".

Ask the product owner / client how they want to handle edge cases.

Research technical unknowns, but try to timebox your research — a quick test implementation is fine, but you are not building the feature yet!

You should end up with a list of steps, each of which feels like "Easy, I could do that in 5 minutes".

Get back to PO / client with that list of tinytasks, and explain to them in plain English what the purpose of each step is, how it affects the end result, and ask if that is in line with their initial expectations.

If you think a seemingly easy step is technically challenging, tell them about the risks of that specific requirement.

If a list of tinytasks is getting extremely long, try to remove bloat and "nice to haves" from the list. It's good to know future requirements, but deployments should be small and incremental.

Two additional points:

1. If you discover during development that requirements have changed, or that something is harder than expected, immediately communicate with the PO / client — don't wait with nasty surprises until an hour before the estimated due date.

2. If you work on a hobby project, you are your own client. Practice the whole planning & delivery cycle by literally pretending to be two persons. Talk to yourself, present to yourself, ask yourself questions.

I can tell ya, it can be painful but in the end it's worth it

@bittersweet thank you very much, this is now clear to me!

@bittersweet sounds so easy and I am teaching that to my team members all the time! but somehow they cannot follow those few small rules.. is that really so hard to do?

I mean: Even at home you write a list of items you have to buy, then you buy all that stuff at once. You will not go to the grocery store repetitively just because you forgot that a dessert needs sugar and you haven't had it on your list. Then when you come back home, you remember that your dessert need some fresh fruits as well and you go back to buy it. And after that you remember at home that you need another thing and so on. That is not how it works!

Sometimes I have the feeling that people are just lazy at work. They take the money and are doing what they like to do, but they do not think about what they had to do. It is simply not professional when thinking is not part of the daily business!

Thanks for the reminder 🤝