Practice 3. Simple Design
Simple design means you should only design and code what you know you need while always striving for simplicity. In the pure definition of simple design (such as in Extreme Programming) the goal would be to only design what you need immediately. The problem with this purist approach is that it can lead to oscillation, where a body of code is continually refactored to meet the current requirements because there was no design or planning ahead. If you know that something is going to be required, then you should design it and build it even if this means the user may only see a limited immediate benefit. But you need to keep the design as simple as possible. Add the interfaces later that you don't immediately need, for example. Likewise, if a problem is understood well enough to know that its solution can be found in a design pattern, then the pattern should be used because patterns work and are well understood. But patterns aren't perfect (see the Design Pattern practice below), and again you need to always think about simplicity first.
Tip: Making architecture work visible to users
In agile development, it is sometimes hard to get architecture work recognized. The cards are user-centric features, as they should be, and users can too easily dismiss architecture work if it doesn't have a recognized benefit.
One effective way I've seen to deal with this problem is to attach architecture cards to user feature cards. The architecture cards not only document what architecture and design work needs to be put in place in order to enable the user feature, but they also document the benefits (from a user's perspective) of the work.
In the hotkey case above, a benefit of having a well-designed hotkey manager would be that it makes the addition of subsequent commands trivial. If the users can't see or understand a benefit to architecture work, then perhaps the work isn't necessary after all . . .
Some readers may be uncomfortable with the gray area surrounding being certain that supporting architecture and future extensibility are required. I think it's important to accept that you're going to get it wrong sometimes and over- or underdesign in some instances. That's software development. Fix the problem as soon as you can, learn from the experience, and move on. Teamwork, knowledge, experience, and collaboration are vital to make the right decision. The more people make design decisions with others and use each other as sounding boards for ideas, and the more people learn from each other, and the greater the collective experience and knowledge in the team, the greater the chance that the correct decisions are going to be reached.