Code, Design and Expression
In math and CS, rigor is one of the standard or qualification that you need to satisfy if you want to join these community. But these days, I think there’re lots of considerations behind this single standard. And we may probably define the wrong question to what we need to solve.
In engineering design, or just in the probability, which is one branch of math, many people may experience one stuck that there’re so many different situations, how can I know that I’ve considered all the situations and combinations?! And the more you think, the more depression you would be. At last, you would summarize these that: it’s truly a rigorous subject that requires iterate all the corners of details. But that’s really beyond my ability, let’s just drop out.
But once you have a little experience of solving these complex and boring problems, and calm down to retrospect your solution and the process to get here, you would find something different, at least I do find something strange. I find, mostly, the final solution will never involve considering lots of special condition cases. It’s amazing that in your final solution, the complexity that bothered you may never exist! What’s the problem?! And how hell it happened? Do I lost my mind?
What happen here is far beyond newbie engineer and math student, but very familiar with those designers in CS & math domain. They call this as the design problem. From my understanding, design’s responsibility is to explore the ways to express, and here it is. Mostly, we’d blame ourselves that we’re not smart/rigorous enough that I can’t iterate all aspects of this problem. We just doubt our brain CPU. But we may forget to blame other aspects of the whole process, e.g. the way to hack the problem.
From my experience, if you find you’re hard to consider all the potential situations of one problem, it’s probably the sign that the way you think of the problem is wrong, the expression of this problem is inappropriate, and the position of penetration is not right.
In Unix/Linux community, there’s one saying from Linus that good programmer cares about data structure, the bad one consider his code. Because the relationships are always more than the elements. Once you get the data structure, you get the stable part. But if you want to hack the relationships of those data structures, you’d be mess. So in order to control the complexity, you need to put your efforts on the data structure design, which is supposed to express your problem and its relationships much better and efficient.
The same techniques are also common in math. In order to control the dynamics of value, mathematicians introduce the variable, which is the relationships of values. In order to control the complexity of variables, they introduce the function, which is the relationships of variables. In order to master the complexity of functions, the functional is introduced. And finally, in order to control any type of relationships, the concept of set is refined in modern math history.
From above discussion, we may find one thing that the complexity is hard to control, thus we would put efforts on the elements to generate them, which is the ways to express them. For CS, it’s the data structure to code. For math, it’s the definitions to connections. (This may not be concrete, because math is abstraction.) Thus if we find we have trouble to consider all the situations in one problem, it’s very probably that you design an inappropriate way to express the problem. Because thinking model you design doesn’t make those complexity under your control, but just let it breed. You do need to redesign your data structure, your basic structure, and the way to organize all the materials in problem.
Thus I would argue that the rigor is not the problem we meet when we deal with multi-situations problem. In fact it’s the matter of design. Good design can control the complexity, which makes all the special cases disappear and let only one common situation happen. It’s the structure of your solution defines the complexity of your hacking. Designer’s job is making all things under control.
If we’re agree with these discussions, we may understand the old saying that: once you can express the problem appropriately, you’ve solved half parts, even all of the problem.
And from a higher level perspective, we do need introspection. Even we just find that we may blame in wrong direction, it can give us more deeper insight and reduce our senses of guilty.