Reading the NATO report on software engineering that came out of the 1968 conference where the term "software crisis" was coined. (It's at https://www.scrummanager.com/files/nato1968e.pdf if you want to read it too.)
Currently on page 11. ELEVEN. (Out of 200+.) It says right here: "The need for feedback was stressed many times."
We knew. Have always known. Feedback is the key to everything. Any process that intentionally delays feedback is going to run into problems. We took such a wrong turn in the 1990s. Ugh.
=> More informations about this toot | More toots from testobsessed@ruby.social
Now reading Randell's 1979 comments on the 1968 report (https://dl.acm.org/doi/pdf/10.5555/800091.802915). He quotes J.W. Smith:
"I'm still bemused by the way they attempt to build software... They begin with planning specification, go through functional specifications, implementation specifications, etc., etc. If you look down the PERT-chart you discover that all the nodes on it up until the last one produce nothing but paper. It is unfortunately true that people confuse the menu with the meal."
(edited for brevity)
=> More informations about this toot | More toots from testobsessed@ruby.social
"Don't confuse the menu with the meal" is my new favorite phrase.
=> More informations about this toot | More toots from testobsessed@ruby.social
Back to the 1968 report. SO MANY GOOD QUOTES. Gonna thread a few of my favs.
"Today we tend to go on for years, with tremendous investments to find that the system, which was not well understood to start with, does not work as anticipated. We build systems like the Wright brothers built airplanes — build the whole thing, push it off the cliff, let it crash, and start over again." -- Graham
=> More informations about this toot | More toots from testobsessed@ruby.social
"I know of one organisation that attempts to apply time and motion standards to the output of programmers. They judge a programmer by the amount of code he produces. This is guaranteed to produce insipid code — code which does the right thing but which is twice as long as necessary." -- McClure
=> More informations about this toot | More toots from testobsessed@ruby.social
“There are two classes of system designers. The first, if given five problems will solve them one at a time. The second will come back and announce that these aren’t the real problems, and will eventually propose a solution to the single problem which underlies the original five. This is the ‘system type’ who is great during the initial stages of a design project. However, you had better get rid of him after the first six months if you want to get a working system.” — Kinslow
=> More informations about this toot | More toots from testobsessed@ruby.social
@testobsessed ooh, I definitely know that guy
=> More informations about this toot | More toots from aburka@hachyderm.io
@aburka @testobsessed yea, it's me. Going to have a rethink of my life now....
=> More informations about this toot | More toots from arichtman@eigenmagic.net
@arichtman @aburka So I should probably have injected my opinion on that quote. I disagree with the author. If I'm hiring and have just the 2 candidates, I'll take the second type over the first...but what I really want is a 3rd type who will start like the first, then see the pattern (rule of 3) and only then refactor to solve the real single underlying problem. I've seen the code bases produced by the 1st approach with no opportunity for extracting the common logic, and...well...shudder.
=> More informations about this toot | More toots from testobsessed@ruby.social
@testobsessed @arichtman yeah the switch hitter here can be the mvp
=> More informations about this toot | More toots from aburka@hachyderm.io
@aburka @testobsessed "...so you're saying there's a chance?"
=> More informations about this toot | More toots from arichtman@eigenmagic.net This content has been proxied by September (3851b).Proxy Information
text/gemini