What can be learned from studying long gone development practices? • Hacker News Board

Re: What can be learned from studying long gone development practices?

#11

Post by timoth3y » Sun, Aug 15, 2021, 10:06 PM UTC

The real value of studying outdated development methodologies is that it teaches you how to think about new problems. It will almost never give you a plug-and-play answer for a problem you are facing, but it will give you a new a useful way of looking at things.

Brooks wrote The Mythical Man Month in the 1970s about his experience in the 1960s and it is still extremely relevant today.

When I was starting my software development career in the mid 1990s and trying to understand how to manage the process, one of the things I did was write to NASA and request a copy of their Manager's Handbook on Software Development.

This was not because I wanted to run things like NASA. That would have been be horribly inappropriate for a startup dev team. However, I wanted to understand an extreme; a process where spec writing, testing and on time delivery were prioritized.

I never used anything directly from that NASA handbook, but I learned a lot.

Almost 30 years later, I still have that book. It's one of my little treasures.

Re: What can be learned from studying long gone development practices?

#12

Post by DrNuke » Sun, Aug 15, 2021, 10:12 PM UTC

The (still) relevant (best) practices from the past are all encapsulated into the standard libraries, that’s how CS pays its duties to the big minds of its past?

Re: What can be learned from studying long gone development practices?

#13

Post by anyfoo » Sun, Aug 15, 2021, 10:17 PM UTC

The article says:

> Today, structured programming appears remarkably simplistic, great for writing tiny programs (it has an academic pedigree), but not for anything larger than a thousand lines.

Curious. I rather think that structured programming became so ultra-pervasive in any high level programming language younger than 50 years old or so[1], that we've lost the extra name for it. Practically every programming language that isn't either pure functional (rarer than it seems), low level (i.e. assembly), or very very domain specific (e.g. SQL[2]) is a structural programming language.

Examples for "structural programming languages" are C, C++, C#, Java, JavaScript, python, Go, Swift, Scala, PHP, perl, Rust, D, ... You get the idea. If a general purpose language does not follow it, it's something notable, like Haskell.

So rather, I think this is an example of something that was so utterly successful that it became absorbed into the general fabric of mainstream programming. It's true that we don't draw as many flowcharts as we used to, because we got more comfortable with everyday programming, but they are still how we think about code a lot, and for complex processes that we want to visualize we still do draw them.

[1] Not a scientific estimate. Substitute "not very very old" if you like.

[2] Funnily that stands for "Structured Query Language", but not necessarily for significant reason: https://en.wikipedia.org/wiki/SQL#History

Re: What can be learned from studying long gone development practices?

#14

Post by canadev » Sun, Aug 15, 2021, 10:18 PM UTC

Lots of development practices come back again. E.g. techniques for optimizing code for computers sometimes make a resurgence for mobile phones a decade later.

Re: What can be learned from studying long gone development practices?

#15

Post by walshemj » Sun, Aug 15, 2021, 10:19 PM UTC

johnaspden wrote: post #10

I'm not sure you can call structured programming a fad! An awful lot of languages (I'd say all commonly used ones) use if/then/else, do..while, for..next, and so on, but I can't remember the last time I saw a program with a complicated control flow done by gotos. Such things were common in the 1970s, in fact the first professional program I ever read did it that way, and it took me ages to work out what was going on.…

Originally Fortran only had arithmetic if's

And I agree by the 70's spaghetti code with goto's was on the way out - though some early GWBASIC code had some gnarly practices.

Re: What can be learned from studying long gone development practices?

#16

Post by yourapostasy » Sun, Aug 15, 2021, 10:22 PM UTC

timoth3y wrote: post #11

The real value of studying outdated development methodologies is that it teaches you how to think about new problems. It will almost never give you a plug-and-play answer for a problem you are facing, but it will give you a new a useful way of looking at things. Brooks wrote The Mythical Man Month in the 1970s about his experience in the 1960s and it is still extremely relevant today. When I was starting my software…

For those wondering, there is the original handbook [1] available online today. Also an interesting paper on the process improvement lessons learned applying much of what was expressed in the handbook [2]. I believe the paper is of more immediate TL;DR use today for those who do not have the time to digest the handbook and internalize the lessons to draw from it.

[1] https://everythingcomputerscience.com/books/nasa-manage.pdf

[2] http://www.cs.umd.edu/projects/SoftEng/ESEG/papers/83.88.pdf

Re: What can be learned from studying long gone development practices?

#17

Post by timoth3y » Sun, Aug 15, 2021, 10:29 PM UTC

yourapostasy wrote: post #16

timoth3y wrote: post #11

The real value of studying outdated development methodologies is that it teaches you how to think about new problems. It will almost never give you a plug-and-play answer for a problem you are facing, but it will give you a new a useful way of looking at things. Brooks wrote The Mythical Man Month in the 1970s about his experience in the 1960s and it is still extremely relevant today. When I was starting my software…

For those wondering, there is the original handbook [1] available online today. Also an interesting paper on the process improvement lessons learned applying much of what was expressed in the handbook [2]. I believe the paper is of more immediate TL;DR use today for those who do not have the time to digest the handbook and internalize the lessons to draw from it. [1] https://everythingcomputerscience.com/books/nasa-m…

That's the one! Thank you for posting the link and the lessons learned. That looks like a great article.

In the 90s it took a (very friendly) FOIA request, a $5 processing fee, and three weeks to get my hands on that handbook.

Re: What can be learned from studying long gone development practices?

#18

Post by anyfoo » Sun, Aug 15, 2021, 10:30 PM UTC

ardit33 wrote: post #5

ptsneves wrote: post #2

Very shallow article. Tl;dr: none. I would say that the mythical man month concept has stayed and still is talked about today even though the book itself is also hopelessly outdated except maybe in IBM style enterprise software.

It was actually an interesting read. TLDR: Whatever software building methodology/process you are using now, is probably crap, and made up by people that don't really know any better and just making things on the go. Eg. He mentioned 'structured programing' was a fad at the time. Now it is Agile, and its offshoots. Best way to deliver software is to have a handful of capable people and pay them well and get out of th…

"Structured programming" was 100% successful, and we're all still using it, all the time. It was so successful, that we don't even talk about it anymore. With few exceptions, it's just how programming is now.

Does not invalidate your actual point, though.

Re: What can be learned from studying long gone development practices?

#19

Post by secondcoming » Sun, Aug 15, 2021, 11:02 PM UTC

timoth3y wrote: post #11

The real value of studying outdated development methodologies is that it teaches you how to think about new problems. It will almost never give you a plug-and-play answer for a problem you are facing, but it will give you a new a useful way of looking at things. Brooks wrote The Mythical Man Month in the 1970s about his experience in the 1960s and it is still extremely relevant today. When I was starting my software…

Was that book about the Capability Maturity Model? [0]

[0] https://en.wikipedia.org/wiki/Capability_Maturity_Model

Re: What can be learned from studying long gone development practices?

#20

Post by ufo » Sun, Aug 15, 2021, 11:31 PM UTC

walshemj wrote: post #15

johnaspden wrote: post #10

I'm not sure you can call structured programming a fad! An awful lot of languages (I'd say all commonly used ones) use if/then/else, do..while, for..next, and so on, but I can't remember the last time I saw a program with a complicated control flow done by gotos. Such things were common in the 1970s, in fact the first professional program I ever read did it that way, and it took me ages to work out what was going on.…

Originally Fortran only had arithmetic if's And I agree by the 70's spaghetti code with goto's was on the way out - though some early GWBASIC code had some gnarly practices.

The arithmetic if might be one of the best examples of how structured programming has become the new standard.

In 1960, it was the only way to do "if" in the most popular programming language that existed at the time. Today, I bet that most programmers haven't even heard of it.