They’re not the same thing, and they’re not optimized the same way.  People throw around the word “scalability” all the time without having a clue what it really means.

So let’s talk about the components of performance.

Speed is about how fast your software works for any given operation, independent of data load and demand.  You address speed with profiling and tuning.  It’s both a code problem, and one that’s apparent without load, which makes it the easiest for both engineers and business people alike to zero in on, but in the grand scheme of things, it’s merely a constant multiplier on the performance of a system.

Capacity is how much load your system can handle.  How much data does a user generate over how much time, how fast is the CPU on your production server, and thus how many concurrent requests can it handle (given the Speed of your software).  Capacity is an offshoot of Speed, efficiency, and hardware.

Scalability is about how your system handles growth in capacity.  Does your system scale vertically (upgrade your hardware), horizontally (add more hardware) or diagonally (rewrite the system).  Vertical scaling has two problems: it’s exponentially expensive (ever bought an 8GB RAM chip?), and it’s limited by the physical capacity of individual computers.  This is why when people talk scaling these days, what they mean is being able to expand your infrastructure by adding commodity hardware (relatively) infinitely.  This also explains why the “cloud” is all the rage.

In big companies, programmers focus on Speed, systems administrators focus on Capacity, and architects on Scalability.  In startups, they all keep me up at night.