There are a lot more types than that in my experience (I've added examples at the end), but perhaps we work in different fields. I don't work on windows apps li

There are a lot more types than that in my experience (I've added examples at the end), but perhaps we work in different fields. I don't work on windows apps like FF, I work on web apps. Also, it can happen over a bunch of commits and not be one person's fault. An example might be a terribly performing DB query written by Barry but it's only used in an admin interface used once a year, then Sarah checks in a change 2 years later than happens to use the functionality regularly, but it's used every day, by every user. Additionally, Web apps are very different in a lot of ways as you have one app serving 10, then 100, then 1,000, then 10,000, etc. etc. The performance problems appear from nowhere. Another example of people deferring performance problems was a system I worked with that processed data, it was non-time critical and poorly written, but was fine when the company had 20 clients as they'd just set it and forget it, that was perfectly acceptable, it wasn't worth fixing. When they got to 100 clients 3 years later, they literally ran out of time in the day. This is a regular cause of performance problems, terribly written SQL for reports that 5 years ago ran in 10 seconds, annoying but acceptable, but are now taking 2 hours to run. Here are some examples of other types performance problems: Problems of scale. The problem only appears when you have X number of orders or on-screen widgets, or when there are more than 200,000 users or whatever. Big O problems. This can be missed because your local db has 1,000 orders and your live one has 1,000,000 (which is a problem in itself, but one I have seen almost everywhere I've worked). Race conditions. Everything's fine in a test environment, processing 20 orders a minute. When minutes turn into seconds, race conditions occur. Strange configuration interactions. Problem only appears when you have feature X turned on, with feature Y disabled and feature Z set to option A. Latency. When the DB/App latency is 0.1ms, the app is good, when it's 3ms, certain pages take >500ms because of hundreds of DB calls. Bad Indexes/Query Plans/etc/. Problem only appears after your indexes gradually fragment or because the query plan was built when there were 20 things in the DB, and now there are 20 million.