5 ms·

This is an amazing, amazing skill. Do any university classes teach programmers how to think like this? Can it be taught?

by magpi3 4y ago

dranka 4y ago
It sounds a bit like the Waterfall model. It became highly unfashionable in the 90s, maybe even earlier.
- buescher 4y ago
  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.
  - dranka 4y ago
    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!
llampx 4y ago
Can that really happen with Agile, which means requirements can change or new requirements can come in at any time?
- OwlsParlay 4y ago
  You'd still start off with requirements - documentation - code, it's just on the understanding that any of these can change.
- withinboredom 4y ago
  Sure, why not. Just change the documentation first.
swarnie 4y ago
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
HidyBush 4y ago
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.
- magpi3 4y ago
  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.

This is an amazing, amazing skill. Do any university classes teach programmers how to think like this? Can it be taught?

by magpi3 4y ago

This is an amazing, amazing skill. Do any university classes teach programmers how to think like this? Can it be taught?

dranka 4y ago

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

buescher 4y ago
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.
- dranka 4y ago
  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!

llampx 4y ago

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

OwlsParlay 4y ago
You'd still start off with requirements - documentation - code, it's just on the understanding that any of these can change.
withinboredom 4y ago
Sure, why not. Just change the documentation first.

swarnie 4y ago

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

HidyBush 4y ago

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.

magpi3 4y ago
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.