>A novice programmer was once assigned to code a simple financial package.
>The novice worked furiously for many days, but when his master reviewed his program, he discovered that it contained a screen editor, a set of generalized graphics routines, an artificial intelligence interface, but not the slightest mention of anything financial.
>When the master asked about this, the novice became indignant. ``Don't be so impatient,'' he said, ``I'll put in the financial stuff eventually.''
I love this one because it took me many many years to "get" this lesson: it's not about the code. It's about the Program.
I'm not sure I understand this one yet. Could you explain what you mean about code vs. Program?
To me, it seems the novice is correct here (supposing that those components produced are required for a good result). Is the lesson similar to that of building DSLs?
Firstly it is a focus on "results" rather than output. The novice has produced a lot of output but no results. How would you evaluate if the components serve their purpose? Are they doing too much? Are they not doing enough? It is only by virtue of the program's results that you can check. As programmers we tend to evaluate the code (which is an internal focus) more than the running program (which is an external focus). This is a great way to learn but a bad way to deliver anything of value to an end customer.
As a programmer, the novice would understand and be interested in the ins-and-outs of his screen editor, gui routines, and AI module. However, he would probably not have the same level of understanding of finance. For a good product, the novice should concentrate on raising his understanding of finance to the level where he can deliver solutions to his users. By ignoring his users (delegating them to an afterthought), he is making a fundamental mistake.
Finally, it is a question of value. This is key - the most fundamental aspect of this scenario. The programmer, for all his effort, has delivered nothing of value to his users. Worse, he does not even have the attitude and direction required to deliver value. When someone says "I'll put in that stuff later" (or it's equivalent), you can be sure they will deliver something of poor quality to the users.
In the end, if you cannot say the work you have done today will make someone's life better - what is the point of working so hard?
Ah! I did not understand the emphasis. It didn't occur to me that the novice would be working on things that were not relevant. Thank you for explaining. Also, I may still not understand the depth of this lesson, yet.
Ah, old memories... I remember reading this years ago. And recently while naming my blog too as 'The Tao of Programming' by myself, I thought it sounded vaguely familiar (but oddly, didn't think of Googling for it).
But reading this now, I realize this is more like a set of Zen koans than like Tao Te Ching itself. A little 'poetry' here and there like Tao Te Ching, but most parts are obviously inspired from koans.
Once, a large computer company, seeking to plumb the depths of the Tao, decided to psychologically test a large group of its programmers, including its Masters. Unfortunately, they did not have enough copies of the test. Luckily the test came in two separate parts, so half the group got one part, and half the second. When the group was done taking one part, the tests were exchanged, and the psychologist administering the test, following his programmed script, gave the exact same instructions that he had already given, ending with "Are there any questions?" He was about to command "Then you may begin." when one of the Masters shouted out: "Should we use the same personality as we did on the first half?" The psychologist was silent, and completely baffled. One novice in the room, and some reading this story years later, became enlightened.
[Stolen, with slight alteration, from Gerald Weinberg's The Psychology of Computer Programming]
So many pieces of truth in here. Most of them I internalized long ago, but still there is the odd one which I encountered recently. This time it's "Software rots if not used". It is indeed a mystery, but oh so true.
Not only the dependencies, also the requirements and the people who use it.
But it's more than this. I think the real lesson is that a program is always a work in progress... like a walking person, always falling forward and putting one leg after the other to stop the fall. The moment you don't touch it anymore it dies.
"Working" can be a programmer writing code, or just a user putting data in, or submiting the occasional bug report... or anything. But the moment it stops interacting it gets out of sync with the world.
A novice asked the Master: ``Here is a programmer that never designs, documents or tests his programs. Yet all who know him consider him one of the best programmers in the world. Why is this?''
The Master replies: ``That programmer has mastered the Tao. He has gone beyond the need for design; he does not become angry when the system crashes, but accepts the universe without concern. He has gone beyond the need for documentation; he no longer cares if anyone else sees his code. He has gone beyond the need for testing; each of his programs are perfect within themselves, serene and elegant, their purpose self-evident. Truly, he has entered the mystery of Tao.''
>The novice worked furiously for many days, but when his master reviewed his program, he discovered that it contained a screen editor, a set of generalized graphics routines, an artificial intelligence interface, but not the slightest mention of anything financial.
>When the master asked about this, the novice became indignant. ``Don't be so impatient,'' he said, ``I'll put in the financial stuff eventually.''
I love this one because it took me many many years to "get" this lesson: it's not about the code. It's about the Program.
EDIT: Minor edits