4 ms·

>> The abstraction is just barely enough to get the job done [...] > Or, in other words, the perfect amount... Well no, because the job doesn't end when it's

>> The abstraction is just barely enough to get the job done [...] > Or, in other words, the perfect amount... Well no, because the job doesn't end when it's "done". Minecraft is the perfect example: In the earliest versions of the game, blocks were all basically homogenous cubes of some material, so they didn't need to be oriented. Later, blocks were added that did need to be rotated in various ways, e.g. torches, stairs. But each of these blocks had their own private system for choosing, storing, and rendering their orientation. These systems were often similar, but not identical. At this point, roughly half the blocks in the game are orientable in some way and there is still no generic orientation system. Such a system would have avoided massive amounts of redundant code, prevented many bugs, made the user experience more consistent, and made various 3rd party tools much easier to develop. "You ain't gonna need it" is a cop-out. You are going to need some things. The trick is anticipating which things, and it will definitely pay off if you can guess correctly.

deleted 15y ago
[deleted]
humbledrone 15y ago
Hmm, from what I can tell, Minecraft is fairly successful, despite it being a "perfect example" of not having enough abstraction. Of course, you fail to really acknowledge the risks of premature abstraction. Sure, if you could see the future, and know what patterns could be usefully factored out into abstractions, it would be good to start with those abstractions. But what happens if you incorrectly predict that an abstraction will be needed? You create a bunch of unnecessary framework code that is harder to understand, likely less efficient, and worst of all, you wasted time writing code that you didn't need. YAGNI is not a cop-out. The best way to create abstractions is from concrete examples. Write something once. Then, once you actually find yourself writing it twice, abstract it out. That guarantees that you don't waste time on things that you don't use. It also generally leads to better abstractions, because you have concrete use-cases to work from. Anyway, back to the Minecraft story, who are you to say that the game would be better if Notch followed the premature abstraction strategy? Isn't it possible, perhaps, that he would have wasted enough time implementing ivory towers of abstraction that he might have left out the features that actually made the game fun?
- extension 15y ago
  But what happens if you incorrectly predict that an abstraction will be needed? Then you made a mistake and hopefully learned something. I didn't say architecting software was easy or without risk, just that you can't avoid doing it by following simplistic rules. The best way to create abstractions is from concrete examples. Write something once. Then, once you actually find yourself writing it twice, abstract it out. It's nice when things go that way, but it's not the general case. Often, by the time there is a concrete use for abstraction, the damage is done. For example, adding network multiplayer to a game that has been architected for single player is a nightmare of hacks and duplicated code (Notch has explicitly lamented about that one). Anyway, back to the Minecraft story, who are you to say that the game would be better if Notch followed the premature abstraction strategy? Notch himself seems to be saying as much in that blog post. But that aside, I'm a fellow game developer who has spent dozens of hours reading and modifying the Minecraft code. Even after a round-trip of obfuscation, it tells the story of its creation quite vividly, and the theme of the story is "hack around it!" Though I still have tremendous admiration for the game and its developers.
  - teyc 15y ago
    Multiplayer mode can be extremely hard and can take any fun out of being an indie game developer. I'm still not sure if it is the right abstraction to work in on day one.
  - humbledrone 15y ago
    Regarding the construction of abstractions from day one: http://en.wikipedia.org/wiki/Opportunity_cost http://en.wikipedia.org/wiki/Opportunity_cost
  - humbledrone 15y ago
    > Then you made a mistake and hopefully learned something. Perhaps you learned that prematurely abstracting things is a waste of time?
  - goblin89 15y ago
    I think the point was that the source code doesn't make the game better or worse. A nightmare of hacks is fine as long as the product is great. IMO writing such code is sometimes even better, especially for a solo developer. If you aim to write beautiful code, it might eventually outweigh everything else, while giving a false impression that you're doing the right thing. Your goal is the product, not code. I'd argue that you can't focus on both (it's called ‘focus’ for a reason).
dextorious 15y ago
"""Well no, because the job doesn't end when it's "done".""" By definition, it does. """In the earliest versions of the game, blocks were all basically homogenous cubes of some material, so they didn't need to be oriented. Later, blocks were added that did need to be rotated in various ways (...)""" So you are suggesting that they should have set up a system to allow that from the beginning. Have you sat and thought how adding things like that could delay the initial release? Also, have you sat and thought that if the initial release was not successful at the marketplace, all that extra work would have been in vain? [downvote? Thanks, parent] Just build what you need at the time, and make it flexible enough so that it can be refactored to something else later.
- hackinthebochs 15y ago
  >Just build what you need at the time, and make it flexible enough so that it can be refactored to something else later. But this is simply framework-level abstractions.
  - dextorious 15y ago
    Well, flexible enough so that it can refactored to something else later != framework-level abstractions. It could just be as simple: just don't make an untangleable mess out of it.

deleted 15y ago

[deleted]

humbledrone 15y ago

Hmm, from what I can tell, Minecraft is fairly successful, despite it being a "perfect example" of not having enough abstraction. Of course, you fail to really acknowledge the risks of premature abstraction. Sure, if you could see the future, and know what patterns could be usefully factored out into abstractions, it would be good to start with those abstractions. But what happens if you incorrectly predict that an abstraction will be needed? You create a bunch of unnecessary framework code that is harder to understand, likely less efficient, and worst of all, you wasted time writing code that you didn't need. YAGNI is not a cop-out. The best way to create abstractions is from concrete examples. Write something once. Then, once you actually find yourself writing it twice, abstract it out. That guarantees that you don't waste time on things that you don't use. It also generally leads to better abstractions, because you have concrete use-cases to work from. Anyway, back to the Minecraft story, who are you to say that the game would be better if Notch followed the premature abstraction strategy? Isn't it possible, perhaps, that he would have wasted enough time implementing ivory towers of abstraction that he might have left out the features that actually made the game fun?

extension 15y ago
But what happens if you incorrectly predict that an abstraction will be needed? Then you made a mistake and hopefully learned something. I didn't say architecting software was easy or without risk, just that you can't avoid doing it by following simplistic rules. The best way to create abstractions is from concrete examples. Write something once. Then, once you actually find yourself writing it twice, abstract it out. It's nice when things go that way, but it's not the general case. Often, by the time there is a concrete use for abstraction, the damage is done. For example, adding network multiplayer to a game that has been architected for single player is a nightmare of hacks and duplicated code (Notch has explicitly lamented about that one). Anyway, back to the Minecraft story, who are you to say that the game would be better if Notch followed the premature abstraction strategy? Notch himself seems to be saying as much in that blog post. But that aside, I'm a fellow game developer who has spent dozens of hours reading and modifying the Minecraft code. Even after a round-trip of obfuscation, it tells the story of its creation quite vividly, and the theme of the story is "hack around it!" Though I still have tremendous admiration for the game and its developers.
- teyc 15y ago
  Multiplayer mode can be extremely hard and can take any fun out of being an indie game developer. I'm still not sure if it is the right abstraction to work in on day one.
- humbledrone 15y ago
  Regarding the construction of abstractions from day one: http://en.wikipedia.org/wiki/Opportunity_cost http://en.wikipedia.org/wiki/Opportunity_cost
- humbledrone 15y ago
  > Then you made a mistake and hopefully learned something. Perhaps you learned that prematurely abstracting things is a waste of time?
- goblin89 15y ago
  I think the point was that the source code doesn't make the game better or worse. A nightmare of hacks is fine as long as the product is great. IMO writing such code is sometimes even better, especially for a solo developer. If you aim to write beautiful code, it might eventually outweigh everything else, while giving a false impression that you're doing the right thing. Your goal is the product, not code. I'd argue that you can't focus on both (it's called ‘focus’ for a reason).

dextorious 15y ago

"""Well no, because the job doesn't end when it's "done".""" By definition, it does. """In the earliest versions of the game, blocks were all basically homogenous cubes of some material, so they didn't need to be oriented. Later, blocks were added that did need to be rotated in various ways (...)""" So you are suggesting that they should have set up a system to allow that from the beginning. Have you sat and thought how adding things like that could delay the initial release? Also, have you sat and thought that if the initial release was not successful at the marketplace, all that extra work would have been in vain? [downvote? Thanks, parent] Just build what you need at the time, and make it flexible enough so that it can be refactored to something else later.

hackinthebochs 15y ago
>Just build what you need at the time, and make it flexible enough so that it can be refactored to something else later. But this is simply framework-level abstractions.
- dextorious 15y ago
  Well, flexible enough so that it can refactored to something else later != framework-level abstractions. It could just be as simple: just don't make an untangleable mess out of it.