yozibak.com

Done is done

2024-04-08

However small a task is, you should define "done" before working on it.

Programming is fun. Once you get into it, you can hardly stop. It's like having a potato chip. You have one chip, and you want another. But you should stop at some point. When? When it's done.

Don't rely on your aesthetics

Code can be ugly, but who cares? You, the most, followed by your teammates. And who else?

What your client cares about is the requirement to be fulfilled.

You shouldn't rely on your aesthetics. All you should care about is whether it satisfies the requirements. What means "done" in this situation?

Write a definition of "done" - Acceptance Criteria

One tool I find useful is acceptance criteria. It's written as follows: Given <condition>, when <use case>, then <expected behaviour>.

However small the task is, I usually take at least 10 seconds to write down the acceptance criteria. It can save hours. Because without the acceptance criteria, I tend to fall into a maze of aesthetics and metaphysical discussion within myself. Whenever I'm about to get lost in that, acceptance criteria come in and get me the sanction of "done".

How clean should the code be?

A task is done as long as the acceptance criteria are satisfied. It doesn't necessarily mean I totally don't care about the cleanliness of the code. I tidy things in the self-review process after the implementation.

I only make it clean enough to be read easily by a reviewer. But not more than that. I don't hesitate to push ugly changes as long as the acceptance criteria are satisfied and others can see it as done.

Use refactoring sparingly

Some developers say refactoring is always a good practice. I don't agree with it because: 1) Refactoring can take much time. 2) It doesn't necessarily benefit the further changes.

In other words, refactoring makes sense only when refactoring can make the changes in the future easier. It means nothing when there's nothing further to implement.

The same applies to tidying. Tidying makes sense only when it makes the code easier to understand. When everyone understands it well, it doesn't benefit anything.

Yes, I won't forget the Boy Scout rule(I used to be one when I was a kid): you pick up garbage, but you shouldn't cut the trees just to make the forest "clean".

Github© 2024 Katsumi Yoshida