Don’t build without a blueprint, don’t rebuild without a plan.
If you study software engineering, chances are you’ll get it hammered into your head over and over again: architecture is important. You can’t just blindly set about building your software. If you do, you end up with a piece of crap with junk tacked onto it left and right. And that’s no bueno, because it means changing one thing is much more likely to send the whole thing toppling over. So before you do anything, you figure out your intentions, describe them on a higher level, and then work down to the details from there. Kind of like the recommended process for writing a story.
The same goes for making big changes to an existing system. If you want to approach the things it does differently in the next iteration, then you need to think about the rules with which you originally laid the foundation and then morph those, rather than building more things on top to suit your new intentions and needs.
And that’s exactly what I’m supposed to be doing in my internship. I take the existing architecture, figure out all the “why”s, and the “why”s of those answers, make changes on that level with an eye on the new requirements (after figuring those out), and then translate it all back to an architecture which can be used as a guide for making new elements.
Well, more or less.