> This is especially important IMHO for more senior engineers responsible for architecture and stuff, because those matters can greatly affect the architecture.

> This is especially important IMHO for more senior engineers responsible for architecture and stuff, because those matters can greatly affect the architecture. Telling me why lets me start getting a grasp on what parts of the code are long term and what can be considered a short term hack, what the scaling levels I need to shoot for... This right here has been the biggest problem in my experience. We'll have unforeseen issues arise in production, and the business side will come up with methods to fix the issue. Without context, all of these fixes to our products have been fine, but they never take the future into consideration. It makes me paranoid. I used to adhere pretty well to the adage "Write code for what you have now and not some mystical thing that may arise in the future" while still maintaining enough abstractness to extend things. New requirements would come in, we would implement them, and everyone is happy. 3 months later, a new set of requirements that destroys how we wrote something else. If we knew a road map before we started designing and implementing, we could have saved everyone time and money by designing for X + Y instead of X alone. I get that you can't know everything that is going to happen. I get that there will be times where you must refactor the code. That's fine. However, tell me where the product is going. It may seem like a trivial change to you as a business person, and the only way we devs can keep the change trivial is by proper design.