[appleiigs]

I had a boss who had a math degree. He'd map out the flow from start to finish on a whiteboard like you see mathematicians on TV/movies. Always had the smoothest projects because he could foresee problems way in advance. If there was a problem or uncertainty identified, we'd just model that part. Then go back to whiteboard and continue.

An analogy is planning a road trip with a map. The way design docs most are built now, it shows the path and you start driving. Whereas my bosses whiteboard maps "over-planned" where you'd stop for fuel, attraction hours, docs required to cross border, budget $ for everything, emergency kit, Plan A, Plan B.

Super tedious, but way better than using throwaway code. Not over-planning feels lazy to me now

Sure, everyone has a plan until you get punched in the mouth; however, that saying applies to war, politics, negotiations, but not coding.

[jnsaff2]

I the book How Big Things Get Done they analyze big and small project failures and success and end up with something along the lines:

1. Spend as much time in planning as necessary, in the context of mega projects planning is essentially free, maximize the time and value gained in planning.

2. Once you start execution of the plan, move as fast as possible to reduce likelihood of unforeseen events and also reduce costs increases due to inflation, interest paid on capital etc.

[0] https://www.goodreads.com/book/show/61327449-how-big-things-...

[SaltyBackendGuy]

+1 for "How Big Things Get Done". It changed the way I run projects. I got lucky in the sense that I was able to convince my corporate overloads to allow us to have separate Discovery and Delivery goals, on the premise that discovery is cheap and delivery is expensive (the former significantly reduces risk of the latter) and we show our work. Discovery goals come with prototype deliverables that we're ok not shipping to production but most times lay the foundational work to ship the final product. Every single time we've found something that challenged our initial assumptions and we now catch these issues early instead of in the delivery phase.

We've fully embraced the "Try, Learn, Repeat" philosophy.

[huijzer]

Yes I have to second that. MLJ.jl is also written by a mathematician and the API is excellent. Truly well thought-out.

(If you think “why does MLJ.jl have so few stars?” please keep in mind that this library was written for the Julia language and not for Python. I honestly don’t think the library is the cause of low popularity. Just wrong place wrong time.)

[ozim]

First you have to have smart people who will be able to foresee design issues.

That’s a bit uncharitable but following this line of thought - you also need those smart people to be confident and communicative.

[marcosdumay]

And for them to be listened to, what is independent on how well they communicate; and for them to be aligned with the most powerful stakeholder, what is almost never the case; and for no big change to happen in an uncontrolled way, what powerful people nowadays seem intent on causing all the time.

[sevensor]

> however, that saying applies to war, politics, negotiations

It’s not even an argument against planning. You’d be a fool to go to war without a plan. The point of the saying is that you’d be a fool not to tear up your plan and start improvising as soon as it stops working.

[zmgsabst]

To borrow another quote:

Plans are nothing, but planning is everything.

The process of building a plan builds the institutional knowledge you need to iterate when inevitably the original plan doesn’t work.

[dbsmith83]

It is kind of an argument against overplanning though, because if your plan that you spent considerable time creating becomes irrelevant, you wasted a lot of time

[DidYaWipe]

I had to do this for a patent application, and likewise found it very useful for identifying holes in my thought process or simply forcing myself to do the functional design work up-front and completely.

It was also great for brainstorming about every feature and functional aspect you can imagine for your product, and making an effort to accommodate it in your design even if it's not MVP material.

[bayarearefugee]

> but not coding.

In my experience it applies to coding when you have any reliance on third party libraries or services and don't have an extensive amount of actual real world experience with that technology already.

[jyounker]

If you have unknowns, then your planning process starts with, "let's figure out how to use this new technology." And that process can involve a bunch of prototyping.

Having to make a choice between "make a design document" or "do prototyping" is a false dichotomy. They're complimentary approaches.

[bryanrasmussen]

>Sure, everyone has a plan until you get punched in the mouth; however, that saying applies to war, politics, negotiations, but not coding.

hey, the EU just introduced this new regulation is the software version of getting punched in the mouth.

[lmm]

> Super tedious, but way better than using throwaway code. Not over-planning feels lazy to me now

How was it better? I think a lot of people plan precisely because it feels virtuous, but that's true regardless of whether it's effective or not.

[appleiigs]

My boss would take a piece of data/input and run it through the entire process. It's a string data here, converts to number here, function transforms it here, summarized here, output format there... You wouldn't run into data type issues or have an epiphany that you're missing a data requirement.

[PittleyDunkin]

> Super tedious, but way better than using throwaway code. Not over-planning feels lazy to me now

Certain projects have too many unknowns to overplan and you need to collect data to construct the assumptions necessary to evaluate the approach.

[bravetraveler]

Man plans and executives laugh