This post is about my personal notes about the amazing talk of Alan Kay.
Alan, start to split the problem of Software Engineer into three main parts
Alain explains that the trash exists because the human doesn’t think about the future. We create all the products to be disposable, so in that way, we make a lot of trash around the world (physically exist the island of trash in the ocean bigger than most countries).
The important here, is the trash exist because of us.
Alan explains in the software happens the same. We create software without thinking about the future, most of the cost of doing software is because wasn’t done in the present, to make 85% of the costs of the software in the future much much lower. So instead of everything is done right now (in the present), it’s done too quickly. and we wind up with this immense of trash.
Alan, explain one of the historical reason why we get into these kinds of troubles is because in our genes, like many animals (many mammals, especially primates), our natural instincts are to tinker with things. Like what happens if I do this, or what happens if I do that, etc. And don't worry about the consequences.
Play with things is natural, and it’s not something we want to get rid of, but in order to do a professional think, like software is not enough only to playing. He describes a parallel with clay. Let's take a look at the following example:
In order to transform the clay from the left side above, into the perfect sculpture on the right side, you need to study a lot, you need to develop skills. It’s not enough just with trying this and that(Tinkering).
If we just playing, without developing deeps skills we will end up with the following result:
So, we should ask ourself, what came after tinkering, and that is called Engineering.
Engineering is basically making things using principles:
Like a cookbook, there are recipes of doing several things in a better way, to get you faster where you’re trying to go and to get you something that's much better for now and for the future.
So what you need to do is trying things following principles, that is the intersection of both groups (Tinkering and Engineering), but in the same way to any engineer, we should move from tinkering to engineering, so the goal is engineering. Of course, also exist bad principles, so we should care bout the right principles to follow.
After Engineering, thousands of years after, of engineer we recognize the Mathematics that today was invented about 2500 years ago.
Mathematics also involves principles, but the principles are about reasoning and representation.
And later comes what we call Science today was invented.
In Science, its principles are about how we negotiate with bad stuff inside of our heads (our brains), ask to deal using a kind of belief structures and memories, and everything else we have in our brains with the phenomena that we experience in the world (it’s a deep skill).
Alan explain the sweet spot is who works in the middle of the four areas mentioned:
Where you are in that schema, depends partly on your personality. But the people who are really good use all four of these things, and try to choose which ones are reasonable from time to time.
What happens with most of computing these days?
Alan explain what happens with most of programmer this days is the following:
It’s mostly tinkering still today, a little bit of engineering, tiny about a bit of math, and almost no science (most of the engineering is in the Harward, HW), and the last one the software (SW).
The vas majority of software people think it can be done without learning about engineering, without learning mathematics, and without learning science. And that is kind of where this mess comes from!
Real engineering Steps
Alan, point it out about Don’s principle: “Premature Optimization Is The Root Of All Evil”, which is about most part of most programs, doesn’t matter how fast they run, what you really want to do is get the program right. Identify the part of the program that runs too slowly and then find a way of optimizing those. So, base on that principle, that you shouldn’t optimize early, but you still want to do something, what should you do? following are the steps that have in common several engineering fields at the moment of doing something.
- You could try designing
Starting to design is a new thought for a lot of computer people, that just jump to writing code, and think to design later (that doesn’t work so well).
In another hand, you need to write something because it’s really hard to design the whole system before trying things out, it’s too complicated.
- Separate Meanings from Optimisation.
What means Meaning is the simplest thing you can write no matter how slow. Designing and separate the meaning from optimization is called Computer-Aided Design (CAD)
- Program and debug your meanings to vet the designs
The ability to debug allows us to know that you have this meaning captured.
- Implement a way of simulation
Explain to find the way to testing things and also later for testing out the optimizations (without polluting the meaning). This leads to simulation, so you want to simulate everything before commit to doing it into much larger work of packaging (SIM).
- Later add the optimizations
Once we have the System running, no matter how slowly, you can then carefully add the optimizations (in a way that doesn’t touch the meaning). When you add the optimization should be using some CAD tool, that will allow us to let the simulator worry about how to test the optimization against the meaning. The way that we implement the optimization you constantly be able to turn optimization off, in order to compare its results. Once we have our solution tested and optimized we could produce a deployable work called FAB.
These steps are done in regular engineer disciplines, that Alan call, “Real Engineering”
These steps we find over and over again in real engineering such as electrical cad (ElecCad). Any computer chip is not created without having completely simulating every aspect of it. The same is done for the creation of the mechanical parts is done with a Cad tool like MechCAD, for instance, an engine for an airplane), also the BioCad and NanoCad is another field that uses the same principles, etc.
Comparing Real Engineering with most of the software today
When you see how people develop software and are a kind of Thinkering and Fab (the deployable work), they are generally missing the step in the middle needed to make a better product.
We generally don’t think about the design, in rear cases, we find a SIM as a main component. It’s mainly aimed at: “okay, we can do everything right because we are smart enough to write end code” (this is a kind of yikes).
One of the reasons that most people don’t follow these steps, is because our brain (the very complicated set of bad machinery we have between our ear) really doesn’t want to do all this work (Poor Pondering) for that limitation we should be disciplined.
I recommend watching the entire video because it’s great, the same for the last part of the questions. But I would like to stop here because I think what it’s really important from my point of view was already addressed. Understand, what Alan said, we are poor thinkers, and for that, we should design, follow principles, learn new skills, and use tools to help us to make our hard work from our brain easier and get better results for our final products, to looks closer to the statue of Voltaire instead of a mess.