Embedded Software Reliability Metric is short-term or long-term in time
There are no metrics that completely capture this (or much else), but cyclomatic complexity seems likely to correlate somewhat with difficulty in making changes (Some shit however is just complicated).

One thing that DOES (on average) help is having a development team that has subject matter expertise in how the software is likely to be employed. If you are writing a tool for say petroleum geology, then for gods sake have at least one petroleum geologist on the team, same thing (With the appropriate expert) if you are writing a broadcast control system or an engine management unit.
What having such expertise on the team buys you is an eye on where the product may want to go in the future, it is not perfect but if your team can guess 50% of the time about what features are likely to be asked for in the future at initial design time it can make a huge difference.

IMHO this is so key that I would take a real subject matter expert who is only a so-so programmer over some code god who only knows code about 95% of the time. This also really helps to fill in the blanks in the spec (all specifications have blanks, if you think you have a complete spec you are kidding yourself).  

Remember always that you cannot test quality into a product, it has to be put in at design time.