This is *somewhat* along the same lines as the book "The Mythical Man-Month". Though it was written some 25+ years ago, it still applies. It talks, in part, about taking the time to develop applications with less inter-dependence so if need be, you could simply add more people to the project. The authors argument was that if different parts of the application heavily relied upon each other, it would take too much time to get every new person up to speed, then if you had more free standing modules that could be brought together when finished. Not really a new concept now, but a good read none the less.
One argument that I see a lot about taking the time to code highly scalable apps is that it would be more monetarily beneficial to code highly maintainable apps, rather then scalable. Their argument is that it's cheaper to just add more hardware to add scalability, but you can't just add hardware to add maintainability. I have to admit that it makes some sense, but I think you should still be at least mindful of how your coding and implementations are going to effect scalability.
A new meaning indeed... what's most interesting for me here is that the author and snekse both mention adding hardware resources to increase capacity. That means that the software must be scalable already, otherwise more hardware wouldn't solve the problem (see paragraph 2)!
Developers still have to write scalable code, but this is becoming easier and easier as a lot of the enabling technology is commoditised - networking, file handling and so on are taken care of in many development environments today. Putting it another way, it is a lot more difficult than it used to be to write code with serious bottlenecks.
What developers don't (have to) do any more is *optimise*. As long as the application scales, sub-optimal code can be taken care of by adding more cheap hardware, which has become cheaper than optimisation time from developers (the 80/20 rule probably applies here).
I like the main thrust of the article, though - a people-centric approach to development has to be the way ahead given the failure of the engineering approaches of the past. Snekse says that you can't add hardware to add maintainability, and I would endorse that by saying that the only people who can add quality are the developers.
Comments
Mythical Man Month
Scalability assumed
A new meaning indeed... what's most interesting for me here is that the author and snekse both mention adding hardware resources to increase capacity. That means that the software must be scalable already, otherwise more hardware wouldn't solve the problem (see paragraph 2)!
Developers still have to write scalable code, but this is becoming easier and easier as a lot of the enabling technology is commoditised - networking, file handling and so on are taken care of in many development environments today. Putting it another way, it is a lot more difficult than it used to be to write code with serious bottlenecks.
What developers don't (have to) do any more is *optimise*. As long as the application scales, sub-optimal code can be taken care of by adding more cheap hardware, which has become cheaper than optimisation time from developers (the 80/20 rule probably applies here).
I like the main thrust of the article, though - a people-centric approach to development has to be the way ahead given the failure of the engineering approaches of the past. Snekse says that you can't add hardware to add maintainability, and I would endorse that by saying that the only people who can add quality are the developers.