Comments on: The Case Against Insensitivity http://mjtsai.com/blog/2007/12/02/the-case-against-insensitivity/ Thu, 08 Jan 2009 18:29:10 +0000 http://wordpress.org/?v=2.5.1 By: Michael http://mjtsai.com/blog/2007/12/02/the-case-against-insensitivity/#comment-199030 Michael Thu, 20 Dec 2007 15:57:03 +0000 http://mjtsai.com/blog/2007/12/02/the-case-against-insensitivity/#comment-199030 LKM: Well, I don't think anyone was arguing for clean code at the expense of the UI. On the contrary, the whole point of discussing these issues early is so that if there needs to be a transition, developers can have the guidelines and APIs that they need ahead of time, thus making the transition as smooth as possible. It wouldn’t just be dumped on the users in rough form. In this case, HFSX already exists, so it would be possible to test all this stuff before the Future Filesystem is even ready. Ultimately, the developer has to decide on the best way to serve the user. Sometimes this may mean reducing technical debt, othertimes not. LKM: Well, I don't think anyone was arguing for clean code at the expense of the UI. On the contrary, the whole point of discussing these issues early is so that if there needs to be a transition, developers can have the guidelines and APIs that they need ahead of time, thus making the transition as smooth as possible. It wouldn’t just be dumped on the users in rough form. In this case, HFSX already exists, so it would be possible to test all this stuff before the Future Filesystem is even ready.

Ultimately, the developer has to decide on the best way to serve the user. Sometimes this may mean reducing technical debt, othertimes not.

]]> By: LKM http://mjtsai.com/blog/2007/12/02/the-case-against-insensitivity/#comment-199024 LKM Thu, 20 Dec 2007 15:38:03 +0000 http://mjtsai.com/blog/2007/12/02/the-case-against-insensitivity/#comment-199024 Of course, unmaintainable code makes development more expensive and may lead to stagnation (which, by the way, is not always bad - sometimes, users don't really want new features - but that is another subject entirely). I would also not advocate ignoring problems until they create usability issues. If you can make code more maintainable without sacrificing the UI, do it. However, when given the choice between clean code and a better UI, I always go for the better UI, because that's what'll help users. It's also worth noting that you have between 1 and 100 developers working on any given software project who are inconvenienced by crappy code. Often, you have thousands or hundreds of thousands of users of the same software project who end up being inconvenienced by crappy UI. It's obvious to me who should get the priority here, especially since we developers are paid by our users :-) As developers, it's not our job to make our own lives easier. It's our job to make our users' lives easier. That means solving hard issues so our users don't have to. Of course, unmaintainable code makes development more expensive and may lead to stagnation (which, by the way, is not always bad - sometimes, users don't really want new features - but that is another subject entirely). I would also not advocate ignoring problems until they create usability issues. If you can make code more maintainable without sacrificing the UI, do it.

However, when given the choice between clean code and a better UI, I always go for the better UI, because that's what'll help users.

It's also worth noting that you have between 1 and 100 developers working on any given software project who are inconvenienced by crappy code. Often, you have thousands or hundreds of thousands of users of the same software project who end up being inconvenienced by crappy UI. It's obvious to me who should get the priority here, especially since we developers are paid by our users :-)

As developers, it's not our job to make our own lives easier. It's our job to make our users' lives easier. That means solving hard issues so our users don't have to.

]]> By: Michael http://mjtsai.com/blog/2007/12/02/the-case-against-insensitivity/#comment-199020 Michael Thu, 20 Dec 2007 15:22:36 +0000 http://mjtsai.com/blog/2007/12/02/the-case-against-insensitivity/#comment-199020 LKM: "Nobody cares what your code looks like," but they do care about how you're able to evolve that code. The original Mac OS code was ugly and unmaintainable. As a result, the OS stagnated. Microsoft never modernized their Visual Basic code, and so they had to drop it from Mac Office 2008. I'm not saying this is one of those cases, but I disagree with the idea that problems should always be left to fester until they create a user-facing problem. By the time you absolutely must fix the problem, there may be too much technical debt. LKM: "Nobody cares what your code looks like," but they do care about how you're able to evolve that code. The original Mac OS code was ugly and unmaintainable. As a result, the OS stagnated. Microsoft never modernized their Visual Basic code, and so they had to drop it from Mac Office 2008. I'm not saying this is one of those cases, but I disagree with the idea that problems should always be left to fester until they create a user-facing problem. By the time you absolutely must fix the problem, there may be too much technical debt.

]]> By: LKM http://mjtsai.com/blog/2007/12/02/the-case-against-insensitivity/#comment-199014 LKM Thu, 20 Dec 2007 15:07:03 +0000 http://mjtsai.com/blog/2007/12/02/the-case-against-insensitivity/#comment-199014 http://www.codinghorror.com/blog/archives/001022.html :-) http://www.codinghorror.com/blog/archives/001022.html

:-)

]]> By: LKM http://mjtsai.com/blog/2007/12/02/the-case-against-insensitivity/#comment-189951 LKM Tue, 04 Dec 2007 08:46:04 +0000 http://mjtsai.com/blog/2007/12/02/the-case-against-insensitivity/#comment-189951 >I think it's a user experience issue that could >be solved at the framework level So then you get inconsistencies between Carbon, Cocoa, X11, Java, plain old C apps, and so on. I think it's annoying enough that (for example) text components work differently in different apps, depending on what Frameworks they use. Apple has basically spent the last 6 years getting rid of inconsistencies between Carbon and Cocoa. Why introduce new ones? More robust application code is useless if it's perceived by the user as less robust because of slight inconsistencies. >I think it's a user experience issue that could
>be solved at the framework level

So then you get inconsistencies between Carbon, Cocoa, X11, Java, plain old C apps, and so on. I think it's annoying enough that (for example) text components work differently in different apps, depending on what Frameworks they use. Apple has basically spent the last 6 years getting rid of inconsistencies between Carbon and Cocoa. Why introduce new ones?

More robust application code is useless if it's perceived by the user as less robust because of slight inconsistencies.

]]> By: Michael http://mjtsai.com/blog/2007/12/02/the-case-against-insensitivity/#comment-189887 Michael Tue, 04 Dec 2007 05:08:16 +0000 http://mjtsai.com/blog/2007/12/02/the-case-against-insensitivity/#comment-189887 Hugh: OK, you’re right about the domain name, but I still don’t see the problem. Domain case is defined not to matter, so we’re all sloppy with it. In the path, it does matter, and yet this isn’t much of a problem because users have clickable links, bookmarks, and search engines. Likewise, for files they would still have open panels, drag and drop, etc. Hugh: OK, you’re right about the domain name, but I still don’t see the problem. Domain case is defined not to matter, so we’re all sloppy with it. In the path, it does matter, and yet this isn’t much of a problem because users have clickable links, bookmarks, and search engines. Likewise, for files they would still have open panels, drag and drop, etc.

]]> By: Hugh http://mjtsai.com/blog/2007/12/02/the-case-against-insensitivity/#comment-189883 Hugh Tue, 04 Dec 2007 04:22:20 +0000 http://mjtsai.com/blog/2007/12/02/the-case-against-insensitivity/#comment-189883 Which is exactly the point I was trying to make: the correct capitalization of your domain name is mjtsai.COM not .com. (See the root zone file of a DNS server for examples of canonical names at the top level.) If the DNS system wasn't "hiding the details" you'd be getting a lot less email! (OK, maybe that could be considered a good thing...) Which is exactly the point I was trying to make: the correct capitalization of your domain name is mjtsai.COM not .com. (See the root zone file of a DNS server for examples of canonical names at the top level.)

If the DNS system wasn't "hiding the details" you'd be getting a lot less email! (OK, maybe that could be considered a good thing...)

]]> By: Michael http://mjtsai.com/blog/2007/12/02/the-case-against-insensitivity/#comment-189871 Michael Tue, 04 Dec 2007 03:42:27 +0000 http://mjtsai.com/blog/2007/12/02/the-case-against-insensitivity/#comment-189871 Hugh: I always use lowercase for domain names, and that’s what the mailto URL uses. As a user, it doesn't much matter to me whether the domain name is case-sensitive because the rest of the URL generally is, anyway. Hugh: I always use lowercase for domain names, and that’s what the mailto URL uses. As a user, it doesn't much matter to me whether the domain name is case-sensitive because the rest of the URL generally is, anyway.

]]> By: Hugh http://mjtsai.com/blog/2007/12/02/the-case-against-insensitivity/#comment-189797 Hugh Mon, 03 Dec 2007 23:59:13 +0000 http://mjtsai.com/blog/2007/12/02/the-case-against-insensitivity/#comment-189797 Michael, you don't appear to know the correct capitalization of your DNS domain name, judging by the 'mailto' URL at the bottom of this page. Aren't you glad you don't have to? Most of those arguments - that it's poorly defined for non-ASCII, that it's a layering violation, that it forces layering violations on other code and is contagious - would apply equally well to DNS name lookups and email. (The difference is that thanks to the DNS spec, everyone does it the same way.) cheers, Hugh Michael, you don't appear to know the correct capitalization of your DNS domain name, judging by the 'mailto' URL at the bottom of this page. Aren't you glad you don't have to?

Most of those arguments - that it's poorly defined for non-ASCII, that it's a layering violation, that it forces layering violations on other code and is contagious - would apply equally well to DNS name lookups and email. (The difference is that thanks to the DNS spec, everyone does it the same way.)

cheers,
Hugh

]]> By: Michael http://mjtsai.com/blog/2007/12/02/the-case-against-insensitivity/#comment-189738 Michael Mon, 03 Dec 2007 17:19:32 +0000 http://mjtsai.com/blog/2007/12/02/the-case-against-insensitivity/#comment-189738 It's not at all clear to me that this is the tradeoff. I think it's a user experience issue that could be solved at the framework level, potentially leading to a better UI and more robust application code. Hiding the details from the frameworks and applications only makes it appear that the filesystem took care of everything. It's not at all clear to me that this is the tradeoff. I think it's a user experience issue that could be solved at the framework level, potentially leading to a better UI and more robust application code. Hiding the details from the frameworks and applications only makes it appear that the filesystem took care of everything.

]]>