[HN Gopher] What can be learned from studying long gone developm...
___________________________________________________________________
What can be learned from studying long gone development practices?
Author : Hell_World
Score : 58 points
Date : 2021-08-15 19:46 UTC (3 hours ago)
(HTM) web link (shape-of-code.coding-guidelines.com)
(TXT) w3m dump (shape-of-code.coding-guidelines.com)
| anyfoo wrote:
| 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 you think), low level (i.e. assembly), or
| very very domain specific (e.g. SQL) 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
| utterly successful, being 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.
| canadev wrote:
| 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.
| marcodiego wrote:
| You'll probably learn more by trying to understand why these
| practices are long gone.
| johnaspden wrote:
| 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.
|
| One particularly confusing technique was to goto a computed
| expression. Leads to all sorts of interesting bugs.
|
| The whole point of structured programming was "Don't do that! You
| can do everything you want to do with a small set of restricted
| control structures, and the control flow is much easier to read".
|
| I'd say that idea won so hard that we don't even notice it.
| walshemj wrote:
| 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.
| galaxyLogic wrote:
| It is possible to produce software of great quality if you are
| willing to spend a lot of money on it. And if you want to build
| big system good quality is a necessity. Else you will discover
| like IBM did early on that fixing one bug on average can create
| 1.2 new bugs, or something like that.
|
| The issue is that often the quality is good enough to have
| something that works and then the buyer/payer does not want to
| spend more. Problem with that is it makes the maintenance and
| future adaptations expensive and can turn the system into one
| where fixing one bug creates 1.2 new bugs.
|
| Therefore I think it is wise to err on the side of caution and
| spend more on software quality than seems to be needed
| immediately. It is a bit like in the early days of bridge-
| building the bridges needed to be built stronger than needed
| because it was not possible to calculate the safety margins
| accurately.
| azta6521 wrote:
| Yes and no. I'm too amazed by a world which longs for so many
| software developers. I mean do they all know that all that
| software has to be maintained? That software is one of the most
| expensive human artifacts today and that software rots like
| hell?
| timoth3y wrote:
| 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 usefully way of looking
| at tings.
|
| Brooks wrote The Mythical Man Month in the 1970's about his
| experience in the 1960's 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.
| yourapostasy wrote:
| 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
| timoth3y wrote:
| 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.
| ptsneves wrote:
| 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.
| ardit33 wrote:
| 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 their way. The key to
| get paid well as a dev. is to be in a project that is
| important, life/death for the company.
|
| I think the most interesting part of the article was the early
| job divisions while building software. It didn't make sense,
| but it was adopted due to the coorporate culture of the time.
| martininmelb wrote:
| > Best way to deliver software is to have a handful of
| capable people and pay them well and get out of their way.
|
| That is the gist of one of the essays in The Mythical Man
| Month mentioned in the parent.
| anyfoo wrote:
| "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.
| Lapsa wrote:
| stopped reading at "when I wrote my book"
| mavelikara wrote:
| > even though the book itself is also hopelessly outdated
|
| What parts did you find dated? I haven't read it in the last
| few years, but I still get reminded of concepts like Second
| System Effect every once in a while.
| DrNuke wrote:
| 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?
___________________________________________________________________
(page generated 2021-08-15 23:00 UTC)