Scaling is for later: "Quit sweating the problems that give you a mental stiffy, and work on the problem that are truly hard: ease-of-use, process, transparency, discoverability and the whole use experience."

This used to be exactly the attitude that I took until about 2-3 years ago: developer team is expensive, disk, memory and processor are cheap, and so scaling shouldn't be tackled until it needs to be. But I realised (with some gentle prodding) that it's necessary to consider (or at least measure) things like database load and memory usage in applications early on - particularly in large, complex systems or those where you're using frameworks or toolkits (like Hibernate) which help you forget about what's going on "under the hood".

Now these tools are absolutely great... but if you don't understand how they're talking to, say, the underlying database then you need to at least measure how they're doing this. Otherwise those single-user tests you were doing which were working fine start breaking down when you hit a couple of hundred simultaneous users and the database load goes through the roof... and suddenly you either need to worry about how you're going to afford lots more servers to scale across (and get your app to do so), or you need to revisit your application logic.

Granted, perhaps this is less of a problem for pure web applications - but in these AJAXy days where servers are handling requests not just at page-load time but all the way through an application, I suspect it'll become more of an issue.

And none of the above implies that the user experience is in any way less important. At FP we're firm believers that you need rock-solid technology *and* delightful design.

Comments

[petrilli]

I think people have taken my words a bit differently than I originally intended them. What I was referring to is the absurd myopic focus that many "geeks" take towards performance, while forgetting that other things are equally, or more important. Performance only has to reach "good enough," often to delivery a real benefit to the customer. Most of the people who "get" the overall picture, in my experience, naturally deliver sane solutions that don't kill you from a performance perspective. Those that micro-optimize their solutions to shave 1ms off a query have forgotten the 20 minutes it takes a user to enter the wrong data because of their poor design.

Honestly, if it just gets people thinking about where the issues fit together, then that's all I really wanted. Thanks!

[Tom Hume]

Petrilli - I agree with you, you need both. But, particularly at a time when XP-type stuff encourages evolving architectures rather than up-front design, "good enough" needs to be "good enough to go live and cope with an initial audience".

I guess one way around this is to set clear initial targets for scalability - "the system must handle X hundred users within the first Y months", and thus avoid the requirement seen all-too-often in initial specs that the service "must scale" without any explanation of what this really means.

[petrilli]

I agree that scale must be part of requirements, but it's also necessary to be "realistic," something that is unusual in a lot of start-ups. 99.99999% of the time, you don't have to deal with hundreds of thousands of users in a short time. If you do, then you'll be able to get forgiveness in many cases, and you're more likely to find yourself with a lot of users if you're out of the gate earlier.

It's a trade-off, I just find that people tend to find fascination in scaling issues they simply will never face. My definition of a "big database" doesn't start till 500GB or so, but for a lot of people that's inconceivable, and for some that's barely a day's worth of work. It's all a matter of perspective.

[Tom Hume]

Petrilli - I agree, but on a complex service it's perfectly possible to generate high load with lower numbers of users - particularly once we start breaking the page metaphor of traditional web development and head for more asynchronous lands...