Monday, December 15, 2008

How To Guarantee That Your Software Will Suck

You may have recently read two eponymic blog posts about this crucial subject, so I won't give you ten more ways to suck at programming but just one.

Here it is:
Don't critique your code.

If you never ever have a critique view of your code, you are on your way to write software that sucks.

People who pair program may chuckle: they already have a continuous critique process that helps producing high quality code. People who practice code reviews may chuckle too: they already have a process (and, often, tools) for ensuring code is properly discussed.

So what is left for those who do not pair program or practice code review? The same applies: whenever you come back to your own code, critique it. Oftentimes, while adding a new feature, you will realize that a particular design is convoluted, a class is ill named or a method is hard to read.

Do not fall into complacency with your own code: love it, hate it, critique it, refactor it!


Dom Farr said...

but when is your code done....I often critique my code so much that I never feel like it's good enough.

David Dossot said...

I think it is never done, per se. When it satisfies its requirements, your code is functionally done and can be shipped.

But this is only a beginning, as feature requests will make you come back to it and critique/refactor it, while adding new stuff.

Critiquing without shipping is useless. Critiquing in a loop as well: you need to release, do something else, come back to it and only then you will be able to constructively critique it.