If you’ve ever done a couple of interviews, you’ve probably got the “I’m a perfectionist” candidate. When asked about its flaws he says with a fake-hidden smile: “I’m a lil’ bit of a perfectionist”, thinking deep in their mind this is more of a good thing then a bad one. Perfectionist, those people that only craft perfect thing, only the best (by the best), free of any flaw (except being too perfect), a piece of art left to be admired, not touch by anyone even it’s creator!
Well, that might be good for some poor artist on crack but we’re not! We’re developer driven by business rules, deadlines, changing requirements, technology and coffee. Unhealthy perfectionism is like the big bang approach to integration. It’s all or nothing, but most of the time, it’s nothing.
Here are 5 ways to bring your software closer to perfection, bits by bits, while still shipping your damn code (no crack required).
1. Small changes
Making 1000 lines of code perfect in a respectable amount of time is impossible. But tuning 10 to perfection is easy and fun. It’s also easier to wrap your head around the tiny problem you’re trying to fix.
It’s even easier to do this when writing tests, they help you split a complex problem into smaller and simpler ones and focus on one, one at the time. Hack some code, make the tests pass, commit, update and repeat.
2. Every single change should make the whole better
Incremental Perfectionism, is like the poor-artist-on-crack perfectionism on a smaller, healthier scale. Don’t try to make the whole thing perfect. But never ever settle for something that is not the best possible solution to the small problem you’re solving. Don’t copy paste some code because it’s easier, don’t comment out a block of code because it’s faster, don’t live with ugly code. But don’t fix it all at the same time!
3. Refactor, refactor and refactor
Perhaps your understanding of the problem has evolve or you’ve learn a new and better way of doing something. Backed by a bunch of solid tests, listen to the code artist in you and refactor! Make the code beautiful, gorgeous, a piece of art, more perfect! Make the tests pass, commit, update and repeat.
4. svn -R revert .
If you feel you’re breaking any of the previous rules, start over. Maybe your changeset is getting too big. You’re trying to change too much things at the same time. If you’re afraid to loose your precious code, commit your working copy to a branch:
svn cp . http://svn.icanhazcode.com/svn/branches/my_precious
or create a patch:
svn diff > my_precious.diff
then, step on your ego and
svn -R revert .
But since we’re working with small changes, you haven’t lost that much right ?
5. Read lots of code
A good way to trigger your imagination into moving your software closer to perfection is too look at how other people are trying to do it. Open source projects are open books into some of the best programmers mind. They’ve spent time trying several ways to solve a problem, don’t spent your time doing the same thing!
I hope you find this helpful. Let me know how you’re making your code more perfect!
10 Comments
August 22, 2007 at 2:54 am
[...] e nel refactoring del codice… ma a quanto pare in fondo non è che sia poi troppo sbagliato
Incremental Perfectionism : 5 ways to write perfect code « Marc-André Cournoyer’s blog If you’ve ever done a couple of interviews, you’ve probably got the “I’m a [...]
August 22, 2007 at 7:25 am
cool
i am currently deep in code that I have to use – one hell of a big and monstruous app that seemed it was coded when its developers were on crack.
if i have to be perfectionnist, like you say, this will never be done. so i am following 1 and 2.
oh — i am following this too
http://beautifulcode.oreillynet.com/2007/08/beautiful_code_in_the_real_wor_1.php
“scorn globally – act locally”
August 22, 2007 at 8:12 am
Marc-Andre,
Most of your blog posts are ruby oriented which dont usually apply to my c# coding, but this is one of those posts that is very valuable.
I associate most with #4. I have been trying to do this myself more and more. Alot of people are very scared to revert but it can be a powerful tool to wipe the slate when you don’t feel like your making progress.
Cheers on the post! Excellent points
Sean
August 22, 2007 at 8:49 am
@heri: Funny I just ordered the book yesterday, I didn’t know there was a blog. In fact, I’m lucky to work on a project we started from scratch, but I’ve worked on those kinds of project your talking about too. I which I had red that blog post at that time! Thanks for the link!
@Sean: I’m sorry I don’t post about C# anymore, I haven’t touched it since I left my previous job. I’m so much in love with Ruby!
You’re right reverting is really powerful. I think it forces you to approach the problem from another angle, thinking outside of the box.
Thanks for the great words!
August 22, 2007 at 9:02 am
Holy cow!!!
Can you beleive my previous comment was marked as spam! On my own blog!?!
August 22, 2007 at 8:20 pm
Hi Marc-Andre,
I liked your post. Good points.
Most developers I know still think in big upfront design first and code after. Which generally lead to late deliveries and complex design that doesn’t adapt well to changes.
In their mind, refactoring is perceived as a failure of their design, so they don’t welcome changes in product specifications.
Liked your point; I was actually looking for how to commit my current work to a branch.
August 22, 2007 at 8:30 pm
Hey Fred!
It’s sad that some ppl still think like this. That’s the perfect example of bad perfectionism, trying to make the whole thing perfect all at once.
Oh and when commiting your working copy to a branch, don’t forget to add new files, I always forget this part :/
Thanks for your comment Fred!
August 22, 2007 at 10:11 pm
Me too, I always forgot to add files…
By the way, I’d be glad to share with you some experience with SVN. It’s not always clear how to choose the best layout for the repository.
For example, when you look at the Ruby on Rails repository, all Rails modules are in the trunk (railties, actionpack, activerecord, …) whereas they have their own version number. I wonder why they didn’t make different “project” so that they can manage branches separately.
I’m thinking about that because for Twittercal I have 2 modules that have a different life cycle while being linked for some release. For the moment everything is under trunk/ but creating a branch for the webapp is a bit confusing.
Well, too much brainstorming I guess…
August 23, 2007 at 9:05 am
Fred, I don’t think there’s a best repo layout for everything. Everyone manage it differently. But the Rails repo is somehow stange and inconsistant.
If you’re 2 modules (the bot and the website I guess) needs to be deployed at the same time, maybe put then under the trunk so you can script your deployment strategy in there.
In fact, if you’re using Rails I think I’d put the bot code under bot/ directly in the Rails project. Then you could use the same Rakefile to compile and deploy.
Just brainstorming, I’m still not sure this is the best thing to do. Repo layout is more an art then a science…
August 23, 2007 at 4:19 pm
Thanks, that might be a solution. I’ll think about that.