Of ad-hoc changes and context's short-changes

I hate ad-hoc changes. There, I said it loud after long. I'm not sure about you, but I almost hate them with a vengeance. Not in an acerbic tone, but the layers they introduce in maintenance, a sure spoilsport.

That's exactly what one gets to deal with when looking at legacy code bases. All the more so, when it evolves right as it keeps moving and brings in changes. Quite an odd situation to be in, that way.

And that's today's context switch from last week's work; tad better the focus loss. Had to add an ad-hoc flow to fill in information without breaking an existing, evolving flow. Or, if my understanding is right, a local change that's yet to get checked in.

There's pain in such trade-offs, but there is an important takeaway - forced structuring. This change set, for an example, forced me to write a functional component[sic]. Much like the earlier change that formed the meat of the PR1, can move around easy once the flow stabilizes.

All said and done, the minimal context switch based concerns remain, much to one's chagrin. Now that, come to think of, is worth visiting, Clearsoup beckoning louder than ever.