4 ms·

There are definite practical limits in Excel. Even at 100k rows, some of the more complex financial models we have made get very difficult to work with. We’v

by Vaslo 6y ago

There are definite practical limits in Excel. Even at 100k rows, some of the more complex financial models we have made get very difficult to work with. We’ve spent days learning and trying new ways to speed them up (never use Vlookup or offset, etc) and they became usable but still frustrating. I guess the biggest upside is that it’s forced my team to go out and learn SQL, Python, etc. However that has it’s own downside because we are the only ones in our division that know these tools, so we get stuck maintaining stuff that we shouldn’t!

bob1029 6y ago
Having everyone on the team competent in SQL is not something that is an unreasonable objective. Even project managers and executives could benefit from knowing how to write their own queries against various data sources. As wizened developers, we can assist our more business-like coworkers by developing views and reporting databases that help to present a more consistent and higher-order perspective of the world. Just having a document that lists out examples of SQL they can use is 99% of what most people need to get bootstrapped. Getting your problem domains modeled in SQL and using the appropriate form of normalization is foundational for managing non-trivial levels of complexity in larger projects. For me, non-trivial complexity means any domain model with more than 10 related types or more than 100 total properties to deal with. Relational modeling is one of the most powerful abstractions we have available for working with anything that goes beyond the 3 spatial dimensions that we can see with our eyeballs. I have dealt with queries in factory automation that join over 40 tables to produce some important projection. You could make a bunch of assumptions about how the domain model should be shaped in some complex object graph monstrosity and then stick it into MongoDB, or you can leave it neatly organized and indexed such that any reasonable query can be made of the data to produce virtually any shape of output you need. With all of that in mind, Excel is still one of the most powerful tools on your computer for documenting virtually anything. Any problem domain can be represented as tables of things and relations between them. Anyone can figure out the most important parts of this tool with just a few minutes of screwing around with it. It is trivial to take a model from someone's xlsx and turn it into proper SQL tables and then slap a front-end and business logic around it. When someone wants me to write a new piece of software for a new problem area, we always start with types, properties, and relationships between these things. Excel is a perfect fit for the first phase of any software project.
NicoJuicy 6y ago
Share linqpad scripts?

by Vaslo 6y ago

bob1029 6y ago

Having everyone on the team competent in SQL is not something that is an unreasonable objective. Even project managers and executives could benefit from knowing how to write their own queries against various data sources. As wizened developers, we can assist our more business-like coworkers by developing views and reporting databases that help to present a more consistent and higher-order perspective of the world. Just having a document that lists out examples of SQL they can use is 99% of what most people need to get bootstrapped. Getting your problem domains modeled in SQL and using the appropriate form of normalization is foundational for managing non-trivial levels of complexity in larger projects. For me, non-trivial complexity means any domain model with more than 10 related types or more than 100 total properties to deal with. Relational modeling is one of the most powerful abstractions we have available for working with anything that goes beyond the 3 spatial dimensions that we can see with our eyeballs. I have dealt with queries in factory automation that join over 40 tables to produce some important projection. You could make a bunch of assumptions about how the domain model should be shaped in some complex object graph monstrosity and then stick it into MongoDB, or you can leave it neatly organized and indexed such that any reasonable query can be made of the data to produce virtually any shape of output you need. With all of that in mind, Excel is still one of the most powerful tools on your computer for documenting virtually anything. Any problem domain can be represented as tables of things and relations between them. Anyone can figure out the most important parts of this tool with just a few minutes of screwing around with it. It is trivial to take a model from someone's xlsx and turn it into proper SQL tables and then slap a front-end and business logic around it. When someone wants me to write a new piece of software for a new problem area, we always start with types, properties, and relationships between these things. Excel is a perfect fit for the first phase of any software project.

NicoJuicy 6y ago

Share linqpad scripts?