3 ms·

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 them

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.

IshKebab 4y ago
And then discover that the entire foundation of the design can't work because of some critical logical flaw you didn't think about...
- jussij 4y ago
  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.
- swarnie 4y ago
  Yep - It was a pretty flawed methodology all told.
  - nitrogen 4y ago
    It's only flawed for beginners. With 10 years or more of experience, it's possible to design successfully based on that experience.
    - badsectoracula 4y ago
      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 https://github.com/lukego/blog/issues/32
    - IshKebab 4y ago
      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!
- samlittlewood 4y ago
  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.

IshKebab 4y ago

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

jussij 4y ago
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.
swarnie 4y ago
Yep - It was a pretty flawed methodology all told.
- nitrogen 4y ago
  It's only flawed for beginners. With 10 years or more of experience, it's possible to design successfully based on that experience.
  - badsectoracula 4y ago
    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 https://github.com/lukego/blog/issues/32
  - IshKebab 4y ago
    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!
samlittlewood 4y ago
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.