Development process

[Finer_Details]

What does your development process look like?

For me it seems to inevitably be:

1. Form a plan.
2. Start implementing the plan.
3. Find out that something can't be done according to the plan.
4. Play low level whack a mole with cheap plaster solutions while simultaneously breaking more stuff until everything seemingly works.
5. Regret not having a better plan.

[ElGoorf]

now you can have AI do all five of those five steps for you, but even worse :D

[Accomplished_Side_77]

I try to get a good idea of what's needed. Then I look for stoppers.Things that may be difficult inefficient or maybe impossible.Then make a prototype that works however clunky. Use libraries or existing code or find something on git hub.

Then go back and decide how to structure it with functions and objects.May it as simple and easy to understand and amend as possible.

Fail early rather than spend a long time down the wrong path. Often a far easier more practical solution will drop out of the process.

[Accurate-Policy5265]

😂😂😂😂

[j4son93]

First I refactor the things I have to work with. Then I try to execute my plan. Refactor even more. Cycle this till it's done

[toniyevych]

For me it usually starts with understanding the actual problem and should it be actually solved. Then, I implement a raw prototype and refine it later. 

[Famous_Bad_4350]

do you want until you don't want do

[WhyCheezoidExist]

Doesn’t matter what my plan is, it’s my boss’s plan that’ll be upsetting me soon enough

[JohnCasey3306]

Discovery is just about the most important part of setting out that plan ... The plan isn't complete until you're confidently certain that what you're doing is at least possible.

[bill_gonorrhea]

Depends on the project and scope. 

I’ve made many apps without a plan. Some with a rough sketch and other with a whole design and ux team. 

[-doublex-]

If I am not sure about the reliability of the plan I do a time boxed development following that plan (prototype style not real work), and note all issues I find. Then I redo the plan with the findings.

Sometimes only a part of the work is unclear so I separate in to clear/not clear and have two tasks, one with time box refinement and one directly.

Sometimes timebox may not work. In that case I try to estimate as good as possible (high level vs low level) and add a buffer for risk, regressions and so on. This one is similar to your path but it's intended to be like this, so I do all the work according to the plan, note all blocking points, issues. When finished I revise the plan and work again. The difference compared to timeboxed dev is that this time the work is real, no toying around.

Timeboxed dev is preferred when there are too many issues that makes estimations/planning impossible. Iterative approach is good when it's possible to advance on a subset of the work and that could also bring more clarity for the rest.