Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What can be learned from studying long gone development practices?

shape-of-code.coding-guidelines.com

Post reply on HN
Print view View original

21–30 of 142 posts

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

#21

Post by bdavis__ »

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…

curious if anyone tracks software engineering metrics like this anymore? defects identified, defect fixed vs. time

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

#22

Post by ljm »

ufo wrote: post #20
walshemj wrote: post #15

Earlier quoted context omitted.

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.

Looks like arithmetic if is now just a comparator operator, like ``.

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

#23

Post by vincent-manis »

`Structured programming' is actually used to refer to two different things: reducing or eliminating the number of gotos, and top-down programming. The former is universally understood to be generally a good thing (though there are still some good uses for gotos); the latter was the fad. The 1970s was the time of HIPO (hierarchy/input/process/output) charts. An early-1980s research project I was acquainted with at the time had an iron-clad rule: each procedure must be in its own source file. At least one well-known book in the 1980s gave definitions of software quality metrics that made object-oriented designs bad.

Pretty much every SE methodology has been a fad when it claimed to be the One True Way, and has offered useful ways of solving a certain kind of problem.

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

#24

Post by Jtsummers »

bdavis__ wrote: post #21
yourapostasy wrote: post #16

Earlier quoted context omitted.

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…

curious if anyone tracks software engineering metrics like this anymore? defects identified, defect fixed vs. time

Yes. However, it's mostly in "maintenance" programming. Particularly in the way that DOD and safety critical systems are maintained.

It's both a reasonable and unreasonable concept. It's unreasonable because it tries to turn programming into factory work, in fact you may even see them set up workflows predicated on an assembly line concept. This kind of works, and why it's kind of reasonable, when the work is sufficiently well-understood. It's very common in these systems to have a very detailed specification. Often the defects are deviations from the specifications that got through because of the manner in which these were classically tested (primarily integration tests, often manual, necessarily restricting the scope of the testing regimen). Other defects are realizations that the specification itself has an issue (happens), often the result of a dependence on a prose format for the specification which doesn't lend itself well to formal analysis. It also tends to, well, become wordy. 1000 page specs are not unheard of even for relatively small systems, you can imagine there may be quite a few pieces of conflicting information in there.

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

#25

Post by kevin_thibedeau »

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.…

> I can't remember the last time I saw a program with a complicated control flow done by gotos.

I've run across this in C demo code for a chip designed within the last 10 years. It was all goto soup in a god function.

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

#26

Post by bitexploder »

kevin_thibedeau wrote: post #25
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.…

> I can't remember the last time I saw a program with a complicated control flow done by gotos. I've run across this in C demo code for a chip designed within the last 10 years. It was all goto soup in a god function.

Some embedded developers just never got the memo about control flow constructs. You can find some truly bizarre and concerning development practices in the embedded world.

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

#27

Post by aetherspawn »

> I think the best management technique for successfully developing a software system in the 1970s and 1980s (and perhaps in the following decades), is based on being lucky enough to have a few very capable people, and then providing them with what is needed to get the job done

> There is one technique for producing a software system that rarely gets mentioned: keep paying for development until something good enough is delivered.

Highlights.

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

#28

Post by lugged »

bitexploder wrote: post #26
kevin_thibedeau wrote: post #25

Earlier quoted context omitted.

> I can't remember the last time I saw a program with a complicated control flow done by gotos. I've run across this in C demo code for a chip designed within the last 10 years. It was all goto soup in a god function.

Some embedded developers just never got the memo about control flow constructs. You can find some truly bizarre and concerning development practices in the embedded world.

I think it's a symptom of the field. A lot of arduino code is ghastly but mostly comes down to hardware people coding things for the first time and having zero professional development experience or formal education.

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

#29

Post by lisper »

kevin_thibedeau wrote: post #25
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.…

> I can't remember the last time I saw a program with a complicated control flow done by gotos. I've run across this in C demo code for a chip designed within the last 10 years. It was all goto soup in a god function.

The problem with C is that it doesn't have proper tail recursion, so if you want to use C as a target language for something that does have proper tail recursion, you pretty much have no choice but to make goto soup.

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

#30

Post by ufo »

lisper wrote: post #29
kevin_thibedeau wrote: post #25

Earlier quoted context omitted.

> I can't remember the last time I saw a program with a complicated control flow done by gotos. I've run across this in C demo code for a chip designed within the last 10 years. It was all goto soup in a god function.

The problem with C is that it doesn't have proper tail recursion, so if you want to use C as a target language for something that does have proper tail recursion, you pretty much have no choice but to make goto soup.

The C standard doesn't mandate tail-call optimization, but at least GCC and Clang are pretty good at doing it (-foptimize-sibling-calls, which is turned on with -O2)
Post reply on HN