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
Polluting
Alain explains that trash exists because 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 exists 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 being 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 that 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.
Thinkering
Play with things is natural, and it’s not something we want to get rid of, but in order to do a professional thing, like software is not enough only to play. 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 play, without developing deeps skills we will end up with the following result:
So, we should ask ourselves, what came after tinkering, and that is called Engineering.
Engineering
Engineering is basically making things using principles:
Like a cookbook, there are recipes for 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 try things following principles, that is the intersection of both groups (Tinkering and Engineering), but in the same way as 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
Mathematics also involves principles, but the principles are about reasoning and representation.
And later comes what we call Science today was invented.
Science
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).
Sweet Spot
Alan explained 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 computing these days?
Alan explains what happens with most 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 is the software (SW).
The vast 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 out 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, based 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 in 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 separating 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 test things and also later for testing out the optimizations (without polluting the meaning). This leads to simulation, so you want to simulate everything before committing 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, which 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 completely simulating every aspect of it. The same is done for the creation of the mechanical parts done with a Cad tool like MechCAD, for instance, an engine for an airplane), also BioCad and NanoCad are other fields that use 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 ears) really doesn’t want to do all this work (Poor Pondering) for that limitation we should be disciplined.
Conclusion
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 look closer to the statue of Voltaire instead of a mess.
