I think the easiest way to tell an experienced programmer from a newcomer is to see how much they care about maintainability. New coders (and some business clients) just want to it built as fast as possible, at any cost. Coders who have been around for a while understand, however, that code of any quality spends a lot more time in maintenance than it does getting build the first time.
But there are still some disagreements on just what maintainability means. You can't boil it down to a number, like lines of code or hours spent, so it's not as easy to measure -- and if you can't measure it, it requires a lot more intuition and "art" to manage it. Here are a few thoughts for making decisions based on which is the more maintainable.
Maintainable Components
For almost any common programming problem, there are two or three potential solutions that are already built, and generally, a well-supported external component is more maintainable than rolling your own... usually. If the code is buggy, poorly-documented or poorly-supported, you might be better with your own home-made solution. Or, depending on the options and task, it may make more sense to take a poorly-supported, but open solution, add what it needs, and contribute the changes back.
In any case, you want your components to be reusable, reliable and, as much as possible, forgettable. If you never have to think about it, it's doing its job just fine.
Maintainable Design
Test-driven design often calls for the "simplest change that will pass the test." And if you have full test coverage, it's so much safer to refactor that it can be the wisest decision. But often the type of "organic" design that can grow out of Agile development is closer to organic fertilizer.
Maintainable design means using "just enough" design to get your job done -- over-engineered code is a pain to maintain -- but it also means encapsulation, smart code re-use, and appropriate application of design patterns.
Yeah, I said design patterns. I also said, and I emphasize, appropriate use of design patterns. I'm not talking about using a Factory to produce "Hello, World!" But design patterns are a smart way of encapsulation with maintenance in mind, and when your developers understand and use patterns, you greatly reduce the typical heavy communication overhead associated with maintenance.
Maintainable Process
This can be a major challenge for rapid-development groups because there is a way to get working code out that is faster than the most-maintainable process for the first draft or two ... and some programs never get past the first draft or two. But if you have a high-output "lightweight" process that glosses over maintenance needs, it's only a matter of time before your output of so many code chunks that require maintenance starts draining resources from your high-production plan.
There are many options for process, and it's wise to choose one that's appropriate for your team, your business, your industry, and your size. Whatever process you choose, it's essential to track new development and maintenance work, to pro-actively reduce code debt, and to plan for maintenance before you start a new project.
