Incremental Perfectionism : 5 ways to write perfect code

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

TinyMaking 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

BetterIncremental 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 .

Back signIf 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

RubyForgeA 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!

14 Comments

Filed under Misc, tips

14 responses to “Incremental Perfectionism : 5 ways to write perfect code

  1. Pingback: Io sono un perfezionista... - ExternalBlogs

  2. 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”

  3. 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

  4. @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!

  5. Holy cow!!!

    Can you beleive my previous comment was marked as spam! On my own blog!?!

  6. 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.🙂

  7. 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!

  8. 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…

  9. 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…

  10. Thanks, that might be a solution. I’ll think about that.

  11. Hello

    thanks for this tips viagra

  12. Liked your point; I was actually looking for how to commit my current work to a branch.

  13. Great article! superb data, been longing for one thing like this for a short time.

  14. Great Submit, Many thanks

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s