The document discusses the agile practices of 1960s programmers, noting that they wrote whole operating systems and applications from just a handful of machine instructions (the "MVP"). Programmers in this era understood principles now considered agile such as writing their own domain-specific languages, keeping software simple, and avoiding speculation. They were able to port code between different machines and achieve agility even with computers that had only a few kilobytes of memory and storage. The summary questions who now considers today's software to be heavyweight, slow, and clunky in comparison.

1. Moore For Less
Agile Wisdom from the 1960s
Frank Carver http://frankcarver.me/

2. What do you think of when I mention
the 1960s?

3. What do you think of when I mention
the 1960s?

4. What about computer technology of
the 1960s?

5. What about computer technology of
the 1960s?

6. Plenty of words to use…
How about:
Heavyweight
Slow
Clunky

7. So what about computer software of
the 1960s?

8. So what about computer software of
the 1960s?
FORTRAN COBOL

9. So what about computer software of
the 1960s?
Looks like the software of the1960s was just like the hardware:
heavyweight,
slow,
and clunky.

10. Oh no it wasn’t!
John McCarthy
Father of LISP

11. Oh no it wasn’t!
Ken Iverson
Inventor of APL

12. Oh no it wasn’t!
Charles Moore
Creator of FORTH

13. “The first versions of APL360 took control of the entire
machine. It was thus a combination operating system, file
system, timesharing monitor, command interpreter, and
programming language. Given the limited main memory,
user workspaces were swapped out to drum or disk as
needed.
Performance was impressive, which Larry Breed
attributes, in his clear and succinct description of the
implementation, to the ability to tailor the operating
system to the requirements of the language.”

14. Charles Moore on…
Domain Specific Languages,
User Centred Software,
Mentoring …
“We shall be less interested in computer language than most programmers. For 3
reasons: First, we will eventually define our own application-oriented language.
How we implement that language is of lesser concern. Second, you probably aren't
in a position to pick a language. Your installation probably has reduced your
choice to nil. Third, we won't be talking about problems at the language level.
This last comment deserves elaboration. I assume that you are already a competent
programmer. I'm not interested in teaching you how a computer works, or how a
language conceals the computer. I want to talk about problems common to all
programs in a machine-independent and language-independent manner. I will leave
to you the details of implementation. I am not going to write a program, I am going
to show you how to write a program.”

15. Charles Moore on…
Simplicity
“A computer can do anything. ... A computer cannot do everything. But most important, with
only you and I to program it, a computer can not even do very much. This is of the nature of
an empirical discovery. So to offer guidance when the trade-offs become obscure, I am going
to define the Basic Principle:
Keep it Simple
As the number of capabilities you add to a program increases, the complexity of the program
increases exponentially. The problem of maintaining compatibility among these capabilities,
to say nothing of some sort of internal consistency in the program, can easily get out of hand.
You can avoid this if you apply the Basic Principle. You may be acquainted with an operating
system that ignored the Basic Principle.
It is very hard to apply. All the pressures, internal and external, conspire to add features to
your program. After all, it only takes a half-dozen instructions; so why not? The only
opposing pressure is the Basic Principle, and if you ignore it, there is no opposing pressure.”

16. Charles Moore on…
“You Aint Gonna Need It” (YAGNI)
“The Basic Principle has a corollary:
Do Not Speculate!
Do not put code in your program that might be used. Do not leave hooks on which
you can hang extensions. The things you might want to do are infinite; that means
that each one has 0 probability of realization. If you need an extension later, you
can code it later - and probably do a better job than if you did it now. And if
someone else adds the extension, will they notice the hooks you left? Will you
document that aspect of your program?”

17. Charles Moore on…
10,000 Hours,
Software Craftsmanship,
Code Kata …
“The Basic Principle has another corollary:
Do It Yourself!
Now we get down to the nitty-gritty. This is our first clash with the establishment.
The conventional approach, enforced to a greater or lesser extent, is that you shall
use a standard subroutine. I say that you should write your own subroutines.
Before you can write your own subroutine, you have to know how. This means, to
be practical, that you have written it before; which makes it difficult to get started.
But give it a try.
After writing the same subroutine a dozen times on as many computers and
languages, you'll be pretty good at it. If you don't plan to be programming that
long, you won't be interested in this book.”

18. Charles Moore on…
Portability,
Factoring,
Don’t Repeat Yourself (DRY),
Machine Sympathy …
“Don't try for platform portability.
Most platform differences concern hardware interfaces. These are intrinsically
different. Any attempt to make them appear the same achieves the lowest common
denominator. That is, ignores the features that made the hardware attractive in the
first place.
Achieve portability by factoring out code that is identical. Accept that different
systems will be different.”

19. “First an exercise. Initialize the interrupt locations in such a way that the computer
will run, will execute an endless loop, when you start it. OK? Then modify your
loop so that it will clear memory. OK? You've probably learned a lot.
Now we're going to start for real. We're going to start building your dictionary,
even though you can't use it yet. You must choose your entry format now; variable-
sized entries are required, but you can decide about word-size and layout. The first
entry is SAVE; it will save your program on disk. Lacking a control loop you'll
have to jump to it manually, but at least you can minimize re-doing a lot of work.
The second entry is LOAD; it will re-load your program from disk.
The third entry is DUMP; it will dump core onto the printer. It needn't be very fast
to be a lot faster than looking with the switches. This probably isn't a trivial routine,
but it oughtn't take more than a dozen instructions. You might want to postpone it
just a bit.
So, with a couple hours work - providing you read the manual first - you have an
operating system (SAVE, LOAD) and debugging package (DUMP). And you know
a lot about your computer.”

20. Summary
• Programmers in the 1960s wrote whole systems from
scratch. They were so agile that the “MVP” could be a
handful of machine instructions.
• They understood pretty much all of what we consider new,
radical and agile.
• They would even refactor an operating system to suit an
application.
• And all of this on machines with just a few Kb of memory
and storage.
Now whose software seems heavyweight, slow, and clunky ?