Things Every Software Architect Should Know

The key is to avoid slavishly following a rule. You should not shy away from breaking a rule, provided you have good reasons for the violation. First learn what the good rules are (as applicable in majority of cases) and then learn when to break them. The best practices are not supposed to be carried over verbatim into every development project.

If you're building a web start-up, forget specifications. Write code. There is no way to have the slightest clue what you need to specify anyway. Write something that does something useful and put it in front of some users. Go from there. In different circumstances, of course (e.g. while building the software for a major Stock Exchange), this is the absolute worst thing you can do.

If you're building your start-up, it's almost always too early to think about performance. You need to have some vague awareness of whether it will be possible to optimise your code later and keep it clean and simple so that it remains possible, but ultimately I've found that it pays to optimise at the last minute - i.e. optimise when there are performance problems, not before. On the other hand, going back to the major stock exchange example, performance there is likely to be one of your major challenges, so you need someone on the team who is performance-minded and has built a stock exchange before, so that they know where the bottlenecks will be and can ensure those are avoided.

That difference is due to scale - the architect has to think about the application holistically where a developer needs to think atomically.