I've noticed that as I've gained experience over the years, I've also adopted many strong opinions - Some of which turn out to be erroneous, and clouded my judgement.
This is an excellent TED talk that gave an extra dimension on communication: http://www.ted.com/talks/celeste_headlee_10_ways_to_have_a_better_conversation
It's well worth taking 12 minutes out to watch this - What things do you notice that you do?
"Approach a conversation, as if you always have something to learn".
Friday, 24 February 2017
Wednesday, 8 February 2017
Consistency vs Perfection
I prefer known "bad" code than assumed-perfect new code for knowability reasons (Six Sigma) - You can control, fix and support known(bad, but consistent) processes far easier - And the typical way forward is to bring consistency first.
An example (One that I've trapped myself with in the past):
1. I write one half-good piece of code.
2. I copypasta that in 5 other places (Defect: Now was the time to refactor. Perhaps understandable when you have a large code base).
3. Someone else adds a 2nd similar-but-better piece of code.
4. Someone else adds a 3rd similar-but-even-better piece of code.
5. We have 3x different similar pieces of code that should be consolidated into a single abstract helper method.
6. Perfect code #2 has a bugfix applied because it turned out that we forgot about an old edge case that method #1 covers.
7. Perfect code #3 has a cool enhancement, and diverges it's purpose away from the other two methods.
The two issues with this design pattern are:
1. The refactor becomes harder. The difference necessarily causes difference. Consistency keeps stuff glued together, makes for easier refactors, and therefore more likely to be done.
2. Multiple ways of doing the same thing, with different performance characteristics (two methods having unknown performance characteristics). The old code might be "bad", but it's also probably less buggy and a more known quantity.
This is another case of Perfect being the enemy of Good.
1. I write one half-good piece of code.
2. I copypasta that in 5 other places (Defect: Now was the time to refactor. Perhaps understandable when you have a large code base).
3. Someone else adds a 2nd similar-but-better piece of code.
4. Someone else adds a 3rd similar-but-even-better piece of code.
5. We have 3x different similar pieces of code that should be consolidated into a single abstract helper method.
6. Perfect code #2 has a bugfix applied because it turned out that we forgot about an old edge case that method #1 covers.
7. Perfect code #3 has a cool enhancement, and diverges it's purpose away from the other two methods.
The two issues with this design pattern are:
1. The refactor becomes harder. The difference necessarily causes difference. Consistency keeps stuff glued together, makes for easier refactors, and therefore more likely to be done.
2. Multiple ways of doing the same thing, with different performance characteristics (two methods having unknown performance characteristics). The old code might be "bad", but it's also probably less buggy and a more known quantity.
This is another case of Perfect being the enemy of Good.
Subscribe to:
Posts (Atom)