5 ms·
Writing "good code" is always preferable, especially when you do things "right" the first time. But what happens when you want to refactor something when 1) it
by mbenjaminsmith 14y ago
Writing "good code" is always preferable, especially when you do things "right" the first time.
But what happens when you want to refactor something when 1) it's not strictly necessary in terms of functionality and 2) it will cost the client some non-zero amount of money. You easily slip into a gray area that this visual example illustrates well. Sure there are differences but are they material to the overall design goals? It's hard to say yes.
There's no such thing as "giving a damn" in an absolute sense. It's hard to say that any software product is ever done. If that's the case then it's the programmer's / artist's responsibility to say when something is good enough for the project's current goals.
- calinet6 14y agoIf you had unlimited time and money, what would you do? The higher quality thing is still higher quality, regardless of time or value constraints. If you choose a lower quality path while acknowledging you're balancing time and money, you're still choosing lower quality. Realistically you can't achieve perfection (sometimes even completion) because you don't have unlimited time or money, and there are always new variables. But it is important to strive for that high quality as an ideal, even if you can never reach it. You know it is still better in some absolute sense. It's always out there as an intangible goal, and if you reach for it, you can understand and center on that balance beam even better.
- nahname 14y agoPerfection is unobtainable by it's very nature. If you froze the world and left the designer alone for centuries what came out would not be perfection. Don't kid yourself that it would be otherwise.
- calinet6 14y agoI never said it was even real. All I'm saying is that some things are higher quality than others, and the higher quality things are better. It's a simple tautology. I did say, "realistically you can't achieve perfection" which would appear to indicate that I'm not kidding myself here. Understanding quality in both the realistic obtainable realm, as well as the unobtainable more-pefect level allows you to differentiate the two, and make conscious decisions about the level of quality you're targeting as well as your ability to do so in reality. The higher unobtainable level of quality doesn't even have to be close to the perfect you're talking about—if you have time and money constraints, that unobtainable level of quality might be a lot lower than perfect. If you dismiss all levels of quality above a certain level as being this mythical unobtainable thing before even attempting to think about them in the abstract, then you've cut yourself off from a true understanding of the balance and compromise involved. Of course you can't achieve it, but that doesn't mean you shouldn't be aware of it. At some point this idea becomes a philosophical discussion and ceases to be useful. Just as at some point, your perfectionism becomes a philosophical endeavor and ceases to be useful. There is a balance where the pursuit is useful and complete.
- mbenjaminsmith 14y ago>> The higher quality thing is still higher quality, regardless of time or value constraints. If you choose a lower quality path while acknowledging you're balancing time and money, you're still choosing lower quality. Framed like that I would say "yes, I never want to deliver something of 'lower quality'", but in this case (the two interfaces) one really doesn't qualify as lower quality. We're talking about the difference between "good" and "slightly, almost imperceptibly better". Having said that I'm not a designer and maybe if I were I would have a different opinion about this particular case. >> But it is important to strive for that high quality as an ideal, even if you can never reach it. No, I think it's entirely possible to deliver high quality. But we do have to deal with the law of diminishing returns and it's up to us (programmers, designers) to know what's best for our client (or ourselves).
- sea6ear 14y agoBut this leads to stasis if you are given unlimited time and money. That is, if you did have your ideal constraints, would anything ever be produced? I read some short story (that I wish I remembered the title of) when I was a kid about the idea that achieving immortality on earth had caused people to stop producing anything useful in their quest for perfection.
- calinet6 14y agoI'm going to copy verbatim a comment I posted elsewhere in this thread. Apologies... I don't understand where people are getting the idea that we are to ignore balance, constraints, and reality in deciding how to complete a project. Absolutely not the case. We're talking about quality specifically, and why someone might choose to pay attention to finer details versus ignoring them. Your reasons for ignoring details might be perfectly valid and entirely appropriate. The project may not call for artistry and mastery. All very good points for a different discussion. Don't think for a moment that those who believe high quality is an important factor are implying that it is absolutely necessary. That is simply a false dilemma.
- scott_s 14y agoThe differences presented in this article, however, clearly fall into the category of "worth it" because of how minor they are. I think it's easy to imagine code analogues - such as coming up with good variable, class or function names.