I’ve written articles here that touched on art theory, quantum theory, science fiction theory and number theory. There are many more theories: gravitational, electromagnetic, economic, social. Of course, there is also pure, practical and applied theory. The idea gets around. On the outskirts there are theories about UFOs, ghosts, Noah’s Ark, many more!
And there are the my theory theories put forth from soap boxes, fliers and now blogs such as this. Literally such as this, since here’s my theory about theories.
A theory, generally speaking, is a kind of statement about some aspect of reality, existence, life. A theory is proven or unproven. If it’s proven, it’s either proven true or proven false. While it is unproven, the matter of whether the statement is true or false remains open. Theories almost always start unproven; some later graduate to proven status.
The goal of any theory is to be proven. In the abstract, it doesn’t matter if a theory is proven true or proven false. (It may matter if you were hoping for a particular outcome!) Once proven, a theory is a foundation on which to build new thoughts, new theories. In fact, proving a theory false can be a good result because it closes all paths leading from that theory. This frees you to explore other areas, which is good; there are so many areas to explore!
It turns out that theories can be hard—or impossible—to prove one way, but much easier to prove the other way. (Which way is true and which is false depends on the theory.) One easy way to prove a theory involves finding an exception to the theory’s statement(s). This leads to the idea of a falsifiable theory; that is, a theory should be something we can try to break. If we can break it, the theory is false. The longer it survives our efforts to break it, the more likely it is the theory is true.
To understand why it works this way we can think about swans…
There’s no such thing as a black swan
Consider two parallel theories. One says that there are no black swans; the other that all swans are white. The two theories are similar in that both make statements about the colors of swans. But the first says there is no such thing as a certain type; the second says they’re all a certain type.
(It is probably easier to imagine proving a much smaller theory: there are no black swans in my yard right now; or if you prefer, all swans in my yard right now are white. Note that although neither theory requires any swans in your yard at all, the second one seems to imply them. More importantly, notice that small theories don’t necessarily translate into big theories. The fact that there are no honest politicians in your yard right now doesn’t necessarily mean they don’t exist at all. More to the point, if there are swans in your yard, theories about their color may not be the best focal point for you right now.)
We can prove the first theory (no black swans) two ways: we can examine every swan that ever was, is now, or ever will be. If we can do that (we can’t, but if in “theory” we somehow could) and find none that are black, then the theory is finally proven true. But if we find a single black one along the way, we stop; the theory is proven false!
The very important point is that proving it false lets us stop testing. It also elevates the theory to a proven status, but—and this is the crucial part—it lets us stop testing. Of course, so would proving it true…
But proving the theory true requires searching all possible swans, and that’s not possible. Generally speaking, a no such thing as theory is, impossible to prove true. It’s impossible to prove that there’s absolutely, 100%, no such thing as UFOs, ghosts, God(s) or flying spaghetti monsters. The only way to prove there’s no monsters under the bed is to check under the bed. Every bed. In all of time and space.
Now consider the second theory (all swans are white). As before, to prove the theory correct we need to examine all possible swans. Again, each swan must confirm to our theory—it must be white—or the theory is proved false (and we stop). But so long as each swan we find is white, the theory is open, and we must continue with the swan search.
A difference is that the second theory (swans all white) is a statement that all swans have a specific trait (color=white). Any color variation makes the theory false. The first theory (no black swans) is a statement that all swans lack a specific trait (color=black). Color variation doesn’t matter so long as it doesn’t vary to the color black. Assuming different swan colors, the second theory should be easier to prove false, because any variation of the trait makes it false.
That is why all X are Y theories tend to end up proving false. The all swans are white theory is as easy to prove false as the all Bruce Willis movies are good theory. Or just about any other theory making universal claims about a group of whatevers. And such theories tend to be ugly when applied to groups of humans—plus they tend to be false—so they are doubly wrong.
Note that the assumption a trait is distributed isn’t always warranted. This is why swans are a canonical theory metaphor. A theory that all swans are white is sensible, because most swans are, in fact, white. And since most swans are white, or at least more white than not, it’s easy to guess that there are no black ones. Swan color, we can imagine, is not distributed. Swan are white; swan are not black.
In any event, proving either theory false—which we can do if we find the right sort of swan—graduates the theory to proven (proven false). We can do this because the theories makes statements we can test and possibly prove false. Both theories are falsifiable.
Reverse Theories
The natural question is, does it work in reverse? Are there theories that are easy to prove true but impossible to prove false? In fact, there are, but in some cases all we end up with is different wording. We’re still breaking the theory by finding an exception to what it says.
Consider the theory some swans are black. This is precisely the reverse of the original black swan version. In this case, finding a black swan makes the theory true (not false, as in the original) and lets us stop. And we must check all swans in creation (and find no black ones) to make the theory false.
A reverse version of the second theory is some swans are not white. Again, the true/false outcomes are reversed. Again, one outcome lets us stop the proof process, the other requires (literally) forever.
Both these theories use some with regard to swans. If a swan qualifies as some swans, then these are precise mirrors of the original theories. But a theory can also involve a group. The theory there are at least 100 black swans, for example. The question is whether a theory about some things is useful. It’s the theories about all things tell us important things about reality.
Getting Formal
For those interested in the technical details, our two theories have formal logical expressions; they can be stated mathematically. Let’s first state the theories a little more formally and then a lot more formally:
The formal logic (mathematical!) versions go like this:
The little s stands for a swan; the upside-down ∀ means all (∀ll); the ∈ symbol means is a member (element) of (∈lement); the tilde (~) means not.
So the first one reads as “for any swan in the class of all Swans, that swan is not black.” The second one reads as “for any swan in…all Swans, that swan is white.” In both cases, the theory asserts the formula is true. If we find a case (a swan) that makes the formula false, the theory is falsified.
Keep in mind that black swans and white swans are just a metaphor with no connection to actual blackness, whiteness or swanness. It was all theoretical theory anyway.
If nothing else (and I think there is plenty of else), I can look back on all those years of writing code and pick out the main themes and principles, the things that seemed to matter most. That’s what this CS101 series is about: things I think matter most when it comes to designing software.
Learn to learn. This is a required skill. Programmers constantly learn new things. There are new tools, new languages, new processes, new standards, new client contexts and new technology. This is an evolving field; there’s always something new. I’ve learned as much in this past year as in every one of the 30+ past years I’ve been doing this.
Learn to look stuff up. Another required (and acquired) skill. No one can know it all, so the key is knowing where to look stuff up. As I said, we all need the documentation sometimes. That was Scotty’s secret, you know. He had access to Wikipedia!
Learn to communicate. This covers tools, such as Word and Excel (or whatever), but also has to do with improving your writing, and possibly speaking, skills. You may need to do documentation for others, or give a presentation, but you’ll find that skill with documentation and analysis tools is also a benefit to you.
Learn your craft. Well, duh. Naturally you want to be good at what you do. That includes the background knowledge, such as knowing the programming language, as well as specific knowledge, such as the data scheme of your database. The stronger your background knowledge, the more you can see of a system, the more of that system you understand. The more you can see, the better you are at debugging or making changes.
Here’s a simple tip! I can’t begin to count how many potential code bugs this has eliminated. It takes some getting used to but once you make it automatic it’s a real help in keeping code and your thinking correct. The tip is this: when you write relational expressions, always use less-than, never use greater-than.
Clarity is the #1 priority when writing code. Clarity trumps everything else; it’s even more important than the code being correct! One of the biggest wins a serious programmer can offer is writing clear, readable code.
Clarity is more important than correctness (which is still very important!), because clear code can be fixed if it’s incorrect. Unclear code is harder to work with. It’s harder to find, let alone fix, bugs. Clear code also helps debug as you write; you are more likely to catch your own errors when you write clear code.
Think of writing code as you think of writing a formal letter.
Literate Programming
The order of things is one way you make source code clear. I’ve also mentioned the importance of good comments. (I’ll talk about good comments vs bad comments another time.) There are other important ways you write clear code.
It’s been said that programming is an exercise in managing complexity, and while that’s true, it’s only part of the picture. (Still, it’s a pretty big part!) More to the point, managing complexity applies to much more than software design. A defining characteristic of modern life is its complexity, so learning to manage it might be a Pretty Good Idea!
Most people are familiar with top-down (or top-to-bottom) and bottom-up (bottom-to-top) analysis or modeling.
Problems involving data flow or process (for example reading a file or generating a report) often model well horizontally. As with top-down and bottom-up, horizontal organization also has its polar opposites: left-to-right and right-to-left. Which fits best depends on whether the problem is input-dominated or output-dominated. Input is thought of as on the left, and output is thought of as on the right.
The final two are hard-to-easy and easy-to-hard (similar to top-down and bottom-up, but model on difficulty rather than scale). The first one seeks to meet the most challenging aspects of a problem first. The second one seeks to accomplish as much as possible in the shortest time, to get the easy tasks out of the way early. Combining them (as we can with the above models) helps to discover potential pitfalls while rapidly bootstrapping a project.
Time to start talking more about programming. It’s one of my defining aspects. I’ll try to make it as interesting as possible for the non-programmers. For the programmers, I’m sorry, but that means sometimes I’ll have to get a little basic or skirt a few corners. Feel free to use the Comments section!
Physically software is just a long string of numbers. In fact it’s really just a string of things and not things. Holes in paper; or not holes in paper. Magnetic domains magnetized; or not. Tiny electronic switches turned on; or not. You can represent software as a string of black and white jelly beans. It’s all the exact same thing. What matters is the pattern of thing and not thing.
Now the packages of eight bits, the bytes, are clumped into small groups, usually, of four (4 x 8 = 32). These are called words. In some cases the words are of two bytes (2 x 8 = 16) or eight bytes (8 x 8 = 64). The phrases “32-bit” and “64-bit” refer to this is the level of abstraction. The software is a string of words now rather than just a string of bits. The words are meaningful in the (abstract) language of the program.
Other professions deal more with abstraction. Architects and Mechanical Engineers, for example, deal with drawings and models, which are abstractions of buildings or machines. They start from a pure abstraction, the idea and design, and work to build a concrete thing. [In passing, computer models and 3D printers have made the abstractions much more concrete. We've come a long way since faded blue prints.]
Mathematicians and theoretical physicists are entirely in the realm of abstraction! In some cases, 11-dimensional objects for example, a concrete object is not possible. Or took place long ago; the Big Bang took place a very long time ago! In other cases, the forces, energies or times involved are far beyond our technology. They could be concrete in theory, but we’re not likely to pull it off any time soon.
I don’t like the term Software Engineer. Real engineers have licenses and certifications and prescribed educations. No such exists (currently) for software makers. It is still a new craft in our society (it goes back only to the 1950s or so), and we haven’t caught up to how complex and demanding it really is. Anyone can use the term Software Engineer, so it doesn’t have the meaning it could.
People who work with software are sometimes called knowledge workers, but I think that’s also poor terminology. All workers use their own knowledge as well as the business’s knowledge. Some professions require more base knowledge than others, but it is still a continuum. I just think it’s a vague way to specify a profession.
Here’s the punchline: if you could pour grains of rice for all 64 squares on the chessboard, you end up pouring a total of 18,446,744,073,709,551,615 grains of rice.
As the parable also mentions, after a while the doubling becomes serious. 16 thousand, 32 thousand, 64 thousand, 128 thousand, 256 thousand. Wait, that’s a quarter million, and we’re only 18 squares in! By 25 squares we hit 33 million; at 30 squares we cross the billion mark. At 40 squares we reach trillion (million million), and at 50 squares we’re over 1000 times beyond that. By 60 squares, we’ve got over 1 billion billion grains of rice, and we reach the final count four squares later: 18,446,744,073,709,551,615 grains of rice.
