[HN Gopher] First make the change easy, then make the easy chang...
___________________________________________________________________
First make the change easy, then make the easy change (2021)
Author : kiyanwang
Score : 111 points
Date : 2022-10-02 20:29 UTC (2 hours ago)
(HTM) web link (www.adamtal.me)
(TXT) w3m dump (www.adamtal.me)
| montroser wrote:
| This is absolutely critical to achieve sustainable development in
| large code bases. However, it is also important to know how to
| pick your battles.
|
| Make the change easy with the critical path and core of the
| system. But sometimes, especially along the periphery, the right
| choice is to just make the change and be okay with perpetuating a
| bad pattern, if it is going to bring disproportionate business
| value quickly. The key is knowing when to take one approach or
| the other.
| wpietri wrote:
| I would add one more conditional to this:
|
| > just make the change and be okay with perpetuating a bad
| pattern, if it is going to bring disproportionate business
| value quickly
|
| ... and if it gets cleaned up eventually.
|
| Technical debt should be managed like credit card debt.
| Absolutely take it on in emergencies, but build the discipline
| of paying it down when the emergency has passed.
| Archelaos wrote:
| I disagree. It should be only cleaned up, if nothing else is
| more important.
| omegalulw wrote:
| > But sometimes, especially along the periphery, the right
| choice is to just make the change and be okay with perpetuating
| a bad pattern, if it is going to bring disproportionate
| business value quickly
|
| Agreed. Also tests - if the tests are catching the cases they
| are supposed to but have anti patterns in the way they are
| written - it's not always worth it to fix them so long as your
| new test cases can be easily covered.
| lupire wrote:
| This is the opposite of TDD's "Red, Green, Refactor".
|
| https://www.codecademy.com/article/tdd-red-green-refactor
|
| The TDD version protects against making useless changes.
|
| The "make change easy" version protects against management
| stopping work as soon as the tests pass.
| gardenhedge wrote:
| Ah Kent Beck, where would the industry be without him?
| Jtsummers wrote:
| Probably making snarky comments about some other programmer
| whose book(s) they never read and whose contributions they
| don't understand.
| wpietri wrote:
| Was it snarky? Personally, I think he has made a number of
| really important contributions to our field, and so I read
| that as sincere.
| Jtsummers wrote:
| Maybe I was being ungenerous, but most comments that are
| one-liners like that, "Where would we be without
| <Person>?", when it relates to individuals like Beck or
| Fowler or others here seem to be sarcastic, not sincere. I
| suppose the original commenter could clarify that.
| xupybd wrote:
| I've noticed with this approach it's important to try not to
| rush. If you're like me you see the deadline or the triviality of
| the bug and think I can't charge two days to fix this. But the
| average time to fix bugs in the code base will reduce if you fix
| these things.
| comprambler wrote:
| The same concept applies for system administration, your
| environment (read codebase) eventually gets so complex that it
| accumulates odd infrastructure bugs that pile up over time
| exactly like tech debt. Sometimes you must just spend time
| figuring out how this infra piece (read code block) that was
| implemented by someone long gone from the company even works.
| This usually involves having to fix it as well.
|
| You and your team must piecemeal the long term fixes if you want
| to make any progress towards understanding, scalability and
| reliability.
| OJFord wrote:
| I don't think it's particularly related to the original framing,
| but practising this makes for much better commits IMO.
| civilized wrote:
| I've always been curious, is this how atomic changes are
| accomplished in databases?
|
| I always figured if you changed a table, you would set up the
| data post-change in a separate place, then switch a pointer to
| point to the new data as the very last operation.
| samcheng wrote:
| This is basically the point of Martin Fowler's seminal book
| Refactoring.
|
| The book struck me as a book on unit tests much more than a book
| about refactoring itself, for exactly the same reason as
| described in the article.
| lolinder wrote:
| > In a way, this quote is saying "first do what you should have
| always been doing; being organized" and "then do what you came
| here to do in the first place (add a feature, fix a bug)."
|
| This is half the meaning of the quote, but only half.
|
| Even if you've been as organized as can be, business requirements
| change and suddenly your code organization is _wrong_. A good
| codebase can turn bad fast when people try to retain their
| original code model in the face of a changing real-world model.
| Changes become harder and harder, the code becomes more and more
| complicated, and you end up with a big ball of mud.
|
| I suspect this is especially likely to happen when the original
| architects of the system are long gone. They knew _why_ the
| system was structured the way it was and would have been able to
| recognize when the requirements evolved to the point where that
| design stopped making sense. But subsequent maintainers don 't
| have that picture and either are afraid to make large structural
| changes or they don't know where the inflection points are that
| allow adaptation.
| wpietri wrote:
| > business requirements change and suddenly your code
| organization is wrong
|
| Agreed, and another important case is when you just learn
| something. The beginning of a project is when we know the least
| about the domain. Some early assumptions will be wrong! And
| that's great as long as we've optimized our team's process for
| learning. Indeed, that can become a strength, where we release
| new things specifically to learn. Learn about our users, about
| our domain, about our technical notions.
| tylerchurch wrote:
| Yeah, it seems to be a rule that once something is in the
| hands of users, things that sounded great in theory turn out
| to be bad in practice.
|
| Or things work so well that new (previously unimagined)
| improvements become obvious.
| [deleted]
___________________________________________________________________
(page generated 2022-10-02 23:00 UTC)