The Tower of Babel (and other observations)

Musings on the tower of babel story and how it relates to the general human endeavour of thought.

Posted by 09/26/2005

In which the author makes random observations - centralizing on the fact that the Tower of Babel is a story that repeats itself over and over again - year after year


I'm taking 2 classes from Excelsior College. Project Management and Systems Analysis. I'm incredibly sick of school. I never have liked it. Some things I'm learning seem like common sense and other sort of silly. Is it necessary to come up with a system analysis specific definition for the terms 'techniques' and 'tools'? And a lot of project management could go under the heading of 'plan accordingly'. Is it necessary to turn planning and organization into a discipline?

Preacher's Son

It all seems related to the continual knowledge accumulation of the human brain. The brain has some sort of laziness tendency - and yet the continual desire to categorize. The laziness principle begets systematic approaches to things that often cannot be arrived at without experience. Someone takes their experience and tries to codify it into a series of rules. The problem with this can be that the actual process necessary to arrive at those rules is more valuable then the rules themselves. It's like trying to shortcut experience. This is true in religion. I think that explains the 'Preacher's son' phenomenon. The preacher lives a dissolute life and finally comes to realize it is best to live a clean life and preaches accordingly. The child isn't privy to those actual experiences so they have to learn themselves all over again. It's the actual experience that leads you to the conclusions, not someone telling you the conclusions beforehand.

CASE Tools

As far as computer science goes I've found this problem to come up with the discussion of CASE tools. Is the idea of writing an entirely UML conceived application a worthwhile objective? I have a few problems with this. 1) It can only work if there is a very narrow and strict direct path to the generated code. Much like the assembly code a C compiler generates. Myself I haven't ever written code that I could imagine generating until after I wrote the code. Class diagrams are easy - but it's difficult to imagine sequence diagrams turning into code, without making sequence diagrams as complicated and intricate as the code itself. And what was wrong with the code in the first place? It's a language, it's a description that is just as intelligible as a diagram. 2) It takes years of coding experience to get a good handle on Object Oriented design - and CASE tools assume the programmer has those basic skills to begin with. This knowledge seems to only come from experience. And the tools are created by people who arrived at this knowledge without the use of such tools. They are trying to save everyone the work they had to wade through, but it could be the same problem as the Preacher's son. Maybe that work and thought of all those years itself is what makes the tools useful.

Other People's Code

One thing that is not mentioned in Computer Science school that I think should be emphasized is how to use other peoples code - and to get used to the fact that you may have to deal with code that sucks. The tendency would be to rewrite that code but that is not always possible or advisable. This is difficult to deal with sometimes because computer science is a discipline full of blow-hards that think they are really smart. And I'm one of those people, but this article Things You Should Never Do explains the rewriting principle well.

The Tower of Babel

Another thing I'd like to see emphasized is what I would term The Tower of Babel Problem. This is very similar to ReinventingTheWheel - but it seems to be tied more with the nature of human beings to be continually dissatisfied and less with the isolationary stance that comes with reinventing the wheel. The tower of babel problem is both the impetus for great innovation, and an obstacle at the same time. Sometimes I bemoan that fact the Java was invented, because a huge amount of mind-share was taken from C++ - which could have been improved upon all these years by some very insightful minds. If the industry had not gone through the Visual Basic stage, to the PowerBuilder stage than to the J2EE stage - there wouldn't be these huge continual rewrites happening. If you wrote something in C++ in 1992 - you could still be running it now without a total, complete rewrite. I'd like to see coding less subject to buzz words and fashion.

Accumulated Knowledge

On the other hand C++ is complicated - and laden with artifacts from the past that weight it down and convulate it. The desire to start with a blank slate is overwhelmingly strong. Then again maybe we should have just kept improving upon Cobalt. I think Fred Brooks was correct in the Mythical Man Month with his observation that the most productive code you can write is not writing any code (i.e. using libraries etc...) and that is really the only thing that distinguishes what is written today from what was written 30 years ago.

Building on the Past

So, it's best to build upon what people have already built - and yet sometimes it's impossible to build upon what people have already built. I think that's basically what the tower of babel story is all about. In some ways we human beings build upon the knowledge of our predecessors. We make much better airplanes now - and don't make windshields made of solid glass anymore. On the other hand we are doomed to continually start over from scratch because we can't truly communicate.


Total: 0.32 Python: 0.05 DB: 0.27 Queries: 19