In FoP, Karl states that your goal is to create highly maintainable code. His thesis has many presecriptions for this, but I wanted to make a few comments about what I consider the process of creating.
I program computers because I like to create. I like to "design" new things, and make them reality. Basically, I like to take things that already exist, and apply the things that I have learned to make them do new things. To be technical, as "Herbert Simon" would say in "The Sciences of the Artificial", what I do in designing things is apply knowledge to transform something into something else; I create through the process of design, which is an artifical process because it uses cognition instead of being naturally occurring.
Now, this creating can be done done several ways. One is to modify something that already exists to do something differently. Another is to take two or more things that already exist, and combine them together with some new stuff to make them work together to do something new. Or you can just create something altogether new.
Regardless of which of these scenarios, the end result is something that I want to be proud of. And I like Karl's statement that your goal as a programmer should be to make highly maintainable code, and I think this is spot on. That is how a programmer has his achievment most accurately measured.
Why?
Because showing that I created something new, and did it well, is what gives me the most satisfaction. Highly maintanable code means that the code can be understood, that it follows patterns of practice that have been gained through my experiences, and probably most importantly that because of both of these the people using it can learn to do the same if not better.
But what is meant by "highly maintainable code"?
I think this breaks down to several things:
- The code is built using patterns of practice that are easily understandable so that it can be "maintained" - that is understood completely by others,
- The code is tested and proven to do what it is intended to do, otherwhise it is surely not "maintainable".
I used to be skeptical of TDD. I now embrace it wholly. I used to wonder why I made this change. And I quess that is why I was so perturbed in a previous post when I mentioned that I was actively prevented from building a test. After all, without being able to create the test and prove what you did, how can you tell if you created something effectively? And what better a way of defining the measurement of your quality at the start so that you can guide your way to your goal?