I say "current" because this is subject to change as I learn more about the field.
I think if you ask developers what the worst part of development is, they will most likely say, "Modifying someone else's code." Notice that most developers have no trouble with creating new software. The problem perhaps lies in the way programming is taught -- syntax and techniques are emphasized, but maintainability is rarely taught. Teaching programmers to comment their code makes it more readable, but not necessarily more understandable.
Making code understandable is extremely important:
- In XP (eXtreme Programming), the code is the design. The argument is that the rate of change in design documents usually cannot keep up with the rate of change in code. The most accurate state of a system is in the code.
- Code is a medium to store knowledge (Armour, 2000). More than a product, code stores what the developer has uncovered about the domain.
Software rarely stays stagnant (fixes, patches, new versions) so chances are high that you will end up having to modify someone else's or your own code. Have you noticed that even if only two weeks have gone by, it still takes some effort to re-understand what you wrote? :-)
How do we make code understandable? I'm constantly learning more about this. A good start is to read up on XP, Refactoring, and Design Patterns. XP advocates that code should be as simple as possible and no more. Refactoring gives techniques and ideas on how to rework code so that it remains understandable. Design patterns provide the terminology to describe the way your objects interact with each other. All these strive to make intentions clear in the code.
Do you have to use OO? As long as your code is easy to understand, who cares? There is an appropriate place to use each tool. OO is especially useful in larger systems at least as a packaging mechanism. Polymorphism is an added bonus. Procedural programming still lives -- many times, I think of the code within a class to be procedural (is this accurate?).
I hear this many times -- in literature, students read a variety of essays and novels. From this process, they pick up hints of what constitutes good and bad writing. In software, students rarely get the opportunity to read code. That's not entirely true... I think most people can pick out badly written code, but there's little agreement on what is well-written. If I had to pick the characteristics of well-written code, I would pick code where (1) the intentions are clear and easy to grasp, and (2) the code is reasonably efficient.
References:
- Armour, P.G (2000). "The Business of Software: The Case for a New Business Model", Communications of the ACM, 43(8).
- Gamma, E., R. Helm, R. Johnson, J. Vlissides (1995). Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley
