Wednesday, February 10, 2010
There are few hard and fast rules in software development, but this one comes close: don’t copy and paste code. Keeping multiple copies around within the same code base is almost never a good idea.
Question is, do you have duplicate code in your code base? How much would you be willing to bet?
Recently I stumbled across a great tool called Simian. It scans through your code and reports any duplicate lines. It understands enough programming language syntax so that it can ignore comments, whitespace, curly braces, and variable names.
Simian hasn’t been updated for a couple of years now, but it works. It’s super easy to point it to your code and have it find duplicates. I encourage you to try it. Unfortunately, you may be in for an unpleasant surprise.
Friends don’t let friends copy & paste. That’s why you’ll want to set up this tool (or something similar ;) to run nightly against your code base to see if you’re getting better or worse. I’ve built a “total duplication” count and a “top 10 biggest chunks of duplicate code” reports, updated every night.
If you liked this, click here to receive new posts in a reader.
You should also follow me on Twitter here.
When I was a young student, I had a fashionable infatuation with martial arts. One day at the dojo I was busy practicing a particular punch to the side of the neck. The teacher watched my repeated fumbling for a while, and finally pulled me aside and gave me one of the best lessons I’ve ever received on how to become a better software developer.
Why learning only one thing is hard
“Listen, you won’t learn the punch right by practicing it in isolation. You’re going through the motions but you don’t know what you’re doing. You’re going to need some context.”
OK, I thought, that seems like a good idea. I’m not getting anywhere anyway.
“Let’s make the punch a part of a story,” he said.
So he taught me a kata. It incorporated the punch into a sequence of moves against an opponent. Before learning the kata I did basically know how to execute the punch. But the kata showed me why I was doing it and that made all the difference.
My teacher’s lesson applies to software development as well. The part you’re working on is part of a bigger story. You have to know that story. It is much easier to do the right things if you teach yourself a little bit about the customers, the business, usability, technology, or anything which is not your specialty but is happening around you anyway.
Are you a fake specialist?
When you pick a specialty, strive for technical depth. As Chad Fowler says in The Passionate Programmer:
Too many of us seem to believe that specializing in something simply means not knowing about other things.
This hits the nail on the head. If ”specialist” does not mean technical depth, then all that is left is an excuse to avoid learning anything else.
So, here is my advice. Be both. Be a generalist so you can understand the whole story. Be a specialist to do your part better than anyone else could.
If you liked this, click here to receive new posts in a reader.
You should also follow me on Twitter here.
