Looking forward to hearing a lot more about that!
For example, while we know you've said it will help customer support, that can include many things. Some examples:
Although I've got probably 8 years of experience as a dev, I still feel pretty new. I'm not new to writing code that I feel is of good quality (few defects, easy to understand and maintain, efficient), but I definitely feel like I need more experience in balancing quality versus time.
Sometimes you feel the quality is worth it, sometimes you're told it's not, and sometimes the people who tell you (to ditch the quality) are right, and sometimes they're wrong. Quality code acts the opposite of the squeaky wheel. Sometimes I feel only I appreciate putting in the extra time for quality, and the benefactor is future maintainers. I feel privileged if those around me have deep knowledge of code quality and encourage it.
Quality varies due to many factors, such as time, design decisions, standards (i.e. unit test coverage), complexity of the desired task, experience of the author, defect tracking, test coverage, and, I feel very importantly, whether there are opportunities to refactor.
A code base also isn't uniform in quality either. Some parts may be totally solid, other parts may be very difficult to understand - and you can't fix what you can't understand.
Refactoring is so important, entire disciplines of coding revolve around making refactoring easy. TDD, or Test-Driven Development, for example, suggests that writing Unit Tests (automated tests) first, then writing the code to pass the tests. The idea is that if you don't understand the requirements, how can you write the tests? And if you can't write the tests, then what you deliver cannot be verified. Thus initial quality is very high, but the real payback is (because our world is constantly changing) if anything were to change (i.e. bug fixes or a refactor), you spend the least amount of time possible on re-testing, only needing to write tests that reflect the bug found or the new conditions, and the quality of the codebase ratchets upward.
So when WayTools says:
What we’re preparing right now in our infrastructure code will hopefully prove to be a wise choice to expedite general release.
It's being brave and rational risk taking in the truest sense. You don't know whether it will pay off. I highly suspect it will pay off, and I've seen how WayTools makes very rational and informed decisions, and I sure hope it does pay off for them.
The new structure is a big step up in new power to handle user needs, and will let us react faster to new demands from general release users.
I tend to oversimplify, but probably some features they wished to do (underlying data about how the prediction works, or hardware health monitoring, or maybe some very deep features I can't begin to understand), are almost impossible in the old code base, but much easier (or at least possible) in the new code base.
Not to say their old code base is bad. A smart and rational team wrote the best code they could given what they knew at the time. But TREG other new knowledge comes in, and number of areas that could benefit from additional flexibility is high enough that a rewrite is deemed the best way to respond to this.
I've heard too many times, people saying to me, "well can't you just hack this thing in (to the existing codebase)?" and whenever I choose to confront that, and explain what's going on, and assuming they have the capacity to understand (and the prerogative to do so, as opposed to just being a whip cracker trying to check boxes for a higher-up), they are most certainly awestruck, and supportive. Sadly, not too many people have the capacity or willingness to understand. Plus you can't fight every battle.
To use a bad analogy, yes, we can nail extra MDF onto the table. No, it will never be as strong/thin/light/beautiful/waterproof/recyclable as an aluminum table. Did you want an aluminum table or MDF?