To make something better is a great feeling. But is 'better' equivalent to 'as good as possible'? Is it 'the best'?
- how would Jon Skeet (or any other authority) do it?
- is it SOLID enough?
- wouldn't code reflect domain model better if I ...
- the solution created last week seems a bit 'dirty' to me, there has to be better way to do it, even if it means re-writing ...
Making things the best is a huge temptation. Top notch. World class. Nirvana of code. Something that would make masses worship you & your genius.
Perfectionism.
Pedantry.
Fail.
This great, treacherous sin that affects especially good, ambitious engineers. Makes them lose touch with reality and delve into reckless insanity - sometimes achieve great things, but also make a lot of harm around (hence reference to berserkers):
- proper focus is lost (on adding business value)
- simplicity (KISS, YAGNI) is being sacrificed for engineering purism
- 'done' is never 'done', replaced with endless tweaking and polishing
- they look for a perfect solution that ... just doesn't exist - there are too many ways to achieve results and too many factors to judge these ways by
It's like drug, when you keep coming back to code you still consider unfinished. Because you feel & know that this CAN & SHOULD be done better. So, your vision gets narrow, you can't pay attention to anything else, you're postponing more important tasks you should be doing instead, hoping that no-one will notice. It's just you and the code you're working on - your mortal enemy.
This is an obsession that may lead to failed project, shitloads of accumulated tech debt, crisis of trust (within team), etc.
It may get even worse if the individual has a skewed perception on what 'perfection' is in this particular context:
- introduces new libs / frameworks all the time, just to use a meaningless feature or two
- mismatches solution to the problem - takes a sledgehammer to crack a nut
- continuously re-writes other people submissions to adhere his / her standards
Just a remark (to make it as clear as possible) 'not being pedantic' doesn't mean 'taking it easy' -> DoD is DoD: tests have to be written! :D
It may look silly, but it happens even to the best. But fortunately there are ways to fight it:
- keep low task granularity ...
- ... and high work transparency (for instance: radiate task information or sync frequently)
- pair programming / code peer review helps as well
- crystal clear DoD
- all the activities considered as foundations of continuous improvement (retrospectives, controlled experiments, etc.) are helpful
- contributing to OSS project (the larger the better) will help you faster than you can imagine :)
The title image comes from http://www.firstlawcomic.com/. It's a comic book based on famous "The First Law" trilogy by Joe Abercrombie. You can get a comic book here and books there.
Highly recommended.
