It isn't scalable!
That was the first thing out of my mouth when I saw a diagram the day before yesterday. The diagram was of a domain model and included four entities.
No, I can't see the future and extrapolate from customer/order/order lines whatever the system is going to scale or not. I wasn't talking about the system scalability at all. I was thinking of using the diagram as the main means for expressing concepts. A single diagram is just not a good solution for showing any sort of a complex concept. At that particular case, the diagram is a view on top of a model, so the issue wasn't really relevant,
It did, however, made me think about my use of scalable. I make the word work for its living, because for me, it means:
- Scalable traditional - can we make the system handle more operations
- Scalable complexity - when we increase the complexity of the problem, do we need to increase the complexity of the solution by the same amount, by doubling or tripling the complexity?
- Scalable maintainability - how much work do I need to do in order to maintain this application? Is the work required going to rapidly increase over time?
- Scalable size - as the project grow, do I have the facilities for it? That means, can I split the work between developers / teams? Will VS become extremely slow with huge amount of projects? Do I have an SCM strategy planned.
- Scalable management - as the project grow, how are we going to manage that?
- Scalable IT - as the project grows, do we have the tooling in place to actually understand the application in production. Remote Debugging doesn't work.
Comments
I don't think the term scalable/scalability normally is used in this broad context. I use it only for your "traditional" one and use the term "maintainability" for the rest.
Comment preview