Every so often someone writes an article talking about what great code,
or beautiful software, is (or insert some other superlative.) And,
surprise! surprise! It always looks like just like the author's code!
It's funny how that works out.
Let's take a more interactive approach today. I'm going to present a few
choices and support them a bit. Then I'll ask you to tell me why I'm
right or wrong, or if I'm simply asking the wrong questions.
Code that doesn't help anyone is just a useless exercise... or is it?
Can a detailed and intricate bit of code written for a coding kata, an exercise, be useful? Or
is it just thrown away?
What if the code itself is perfect, well written, in fact a great piece
of work, but no end user finds it acceptable or usable? Is it still
That depends on your definition of "great", doesn't it?
The longer I'm in technology the more I think this is a basic skill set.
And I'm not talking about unit tests either. They have their place, but
automated testing is much more than just unit tests.
Sometimes they're testing how five objects interact. Other times they're
package level tests. Still overs are complete integration tests.
The goal is to have a test suite that provides sufficient safety to the developers, and have it run after every single code
change. This size test suite won't be run locally by developers, so we
use a continuous integration server (or a collection of them!), to run
these tests after code is committed to a source code management system.
The value of having your own code tested after you edit is huge. Having
that test run when your co-workers edit your code is invaluable. And
having these tests in place when the code moves into production support,
and later maintenance mode, completely changes the game.
No matter how large the entire codebase turns out to be, I like small
routines, small methods, and small classes. Each routine, and each
class, can be easily tested and fairly easily understood. This reduction
of cleverness drives down the time needed to write the code, debug the
code, and later, support the code.
I've seen lots of clever code. It's fast, when it runs. It shows us how
smart the developer was. It also shows us that he or she didn't take the
time to finish the job. We start with nothing, then build up the code,
often reaching very clever solutions. But then only the truly clever go
one step further and break it back down to its component pieces, making
it simple again. The insanely brilliant skip the middle step and go
straight to simple.
Are you the only one who can read and understand the code? Then it's
bad. It might be the way you wrote it or it might be the problem domain,
but I strive to create code that's human digestible. Computers are
always running faster... my laptop has four CPU cores in it! But the
human brain is still slow for this type of work, so let's be sure to
optimize for the human brain (where it makes sense). Writing code that
you or your coworkers can't read in a year isn't great code.
So what's your definition?