Asking about limits means you are doing something wrong?

Jeff Atwood is an interesting character, and I love reading his blog. Usually I agree with what he insights; sometimes I don't. Today is a case of a little of both at the same time:

Coding Horror

There are two threads here of interest. The first is a response to a comment on Raymond Chen's blog ( saying that hitting system limits means you are doing something wrong. I agree with Jeff that trying to defend hard system limits is a losing battle: no matter where you put those limits, someone will have a requirement that exceeds them.

Chen spends a lot of pixels in the comments telling people why they are wrong for asking where limits are in various situations. One poster then claims that he and Raymond are the only ones with degrees in the thread comments... ad hominum attacks do not become *anyone*. Finally he edits the post to say that "I did say probably" and "The fact that you folks can come up with suggestions for the other 10% doesn't invalidate my point." Quite repentant I see.

When I started programming (insert old a picture of an old codger rocking on his porch here if you must), I had a 4K memory space to work in, and all other resources were similarly constrained. Of course we had to ask what the limits were: only a fool would have attempted to code *without* knowing where the limits were.

Today I code enterprise systems... and yes, I want to know where the limits are. Maximum simultaneous requests, memory limits, data base connection limits... these are the things that I think about because I need to know which direction to take my design. In fact, I would counter the "you probably have some rather serious design flaws" comment with "I need to create my design to fit within the box I'm put in". The idea that asking these questions means I'm doing something wrong flies in the face of history: operating systems, programming environments and third party libraries often have hard coded limits. I'm going to say it out loud here, *stupid* hard coded limits at that.

In a document management system I wrote using Microsoft's latest and greatest development tools, I have hit my head on a maximum path depth limit (the dreaded MAX_PATH). Because my clients use a nested structure (agency name, agent name, insured company name, policy type, document type, specific document) to store files with descriptive file names, the paths can get quite long. According to Chen's thinking: we are using the operating system wrong. 256 characters seems enough until you realize that the default application storage location is "C:\Documents and Settings\User Name\Application Data\Appliation Name". That's 68 characters right there, and the users haven't *done* anything yet. With a deeply nested, human readable set of folders, you are going to hit the limit in a hurry. But remember, "if you have to ask, you're probably doing something wrong."

(In fact, when asked about this limit in .NET, Microsoft bloggers have responded by saying exactly that: use shorter names and stop bugging us about operating system limits. Further, they suggested "falling back to 8.3 naming conventions" or "use GUIDs as folder names and don't nest in the file system". My, aren't these user friendly suggestions? If I have to resort to mangling user file names, I might as well store the files in database blobs instead of a filing system.)

This kind of arrogance is exactly what leads to hard limits (and more importantly, not *fixing them*), like the one that we hit with BIOS limits to hard drive sizes (that required stupid bios shims to be loaded), memory addressing limits in operating systems (that then require REALLY stupid workarounds [say hello EMM386!]) and countless other "well, it was good enough when we designed it" limits. The fact they exists is annoying, but a fact of life. Suggesting that asking *where they are* means you are doing something wrong is just an insult to anyone who actually bothers to think about how things should be done.

Jeff's specific limit that he hit is an odd one though, and is the second interesting thread in the discussion. My next post will question how he hit the limit in the first place (although I agree with his outrage at the *existence* of the limit). See you next post for that topic.