In Is premature scalation a real disease?, Todd Huff points to an article from Dharmesh Shah, Startups and the Problem of Premature Scalaculation.
The heart of the conversation is a question regarding how much attention should be paid to scalability when in the early stages of a startup. Dharmesh suggests not worrying about scalability too early. Todd reminds us that scaling is no longer the exotic knowledge of yesteryear and that the travesty of focusing purported precious resources on scaling is an overstatement.
To be fair, Dharmesh is not proposing that problems of scaling be ignored. Rather, he's recommending people avoid prematurely optimizing for scale too early in the process.
It is indeed a delicate balance, as are all interesting problems in architecture and design. Besides, we've all grown up with the warning to avoid premature optimization. It's been hammered into our brains.
Here's my problem.
It's a fundamental mistake to frame scalability as an optimization problem.
Scalability fall into the non-functional requirements bucket. It keeps company with a shady cast of characters - security, maintainability, usability, and all the other *ilities.
The primary challenge with non-functional requirements is they tend to pose the risk of significant rework if not taken into account early in the architectural and design phases of a projects. This is where the real skill comes in. If you're in a waterfall mode, you can hope you do an effective job eliciting an accurate picture of the non-functional requirements. If you're in an agile mode, you can hope you do an effective job refactoring the code as you evolve the idea. In both cases, the primary goal is to avoid the decision of whether to implement dramatic amounts of rework or whether to scuttle the ship.
If a particular operation needs to complete in less than 3 seconds and the initial implementation takes 30 seconds, this is not a problem of optimization - something is flawed. To be sure, you might be able to rationalize that future improvements will shave it down to 3 seconds, but most audience members would suspect breakage rather than a lack of optimization.
If a web service is targeted for a million users, the basic framework must be capable of evolving from the initial user base of two. The design is fundamentally lacking if one cannot provide a rational roadmap between these two numbers.
Optimization seldom crops up as a non-functional requirement, except in cases where initial performance is disappointing. The same cannot be said for scalability.
Ok, here's one more way to illustrate the point.
Fail to factor security into a design. Go ahead, I dare you.
Fail to factor maintainability into a design. You'll sell it before it becomes a real problem, right?
Fail to factor usability into the design. Hmmm... will that affect your user base?
Fail to factor scalability into the de...........
On the other hand, ignore scaling. It makes for minutes of entertainment on slashdot.
The heart of the conversation is a question regarding how much attention should be paid to scalability when in the early stages of a startup. Dharmesh suggests not worrying about scalability too early. Todd reminds us that scaling is no longer the exotic knowledge of yesteryear and that the travesty of focusing purported precious resources on scaling is an overstatement.
To be fair, Dharmesh is not proposing that problems of scaling be ignored. Rather, he's recommending people avoid prematurely optimizing for scale too early in the process.
It is indeed a delicate balance, as are all interesting problems in architecture and design. Besides, we've all grown up with the warning to avoid premature optimization. It's been hammered into our brains.
Here's my problem.
It's a fundamental mistake to frame scalability as an optimization problem.
Scalability fall into the non-functional requirements bucket. It keeps company with a shady cast of characters - security, maintainability, usability, and all the other *ilities.
The primary challenge with non-functional requirements is they tend to pose the risk of significant rework if not taken into account early in the architectural and design phases of a projects. This is where the real skill comes in. If you're in a waterfall mode, you can hope you do an effective job eliciting an accurate picture of the non-functional requirements. If you're in an agile mode, you can hope you do an effective job refactoring the code as you evolve the idea. In both cases, the primary goal is to avoid the decision of whether to implement dramatic amounts of rework or whether to scuttle the ship.
If a particular operation needs to complete in less than 3 seconds and the initial implementation takes 30 seconds, this is not a problem of optimization - something is flawed. To be sure, you might be able to rationalize that future improvements will shave it down to 3 seconds, but most audience members would suspect breakage rather than a lack of optimization.
If a web service is targeted for a million users, the basic framework must be capable of evolving from the initial user base of two. The design is fundamentally lacking if one cannot provide a rational roadmap between these two numbers.
Optimization seldom crops up as a non-functional requirement, except in cases where initial performance is disappointing. The same cannot be said for scalability.
Ok, here's one more way to illustrate the point.
Fail to factor security into a design. Go ahead, I dare you.
Fail to factor maintainability into a design. You'll sell it before it becomes a real problem, right?
Fail to factor usability into the design. Hmmm... will that affect your user base?
Fail to factor scalability into the de...........
On the other hand, ignore scaling. It makes for minutes of entertainment on slashdot.
No comments:
Post a Comment