A
mistake I've commonly seen in software development is for many
programmers to believe that things would improve on a project, if they
only had more code.
It's
natural I guess, as we initially start by learning how to write loops
and functions. From there we move onto to being able to structure larger
pieces like objects. This gradual broadening of our perspective
continues, as we take on modules, architectures and eventually whole
products. The scope of our understanding is growing, but so far its all
been contained within a technical perspective. So, why not see the code
as the most important aspect?
But
not all code is the same. Not all code is useful. Just because it works
on a 'good' day doesn't mean that it should be used. Code can be
fragile and unstable, requiring significant intervention by humans on a
regular basis. Good code not only does the right thing when all is in
order, but it also anticipates the infrequent problems and handles them
gracefully. The design of the error handling is as critical (if not
more) than the primary algorithms themselves. A well-built system should
require almost no intervention.
Some
code is written to purposely rely on humans. Sometimes it is necessary
-- computers aren't intelligent -- but often it is either ignorance,
laziness or a sly form of job security. A crude form of some well-known
algorithms or best practices can take far less time to develop, but it's
not something you want to rely on. After decades we have a great deal
of knowledge about how to do things properly, utilizing this experience
is necessary to build in reliability.
Some
problems are just too complex to be built correctly. Mapping the real
world back to a rigid set of formal mechanics is bound to involve many
unpleasant trade-offs. Solving these types of problems is definitely
state-of-the-art, but there are fewer of these out there than most
programmers realize. Too often coders assume that their lack of
knowledge equates to exploring new challenges, but that's actually quite
rare these days. Most of what is being written right now has been
written multiple times in the past in a wide variety of different
technologies, It's actually very hard to find real untouched ground.
Building on past knowledge hugely improves the quality of the system and
it takes far less time, since the simple mistakes are quickly avoided.
So
not all code is good code. Just because someone spent the time to write
it doesn't mean that it should be deployed. What a complex system needs
isn't more code, but usually less code that is actually industrial
strength. Readable code that is well-thought out and written with an
strong understanding of how it will interact with the world around it.
Code that runs fast, but also is defensive enough to make problems
easier to diagnose. Code that fits nicely together into a coherent
system, with some consistent form of organization. Projects can always
use more industrial strength code -- few have enough -- but that code is
rare and takes time to develop properly. Anything else is just more
"code".