10 ms·

Writing scalable software is all about being as flexible as possible. If system load expanded by an order of magnitude and the original design wasn't flexible e

Writing scalable software is all about being as flexible as possible. If system load expanded by an order of magnitude and the original design wasn't flexible enough to scale with the load, that's a bad software design.

wildrhythms 7y ago
Sure but then risk being dinged by the customer/management for "over-engineering something simple." How do you determine where the cut off point is?
TuringNYC 7y ago
Or perhaps the first project was budgeted to only handle limited scale and prove feasibility. In which case it was a success, and now that feasibility is proven, scale can be budgeted for. I mean, if people tried to build for mega scale from day one, every pie in the sky idea I have would start with Spark clusters and load balancers and Kubernetes...which obviously is all expensive, time consuming, and may simply not be worth the cost given the business objective.
paulddraper 7y ago
!! Designing SQLitec data store and designing Cassandra data store are rather different.
- pessimizer 7y ago
  True, but initially decoupling the business logic from the specifics of data retrieval would allow you to write an abstraction layer when you need to switch stores rather than having to rewrite the entire thing.
  - nomel 7y ago
    Fighting for the independence of these separate pieces and layers of abstraction is one of the most difficult problems I’ve had being a developer. Management always wants time saving, “well if we just make these parts dependent, the fix will be much quicker”, requiring deep explanations that requires justifying some “hypothetical” scenario in the future (which always ends up being in a few months). Other developers, not familiar with the deeper understanding of the problem being solved, knowingly or unknowingly implement the shortcuts, adding technical debt and hidden complexity. I don’t know what the balance is, but I find the only way to make a long lived system is to fight hard for the separation of concerns, or slowly fall prey to chaos.
    - AnimalMuppet 7y ago
      > (which always ends up being in a few months) I have seen something about technical debt that says that it's a win over the span of weeks, but a loss by the time of months.
firethief 7y ago
Worrying about scalability before you need it is a good way to ensure that you won't.
twblalock 7y ago
If you try to build the most flexible, scalable solution on day one, you are very likely to make the wrong predictions about the architecture you will need in the future. You will probably need to rewrite the software anyway.
crimsonalucard 7y ago
A lot of people might disagree, and this is just my opinion, but if you are using object oriented programming than in 99% of all cases you are not being as flexible as possible. Tying methods to data is an inflexibility. With sufficient complexity under OOP you will always be writing code that feels like it is poorly designed because the paradigm promotes poor design and lack of flexibility.
- kaoD 7y ago
  > Tying methods to data is an inflexibility. Tying methods to data is an inevitability (whether it is on run- or compile- time). Can you give me an example of a function that does not depend on the data it operates on? What makes OOP wrong is not tying methods to data, but tying data to ontologies. Limiting a function to operating on what something "is" is an artificial limitation. Limiting a function to operating on what something "has" or "can do" is a logical consequence.
  - nradov 7y ago
    You can accomplish exactly that in OOP with careful use of multiple inheritance or interfaces.
    - kaoD 7y ago
      That's kinda my point. Interfaces should be the main abstraction. I don't think multiple inheritance (or inheritance at all) is particularly useful. Composition over inheritance. Interfaces over inheritance. I don't care what something "is" and I don't think ontologies (classes, inheritance) are particularly useful as a means of abstraction.
  - crimsonalucard 7y ago
    >Tying methods to data is an inevitability (whether it is on run- or compile- time). Can you give me an example of a function that does not depend on the data it operates on? I mean tying methods to data via a class. A instantiated class is a structure that has data and has methods specific to operating on said data. Either way, any function that takes void input and with any return type is an example of a function that does not depend on data, but that wasn't my point. Note that a function is different from a method contextually speaking. >What makes OOP wrong is not tying methods to data, but tying data to ontologies. Limiting a function to operating on what something "is" is an artificial limitation. Limiting a function to operating on what something "has" or "can do" is a logical consequence. We may be talking about the same thing. Though I'm not sure what you mean by this: "Limiting a function to operating on what something "is" is an artificial limitation. Limiting a function to operating on what something "has" or "can do" is a logical consequence." Can you please clarify?

wildrhythms 7y ago

Sure but then risk being dinged by the customer/management for "over-engineering something simple." How do you determine where the cut off point is?

TuringNYC 7y ago

Or perhaps the first project was budgeted to only handle limited scale and prove feasibility. In which case it was a success, and now that feasibility is proven, scale can be budgeted for. I mean, if people tried to build for mega scale from day one, every pie in the sky idea I have would start with Spark clusters and load balancers and Kubernetes...which obviously is all expensive, time consuming, and may simply not be worth the cost given the business objective.

paulddraper 7y ago

!! Designing SQLitec data store and designing Cassandra data store are rather different.

pessimizer 7y ago
True, but initially decoupling the business logic from the specifics of data retrieval would allow you to write an abstraction layer when you need to switch stores rather than having to rewrite the entire thing.
- nomel 7y ago
  Fighting for the independence of these separate pieces and layers of abstraction is one of the most difficult problems I’ve had being a developer. Management always wants time saving, “well if we just make these parts dependent, the fix will be much quicker”, requiring deep explanations that requires justifying some “hypothetical” scenario in the future (which always ends up being in a few months). Other developers, not familiar with the deeper understanding of the problem being solved, knowingly or unknowingly implement the shortcuts, adding technical debt and hidden complexity. I don’t know what the balance is, but I find the only way to make a long lived system is to fight hard for the separation of concerns, or slowly fall prey to chaos.
  - AnimalMuppet 7y ago
    > (which always ends up being in a few months) I have seen something about technical debt that says that it's a win over the span of weeks, but a loss by the time of months.

firethief 7y ago

Worrying about scalability before you need it is a good way to ensure that you won't.

twblalock 7y ago

If you try to build the most flexible, scalable solution on day one, you are very likely to make the wrong predictions about the architecture you will need in the future. You will probably need to rewrite the software anyway.

crimsonalucard 7y ago

A lot of people might disagree, and this is just my opinion, but if you are using object oriented programming than in 99% of all cases you are not being as flexible as possible. Tying methods to data is an inflexibility. With sufficient complexity under OOP you will always be writing code that feels like it is poorly designed because the paradigm promotes poor design and lack of flexibility.

kaoD 7y ago
> Tying methods to data is an inflexibility. Tying methods to data is an inevitability (whether it is on run- or compile- time). Can you give me an example of a function that does not depend on the data it operates on? What makes OOP wrong is not tying methods to data, but tying data to ontologies. Limiting a function to operating on what something "is" is an artificial limitation. Limiting a function to operating on what something "has" or "can do" is a logical consequence.
- nradov 7y ago
  You can accomplish exactly that in OOP with careful use of multiple inheritance or interfaces.
  - kaoD 7y ago
    That's kinda my point. Interfaces should be the main abstraction. I don't think multiple inheritance (or inheritance at all) is particularly useful. Composition over inheritance. Interfaces over inheritance. I don't care what something "is" and I don't think ontologies (classes, inheritance) are particularly useful as a means of abstraction.
- crimsonalucard 7y ago
  >Tying methods to data is an inevitability (whether it is on run- or compile- time). Can you give me an example of a function that does not depend on the data it operates on? I mean tying methods to data via a class. A instantiated class is a structure that has data and has methods specific to operating on said data. Either way, any function that takes void input and with any return type is an example of a function that does not depend on data, but that wasn't my point. Note that a function is different from a method contextually speaking. >What makes OOP wrong is not tying methods to data, but tying data to ontologies. Limiting a function to operating on what something "is" is an artificial limitation. Limiting a function to operating on what something "has" or "can do" is a logical consequence. We may be talking about the same thing. Though I'm not sure what you mean by this: "Limiting a function to operating on what something "is" is an artificial limitation. Limiting a function to operating on what something "has" or "can do" is a logical consequence." Can you please clarify?