4 ms·
Unfortunately, "plan for the future" is too general to be workable; this is how you get architecture astronauts using UUIDs and multiple levels of indirection f
by saulpw 2y ago
Unfortunately, "plan for the future" is too general to be workable; this is how you get architecture astronauts using UUIDs and multiple levels of indirection for a 160KB floppy.
The future you can plan for, is specifically 10x more. If you have 160KB floppies, then design as though there might be 1.6MB floppies. You'll have to revisit your design anyway for the emergent complexities of the next order of magnitude, but this will at least give you some breathing room.
Designing for 100x more than your system has is overengineering. You have no idea what the needs of the future are, and the design for a 100x system will be detrimental for your current 1x system, and likely sink it. So ironically planning for 100x means you probably won't get there.
- antonkochubey 2y agoWindows XP lived thorough 6 GB (minimum requirement - 1.5 GB, but I don't recall seeing drives less than six gigs at the time) to 2 TB HDD's. That's literally a 333x increase, which NTFS handled just fine. From min requirement it'd be a 1000x increase.
- akira2501 2y ago> That's literally a 333x increase Yet that's only going from 2^32 to 2^40.
- jeroenhd 2y agoWindows XP's default clustering (well, until SP2 at least) "only" allowed for 128GB disks. The cluster size was later increased. The 2TB limit was generally a limit for the BIOS code rather than an OS limit, as NTFS will happily scale beyond 2TB. Windows NT 4 already contained the code necessary to allow for up to 16 exabyte partitions (https://web.archive.org/web/20010208131204/http://support.microsoft.com/support/kb/articles/Q224/5/26.ASP https://web.archive.org/web/20010208131204/http://support.mi...), but the hardware it was running on probably didn't support anything bigger than a few terabytes. Sure, every text file takes up at least 2MB, but with an exabyte disk, you probably don't care about wasting sectors like that.
- paulmd 2y agoa system that can be scaled 333x or pushed into radically different allocation patterns by changing one or two constants seems like an odd choice for arguing that YAGNI and you shouldn't plan for anything beyond 10x/should plan for a system rearchitecture at that scale. That seems very much like a system that thought ahead and picked meaningful knobs to allow drastic changes in use-case to suit the situation.
- kalleboo 2y agoWhen XP came out, you already had 100 GB consumer drives on the market that it had to support out of the box, so that's where I'd put the design requirements "starting point". That makes it only one order of magnitude bigger, similar to the 10x.
- anthk 2y agoA year after the XP release, disks with 40GB and 60GB were pretty common. Ideally XP required 10GB-20GB for a casual usage.
- banannaise 2y agoDesigning for 10x will probably get you to 100x just fine anyway. Scaling up the first 10x is already in the design, so that design only needs to scale another 10x. Scaling that second 10x will probably be just fine, if not ideal.
- taneq 2y agoExactly. Perfect is the enemy of good, and good often the enemy of pragmatic (assuming we're using 'good' in the sense of 'what most engineers would think was a complete solution' not in the enlightened sense of 'meeting our actual needs for the near future').
- saagarjha 2y agoYou don’t have to plan for the exact details. Just give yourself space to expand (e.g. by adding a version number) and you’ll be fine.
- eternityforest 2y agoI think the exception is when 100x tools already exist, a d the application is so tiny you don't care about overhead. If I only need to store 20 of them on that floppy, why wouldn't I use UUIDs? Anything else would be more work and likely less flexibility.