It sounds a bit like the Waterfall model. It became highly unfashionable in the 90s, maybe even earlier.

It's really more of a proto-agile approach! I've never done the manual first personally, though I had a boss that had been on a project run that way early in his career who always wanted to do things that way again. The idea is to skip distilling requirements into specifications, engineering documentation, and user documentation. Instead you gather requirements AS user documentation, and only work backwards from there as necessary. Sort of like skipping all the specifications to V&V activities in a traditional systems engineering approach by writing tests first in test-driven-development.

My comparison to waterfall was a reductionistic take on the specifications up-front before coding starts aspect. If comparing it to the full waterfall process then it is definitely a fresh take!

This is pretty much how we were taught in college 15 years ago.

Actually implementing something is left to the final 30% of a project. One must first bore themselves to death with design and documentation before a single line of code is written.

And then discover that the entire foundation of the design can't work because of some critical logical flaw you didn't think about...

Something I missed above is that either prior, or concurrently, there will be performance experiments to check that things are staying sane, but these do not contribute to the later software development (except as a reference) and are likely not consistent with each other. The deliverable at this point is only documentation - getting it good as possible without any concern for impact on existing implementation. The goal is to get as far up the slippery pole as possible - inevitably things will slide back over future version iterations.

That describes most software design and development to a T. The reality is you'll hardly ever get the design right the first time around.

Yep - It was a pretty flawed methodology all told.

It's only flawed for beginners. With 10 years or more of experience, it's possible to design successfully based on that experience.

It is flawed for (otherwise) veterans too if they are trying to do something that they haven't done before so do not know what they do not know.

This really only works if you have done the same or something very very similar before and so you have practically no unknowns. Notice that the developer who did that commented above that they had already done similar work at the past.

Also related this quote about how Joe Armstrong (of Erlang fame) approached problems (from [0]):

> Joe wrote amazingly simple programs and he did so in a peculiar way. First he wrote down the program any old way just to get it out of his head. Then once it worked he would then immediately create a new directory program2 and write it again. He would repeat this process five or six times (program5, program6, ...) and each time he would understand the problem a little better and sense which parts of the program were essential enough to re-type. He thought this was the most natural thing in the world: of course you throw away the first few implementations, you didn't understand the problem when you wrote those!

[0] https://github.com/lukego/blog/issues/32

Sure if you're writing a similar program to one you've already written. But then it's just agile on a longer time scale!

I mean, it's not really an amazing skill in my opinion. What's amazing about writing a high level explanation of how your program works, maybe with a few simple diagrams to show the reasoning behind it, and then writing a more detailed specification of what the program should do? It's basically a more comprehensive version of first writing the flow chart of your program in pseudocode with attached comments and then implementing it.

It's easy to do it, but I have never really heard of anyone doing it successfully like this. Most programmers come up with a basic plan and then just start coding it and things evolve from there. As the saying going, "a battle plan never survives contact with the enemy."

I'm incredibly impressed with programmers that can visualize a large program and the end product actually resembles what they originally envisioned. That is a gift.

Can that really happen with Agile, which means requirements can change or new requirements can come in at any time?

You'd still start off with requirements - documentation - code, it's just on the understanding that any of these can change.

Sure, why not. Just change the documentation first.