"If you have a problem domain that deals with thousands (or more) of types/facts/relations, you will quickly find that starting with code and how tightly you ca

"If you have a problem domain that deals with thousands (or more) of types/facts/relations, you will quickly find that starting with code and how tightly you can pack your data in memory to be a massive mistake." To be fair, this depends entirely on the business requirements of the software being designed. For example, a safety critical airbag deploy mechanism may need to make hard real time decisions so that memory layout (let alone dynamic allocation) is anything but "a massive mistake", or a file system may need to account for the spatial locality of corruption by writing superblock headers to different locations on disk. I was also thinking of software design, not business applications that can be solved with SQL, and specifically in the context of infrastructure systems designed by experts such as Jeff Dean or Martin Thompson.