I am not sure I am getting it. For example where does that curve come from ?
I would agree that the value of a software would be somewhat linear to the numbers of users / money they would agree to put on it. And I would agree that to get more users, you likely need "greater" software... Faster, more scalable, with more features yet manageable and usable. Because not all users have the same needs.
On the opposite, the cost of software is exponential to its size. The bigger, the older, the more feature it has, the more it cost to just maintain it and to add new features. Up to a point when not so profound changes take billions of investment. At some point, it is not worth it as the cost is bigger than the expected benefit.
Even if the design is the best in the world, there no way arround that. Agree that we all try to improve our design, but the best ones are the one that actually allow for low coupled independant part to be replaced at any time without impact on the overall system. More or less the best designs, are the one that make capilizing long term of a given code uncessary.
Most API/libraries that are 10 years or older are not used anymore. Actually, out of all websites/app software. Only a few are kept. Not necessarilly the best coded, but the ones that survived because their user base is still there.
Software is really an area where winner take it all. Most startup/companies also completely shift their business model and use cases over time. Simply to adapt, to survive. How would have helped netflix recently if they made their DVD exchange system 10 time better now they stream video over the internet? Their business and their software requirement are completely different than when they started.
You have to be able to fail fast, to iterate and evolve. For that using on the shelf architectures/lib/components and getting things done that matter to your client/user base is more important than a clean design.
The day you found your niche, where to grows and how to do it, there always time to consolidate. It isn't like the software effort you put on the first few years of work when you were small and trying to solve a different problem would be that usefull anymore.
But I agree that in term of high level abstractions. Things maybe beyond a single component/software but more overal architecture can help tremendously.
Another comment speak of amazon. They indistrialized their SOA architecture. So their bottleneck might very well be too chatty app at time or evolution of exchange format, but they can easily had a new component, replace a old one with a different implementation and so on.
Using the cloud concept and scalable architecture, including not having a single centralized database, they can scale infinitely.
And they actually don't care what OS/language/lib whatever a component use. If the team just replaced all the code or not. Because that system is modular it can evolve independantly, part by part... Except again when they need to change/update the exchange format. This is costly.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I am not sure I am getting it. For example where does that curve come from ?
I would agree that the value of a software would be somewhat linear to the numbers of users / money they would agree to put on it. And I would agree that to get more users, you likely need "greater" software... Faster, more scalable, with more features yet manageable and usable. Because not all users have the same needs.
On the opposite, the cost of software is exponential to its size. The bigger, the older, the more feature it has, the more it cost to just maintain it and to add new features. Up to a point when not so profound changes take billions of investment. At some point, it is not worth it as the cost is bigger than the expected benefit.
Even if the design is the best in the world, there no way arround that. Agree that we all try to improve our design, but the best ones are the one that actually allow for low coupled independant part to be replaced at any time without impact on the overall system. More or less the best designs, are the one that make capilizing long term of a given code uncessary.
Most API/libraries that are 10 years or older are not used anymore. Actually, out of all websites/app software. Only a few are kept. Not necessarilly the best coded, but the ones that survived because their user base is still there.
Software is really an area where winner take it all. Most startup/companies also completely shift their business model and use cases over time. Simply to adapt, to survive. How would have helped netflix recently if they made their DVD exchange system 10 time better now they stream video over the internet? Their business and their software requirement are completely different than when they started.
You have to be able to fail fast, to iterate and evolve. For that using on the shelf architectures/lib/components and getting things done that matter to your client/user base is more important than a clean design.
The day you found your niche, where to grows and how to do it, there always time to consolidate. It isn't like the software effort you put on the first few years of work when you were small and trying to solve a different problem would be that usefull anymore.
But I agree that in term of high level abstractions. Things maybe beyond a single component/software but more overal architecture can help tremendously.
Another comment speak of amazon. They indistrialized their SOA architecture. So their bottleneck might very well be too chatty app at time or evolution of exchange format, but they can easily had a new component, replace a old one with a different implementation and so on.
Using the cloud concept and scalable architecture, including not having a single centralized database, they can scale infinitely.
And they actually don't care what OS/language/lib whatever a component use. If the team just replaced all the code or not. Because that system is modular it can evolve independantly, part by part... Except again when they need to change/update the exchange format. This is costly.