This condescending nonsense is infuriating to the mature young people who are active on the forums. Sure there are little kids that act like little kids but then there are also adults that act like little kids, which is even worse. Just because you are older does not necessarily make you better or wiser, just older. I am 14 and I have made several ( not very good) games. So I know how hard coding is and I appreciate the work that notch has done and the work he is doing. No one is perfect though, and I think notch still has something to learn about dealing with the public. For example, rather than saying "I will release the update Oct31 ready or not" he might've said something like "the update will be released some time in early November" and set a private goal of Oct 31 but could've taken more time to polish the update. In a way people are justified in complaining about certain bugs, ( for example the sides of grass) because they paid for the game as is with all future updates as a bonus. So it can be upsetting when your bonus ends up detracting from the game. Although I agree people have no reason to complain about portals etc. Because no one is forcing them to even make one.
Dude, its all cool... Im 14 too :tongue.gif:
I mainly mean 'kids' as in the way they act, some 16 year olds act 12, some 12 year olds act, well, mature.
People who are like 'ZOMG NOTCH GET OFF UR FAT ASS AND FIX MULTIPLAYER' are considered 'kids' to me, generally because they have not 'matured' and have the nature of a small child, nothing against them personally, we were all that way at some point in time. Its just that for us who are generally more mature, we seem to get annoyed by them a bit more. xP
But there are some really cool 12 year olds out there at the same time. :tongue.gif:
The main backbone to this topic the efficiency of development (in particular during the Alpha stage).
Many people in this thread have at least recognised that a certain amount of testing is required, as this is a "paid public alpha." However this testing would still occur if the public didn't have access to the game, the only difference being the magnitude of the testing done, which would be significantly lower. This testing which I am referring to is informal testing. It's different to formal testing (done in the Beta stage, as highlighted by many), becuase it is done during the development stage (which includes the Alpha stage).
The main backbone to this topic is now how much informal testing is necessary while maintaining peak efficiency during development. This is a matter of balance (between playability and time/effort) and Notch's "grand picture" of Minecraft. Lets say,that the Nether is how Notch intends it to be, meaning the main features of it are in place, then a large amount of informal testing can be done (over time) to iron out major bugs, as it is unlikely to conflict with other main features of the "grand picture."
Feel free to agree/disagree with my opinion, just don't denigrate me. Haha.
I'm just used to it being meant just for age I guess. Although I hate when people yell at me just because i try to use my mic for teamwork in FPSes. I'm not being annoying or saying stupid stuff I'm just helping my team on, say, CoD, yet some 47.9 year old red neck has to be like "go and play animal crossing with your plush creeper dolls you stupid kid. I bet you haven't even had sex yet." So annoying... What does that even have to do with anything?
That's just the way it's done, and it's done that way because it's the way that works best
Ever heard of test driven development? Maybe unit tests?
The idea is that a piece of code has a certain purpose. Lets say we have a function that will take two numbers as arguments, and return 0 if either number is odd, or the sum if neither number is odd. We know how this function is supposed to behave, so we can write a test for it!
def TestFunction():
if AddEvens(1,3) != 0:
return false
if AddEvens(2,4) != 6:
return false
if AddEvens(1,4) != 0:
return false
if AddEvens(-1,4) != 0:
return false
if AddEvens(-2,4) != 2:
return false
if AddEvens(0,4) != 4:
return false
return true
After we've written a test, we can write the actual code. And if we change the code later and screw something up, the test will very likely catch it! (and if it doesn't, when we do figure out what's wrong, we can add to the test so that in the future it would)
The beauty of this is that it helps mitigate "1) adding new content will add new bugs anyway, so you can't stay ahead." and "2) there's too great a chance that the new content will end up breaking whatever bug fix you just spent all that time on anyway." When you change code (presuming you've been good about writing tests), you'll know more or less right away that something is wrong, and not just that, but where it's wrong, and in what sort of instance it's wrong.
All that said, I don't have a problem with the fact that there are still bugs or that they aren't all the top priority. I simply have a problem with saying that the development paradigm that Notch uses is the "only" or "best" way.
Nuff said? I mean right there. Just look at it. I don't get how I'm wrong...
Edit: as clarification, he said this After the guy asked him if he wouldn't be coding because of the business. And basically said, no the business is started and I'm coding.
Semantics. In your argument you're implying that Notch has all the time in the world because he has finished starting his company. In Notch's tweet, he is stating that his company has been created, i.e. he has finished starting the company, but a business does not just take off on its own without any work involved.
I was merely pointing out that although his company is complete, it's only the beginning, and there is still a lot of work ahead of him.
I think most of us rational beings understood the point you are making. A very good point at that.
Rollback Post to RevisionRollBack
“A fine beer may be judged with only one sip, but it's better to be thoroughly sure.” ~proverb
That's just the way it's done, and it's done that way because it's the way that works best
Ever heard of test driven development? Maybe unit tests?
The idea is that a piece of code has a certain purpose. Lets say we have a function that will take two numbers as arguments, and return 0 if either number is odd, or the sum if neither number is odd. We know how this function is supposed to behave, so we can write a test for it!
def TestFunction():
if AddEvens(1,3) != 0:
return false
if AddEvens(2,4) != 6:
return false
if AddEvens(1,4) != 0:
return false
if AddEvens(-1,4) != 0:
return false
if AddEvens(-2,4) != 2:
return false
if AddEvens(0,4) != 4:
return false
return true
After we've written a test, we can write the actual code. And if we change the code later and screw something up, the test will very likely catch it! (and if it doesn't, when we do figure out what's wrong, we can add to the test so that in the future it would)
The beauty of this is that it helps mitigate "1) adding new content will add new bugs anyway, so you can't stay ahead." and "2) there's too great a chance that the new content will end up breaking whatever bug fix you just spent all that time on anyway." When you change code (presuming you've been good about writing tests), you'll know more or less right away that something is wrong, and not just that, but where it's wrong, and in what sort of instance it's wrong.
All that said, I don't have a problem with the fact that there are still bugs or that they aren't all the top priority. I simply have a problem with saying that the development paradigm that Notch uses is the "only" or "best" way.
TDD is an excellent development method, not arguing with that at all in concept and certain applications. In a corporate development environment there is rarely a drive to do this, however, unless a primary decision maker is able to force the issue - and even then this person (or dare I say "committee"?) is often later blamed for insufficient progress (slow development). The point has been made before in this thread - constant testing, no matter the method it is implemented under, results in slower content/feature development. There is no question that testing is vital to development (Software Development Life Cycle); it is a question of balance - how much, when, by who. I am pleased to be involved in the alpha stage of a game that shows a HUGE amount of potential. Not to mention a great amount of enjoyment NOW!
EDIT: Nice Minecraft vid series you have going. I'll have to watch the rest very soon.
Rollback Post to RevisionRollBack
“A fine beer may be judged with only one sip, but it's better to be thoroughly sure.” ~proverb
That's just the way it's done, and it's done that way because it's the way that works best
Ever heard of test driven development? Maybe unit tests?
The idea is that a piece of code has a certain purpose. Lets say we have a function that will take two numbers as arguments, and return 0 if either number is odd, or the sum if neither number is odd. We know how this function is supposed to behave, so we can write a test for it!
def TestFunction():
if AddEvens(1,3) != 0:
return false
if AddEvens(2,4) != 6:
return false
if AddEvens(1,4) != 0:
return false
if AddEvens(-1,4) != 0:
return false
if AddEvens(-2,4) != 2:
return false
if AddEvens(0,4) != 4:
return false
return true
After we've written a test, we can write the actual code. And if we change the code later and screw something up, the test will very likely catch it! (and if it doesn't, when we do figure out what's wrong, we can add to the test so that in the future it would)
The beauty of this is that it helps mitigate "1) adding new content will add new bugs anyway, so you can't stay ahead." and "2) there's too great a chance that the new content will end up breaking whatever bug fix you just spent all that time on anyway." When you change code (presuming you've been good about writing tests), you'll know more or less right away that something is wrong, and not just that, but where it's wrong, and in what sort of instance it's wrong.
All that said, I don't have a problem with the fact that there are still bugs or that they aren't all the top priority. I simply have a problem with saying that the development paradigm that Notch uses is the "only" or "best" way.
TDD is an excellent development method, not arguing with that at all in concept and certain applications. In a corporate development environment there is rarely a drive to do this, however, unless a primary decision maker is able to force the issue - and even then this person (or dare I say "committee"?) is often later blamed for insufficient progress (slow development). The point has been made before in this thread - constant testing, no matter the method it is implemented under, results in slower content/feature development. There is no question that testing is vital to development (Software Development Life Cycle); it is a question of balance - how much, when, by who. I am pleased to be involved in the alpha stage of a game that shows a HUGE amount of potential. Not to mention a great amount of enjoyment NOW!
I echo your last sentiments, however I think saying that TDD is a slower cycle (over all, like new project to final release) is a mistake. If done properly, it shouldn't be a longer/slower cycle at all. It may not be any faster, but it does provide a much nicer method for debugging (so faster bug fixing) and often the style of development causes less errors and bugs to be created (and fewer bugs to be fixed). So like right now Notch is guessing at what is causing the server to enter that loop, chances are if he had unit tests, he might already know. Of course, TDD does mean a slower flow of features, but they should be bug free and the issues of "fixing one bug creates a ton more" or "adding more things could cause bugs in older things" become much, much smaller.
To be honest, I'm just so glad that someone made a nice response to my post. I was sort of expecting, "OMG! ur so stupid, i bet you culdn't program even a simpl game". So thank you for that post, it reminds me that the internet is not completely full of idiots.
Ever heard of test driven development? Maybe unit tests?
The idea is that a piece of code has a certain purpose. Lets say we have a function that will take two numbers as arguments, and return 0 if either number is odd, or the sum if neither number is odd. We know how this function is supposed to behave, so we can write a test for it!
def TestFunction():
if AddEvens(1,3) != 0:
return false
if AddEvens(2,4) != 6:
return false
if AddEvens(1,4) != 0:
return false
if AddEvens(-1,4) != 0:
return false
if AddEvens(-2,4) != 2:
return false
if AddEvens(0,4) != 4:
return false
return true
After we've written a test, we can write the actual code. And if we change the code later and screw something up, the test will very likely catch it! (and if it doesn't, when we do figure out what's wrong, we can add to the test so that in the future it would)
The beauty of this is that it helps mitigate "1) adding new content will add new bugs anyway, so you can't stay ahead." and "2) there's too great a chance that the new content will end up breaking whatever bug fix you just spent all that time on anyway." When you change code (presuming you've been good about writing tests), you'll know more or less right away that something is wrong, and not just that, but where it's wrong, and in what sort of instance it's wrong.
All that said, I don't have a problem with the fact that there are still bugs or that they aren't all the top priority. I simply have a problem with saying that the development paradigm that Notch uses is the "only" or "best" way.
TDD is an excellent development method, not arguing with that at all in concept and certain applications. In a corporate development environment there is rarely a drive to do this, however, unless a primary decision maker is able to force the issue - and even then this person (or dare I say "committee"?) is often later blamed for insufficient progress (slow development). The point has been made before in this thread - constant testing, no matter the method it is implemented under, results in slower content/feature development. There is no question that testing is vital to development (Software Development Life Cycle); it is a question of balance - how much, when, by who. I am pleased to be involved in the alpha stage of a game that shows a HUGE amount of potential. Not to mention a great amount of enjoyment NOW!
I echo your last sentiments, however I think saying that TDD is a slower cycle (over all, like new project to final release) is a mistake. If done properly, it shouldn't be a longer/slower cycle at all. It may not be any faster, but it does provide a much nicer method for debugging (so faster bug fixing) and often the style of development causes less errors and bugs to be created (and fewer bugs to be fixed). So like right now Notch is guessing at what is causing the server to enter that loop, chances are if he had unit tests, he might already know. Of course, TDD does mean a slower flow of features, but they should be bug free and the issues of "fixing one bug creates a ton more" or "adding more things could cause bugs in older things" become much, much smaller.
To be honest, I'm just so glad that someone made a nice response to my post. I was sort of expecting, "OMG! ur so stupid, i bet you culdn't program even a simpl game". So thank you for that post, it reminds me that the internet is not completely full of idiots.
Thank you in return for your kind and considered response. I do agree with your "If done properly" statement. My only issue with that is that as a project manager I am constantly under pressure by upper management to increase development speed. Try explaining TDD or even SDLC to any of them and their eyes glaze over in less than 2 minutes. What matters is results. I have learned to implement a measure of TDD, but it requires a lot of time and attention to make sure that development follows its proper course. Considering the pressure and lack of understanding I have to deal with, I think Notch is doing a great job! (I know you are not knocking him for this) Could Notch handle this differently and better? Perhaps... I imagine that with the attention this game (alpha though it is) has garnered he is forcing himself to prioritize on the most demanded features.
Rollback Post to RevisionRollBack
“A fine beer may be judged with only one sip, but it's better to be thoroughly sure.” ~proverb
I hate TDD, but I'll admit it's a personal preference. I don't like the way that TDD makes you think in terms of solving the test, rather than solving the users problem. I don't like tests driving the design, but I do like unit tests in general. But that's beside the point.
Most people here are assuming that all bugs are either fixed immediately, or left until the end. That's just not true. Bugs, and new features, are prioritised by someone, and then they are worked on based on their priority. Off-colour grass? Low. Items not dropping on death? High.
Now given up until now Minecraft has been a one-notch show I suspect the priority of things has been whatever Notch felt like doing. Mostly that means new features, but it could have also been fix most bugs first. Both are valid. I'd be curious to know what development methodology gets implemented at Minecraft HQ.
Notch has chosen to go with Rapid Application Development (RAD) where you churn out a bare minimum, build on it, fix the big bugs, build on that, fix big bugs, build on that, and generally just keep building towards the picture in your head.
Unfortunately, by releasing in alpha, he's invited half a million folks to join in on this progression.
Some of them can't deal with this style of development because it's not what they're used to it.
On the other hand, if he hadn't released until Beta (or Release) then we wouldn't even be having this conversation.
Notch has chosen to go with Rapid Application Development (RAD) where you churn out a bare minimum, build on it, fix the big bugs, build on that, fix big bugs, build on that, and generally just keep building towards the picture in your head.
Unfortunately, by releasing in alpha, he's invited half a million folks to join in on this progression.
Some of them can't deal with this style of development because it's not what they're used to it.
On the other hand, if he hadn't released until Beta (or Release) then we wouldn't even be having this conversation.
To some extent I agree re: your guess that RAD is being utilized. Maybe more than some, esp. recently. However, the overall stability of the game at "alpha" stage seems to me to indicate a more structured approach. He has been building this for some time now and has learned from each mistake, as far as I have observed. It is encouraging that he has a team of specialists to support the development at this point, and I hope that he is able to maintain the vision for this game which he has shared with us to date.
I do agree, unconditionally, that most players do not understand nor can "deal" with his style of development. That is really their problem and I hope Notch doesn't take it personally.
Rollback Post to RevisionRollBack
“A fine beer may be judged with only one sip, but it's better to be thoroughly sure.” ~proverb
I hate TDD, but I'll admit it's a personal preference. I don't like the way that TDD makes you think in terms of solving the test, rather than solving the users problem. I don't like tests driving the design, but I do like unit tests in general. But that's beside the point.
Most people here are assuming that all bugs are either fixed immediately, or left until the end. That's just not true. Bugs, and new features, are prioritised by someone, and then they are worked on based on their priority. Off-colour grass? Low. Items not dropping on death? High.
Now given up until now Minecraft has been a one-notch show I suspect the priority of things has been whatever Notch felt like doing. Mostly that means new features, but it could have also been fix most bugs first. Both are valid. I'd be curious to know what development methodology gets implemented at Minecraft HQ.
Anyway, that's my 2c.
That's why you design the tests such that if they pass, you have solved a user's problem. And for me at least, unit tests are the big thing in TDD. I think a lot of the best advantages come out of having good test code coverage. Like more readily being able to tell where a bug is occurring, for instance. A lot of it does come down to personal preference and ability to stick to it. I know when someone first tried to get me to use unit tests, I kept coming up with reasons why I didn't need them. Next came the reasons why I didn't like them (most of them came out of not be consistent in my usage). Now, I love unit tests. They remove so much frustration from debugging. Even if they don't save time, they save me from wanting to smash and break things.
That's just the way it's done, and it's done that way because it's the way that works best
Ever heard of test driven development? Maybe unit tests?
The idea is that a piece of code has a certain purpose. Lets say we have a function that will take two numbers as arguments, and return 0 if either number is odd, or the sum if neither number is odd. We know how this function is supposed to behave, so we can write a test for it!
def TestFunction():
if AddEvens(1,3) != 0:
return false
if AddEvens(2,4) != 6:
return false
if AddEvens(1,4) != 0:
return false
if AddEvens(-1,4) != 0:
return false
if AddEvens(-2,4) != 2:
return false
if AddEvens(0,4) != 4:
return false
return true
After we've written a test, we can write the actual code. And if we change the code later and screw something up, the test will very likely catch it! (and if it doesn't, when we do figure out what's wrong, we can add to the test so that in the future it would)
The beauty of this is that it helps mitigate "1) adding new content will add new bugs anyway, so you can't stay ahead." and "2) there's too great a chance that the new content will end up breaking whatever bug fix you just spent all that time on anyway." When you change code (presuming you've been good about writing tests), you'll know more or less right away that something is wrong, and not just that, but where it's wrong, and in what sort of instance it's wrong.
All that said, I don't have a problem with the fact that there are still bugs or that they aren't all the top priority. I simply have a problem with saying that the development paradigm that Notch uses is the "only" or "best" way.
Sorry-- that was poorly phrased.
I was by no means seeking to advocate a particular approach to software development. I was merely trying to emphasize the difference between software development as it really is, more or less in all its forms, and as many on this forum seem to view it, which might best be described as "somebody spontaneously generates a bug-free finished product that is in all ways exactly what I want."
Unfortunately, by releasing in alpha, he's invited half a million folks to join in on this progression.
Haha. I laughed. In a good way. Haha.
Notch's choice has had many consequences, both good and bad. Minecraft has gotten the seal of approval from the internet and as a result of that he now has the funds to develop Minecraft and future games (if he desires). On the other hand, as you said it has a generated a large community, mainly consisting of "immature-update-hungry-internet-users," which judge every alternation and addition made to Minecraft.
maby im just a super smart genius but i realized that the game that i bought was offerd at a discount because it was UNFINNISHED.
maby people should realize that they wernt forced to spend there money and if they wanted a fully working game, they should not have bought incomplete product.
its like someone restoring an old car and not being able to compleete it so they sell it as an incompleet rebuild and they buyer gettign pissed because it does not work.
Emily, Argent, Baggins, Arlo (I think I got you all): Thanks for the interesting discussion on coding development practices. My computer science classes haven't covered anything remotely similar, so, it was interesting reading to say the least.
That seems to be the procedure of an MMO development team, such as Runescape, a never ending cycle. There are clear differences between Alpha and Beta stages in development. That fact you call yourself a developer concerns me.
Rawr.
Dude, its all cool... Im 14 too :tongue.gif:
I mainly mean 'kids' as in the way they act, some 16 year olds act 12, some 12 year olds act, well, mature.
People who are like 'ZOMG NOTCH GET OFF UR FAT ASS AND FIX MULTIPLAYER' are considered 'kids' to me, generally because they have not 'matured' and have the nature of a small child, nothing against them personally, we were all that way at some point in time. Its just that for us who are generally more mature, we seem to get annoyed by them a bit more. xP
But there are some really cool 12 year olds out there at the same time. :tongue.gif:
Many people in this thread have at least recognised that a certain amount of testing is required, as this is a "paid public alpha." However this testing would still occur if the public didn't have access to the game, the only difference being the magnitude of the testing done, which would be significantly lower. This testing which I am referring to is informal testing. It's different to formal testing (done in the Beta stage, as highlighted by many), becuase it is done during the development stage (which includes the Alpha stage).
The main backbone to this topic is now how much informal testing is necessary while maintaining peak efficiency during development. This is a matter of balance (between playability and time/effort) and Notch's "grand picture" of Minecraft. Lets say,that the Nether is how Notch intends it to be, meaning the main features of it are in place, then a large amount of informal testing can be done (over time) to iron out major bugs, as it is unlikely to conflict with other main features of the "grand picture."
Feel free to agree/disagree with my opinion, just don't denigrate me. Haha.
Ahh..
Ever heard of test driven development? Maybe unit tests?
The idea is that a piece of code has a certain purpose. Lets say we have a function that will take two numbers as arguments, and return 0 if either number is odd, or the sum if neither number is odd. We know how this function is supposed to behave, so we can write a test for it!
After we've written a test, we can write the actual code. And if we change the code later and screw something up, the test will very likely catch it! (and if it doesn't, when we do figure out what's wrong, we can add to the test so that in the future it would)
The beauty of this is that it helps mitigate "1) adding new content will add new bugs anyway, so you can't stay ahead." and "2) there's too great a chance that the new content will end up breaking whatever bug fix you just spent all that time on anyway." When you change code (presuming you've been good about writing tests), you'll know more or less right away that something is wrong, and not just that, but where it's wrong, and in what sort of instance it's wrong.
All that said, I don't have a problem with the fact that there are still bugs or that they aren't all the top priority. I simply have a problem with saying that the development paradigm that Notch uses is the "only" or "best" way.
I think most of us rational beings understood the point you are making. A very good point at that.
“A fine beer may be judged with only one sip, but it's better to be thoroughly sure.” ~proverb
TDD is an excellent development method, not arguing with that at all in concept and certain applications. In a corporate development environment there is rarely a drive to do this, however, unless a primary decision maker is able to force the issue - and even then this person (or dare I say "committee"?) is often later blamed for insufficient progress (slow development). The point has been made before in this thread - constant testing, no matter the method it is implemented under, results in slower content/feature development. There is no question that testing is vital to development (Software Development Life Cycle); it is a question of balance - how much, when, by who. I am pleased to be involved in the alpha stage of a game that shows a HUGE amount of potential. Not to mention a great amount of enjoyment NOW!
EDIT: Nice Minecraft vid series you have going. I'll have to watch the rest very soon.
“A fine beer may be judged with only one sip, but it's better to be thoroughly sure.” ~proverb
I echo your last sentiments, however I think saying that TDD is a slower cycle (over all, like new project to final release) is a mistake. If done properly, it shouldn't be a longer/slower cycle at all. It may not be any faster, but it does provide a much nicer method for debugging (so faster bug fixing) and often the style of development causes less errors and bugs to be created (and fewer bugs to be fixed). So like right now Notch is guessing at what is causing the server to enter that loop, chances are if he had unit tests, he might already know. Of course, TDD does mean a slower flow of features, but they should be bug free and the issues of "fixing one bug creates a ton more" or "adding more things could cause bugs in older things" become much, much smaller.
To be honest, I'm just so glad that someone made a nice response to my post. I was sort of expecting, "OMG! ur so stupid, i bet you culdn't program even a simpl game". So thank you for that post, it reminds me that the internet is not completely full of idiots.
Thank you in return for your kind and considered response. I do agree with your "If done properly" statement. My only issue with that is that as a project manager I am constantly under pressure by upper management to increase development speed. Try explaining TDD or even SDLC to any of them and their eyes glaze over in less than 2 minutes. What matters is results. I have learned to implement a measure of TDD, but it requires a lot of time and attention to make sure that development follows its proper course. Considering the pressure and lack of understanding I have to deal with, I think Notch is doing a great job! (I know you are not knocking him for this) Could Notch handle this differently and better? Perhaps... I imagine that with the attention this game (alpha though it is) has garnered he is forcing himself to prioritize on the most demanded features.
“A fine beer may be judged with only one sip, but it's better to be thoroughly sure.” ~proverb
Most people here are assuming that all bugs are either fixed immediately, or left until the end. That's just not true. Bugs, and new features, are prioritised by someone, and then they are worked on based on their priority. Off-colour grass? Low. Items not dropping on death? High.
Now given up until now Minecraft has been a one-notch show I suspect the priority of things has been whatever Notch felt like doing. Mostly that means new features, but it could have also been fix most bugs first. Both are valid. I'd be curious to know what development methodology gets implemented at Minecraft HQ.
Anyway, that's my 2c.
Notch has chosen to go with Rapid Application Development (RAD) where you churn out a bare minimum, build on it, fix the big bugs, build on that, fix big bugs, build on that, and generally just keep building towards the picture in your head.
Unfortunately, by releasing in alpha, he's invited half a million folks to join in on this progression.
Some of them can't deal with this style of development because it's not what they're used to it.
On the other hand, if he hadn't released until Beta (or Release) then we wouldn't even be having this conversation.
To some extent I agree re: your guess that RAD is being utilized. Maybe more than some, esp. recently. However, the overall stability of the game at "alpha" stage seems to me to indicate a more structured approach. He has been building this for some time now and has learned from each mistake, as far as I have observed. It is encouraging that he has a team of specialists to support the development at this point, and I hope that he is able to maintain the vision for this game which he has shared with us to date.
I do agree, unconditionally, that most players do not understand nor can "deal" with his style of development. That is really their problem and I hope Notch doesn't take it personally.
“A fine beer may be judged with only one sip, but it's better to be thoroughly sure.” ~proverb
That's why you design the tests such that if they pass, you have solved a user's problem. And for me at least, unit tests are the big thing in TDD. I think a lot of the best advantages come out of having good test code coverage. Like more readily being able to tell where a bug is occurring, for instance. A lot of it does come down to personal preference and ability to stick to it. I know when someone first tried to get me to use unit tests, I kept coming up with reasons why I didn't need them. Next came the reasons why I didn't like them (most of them came out of not be consistent in my usage). Now, I love unit tests. They remove so much frustration from debugging. Even if they don't save time, they save me from wanting to smash and break things.
Sorry-- that was poorly phrased.
I was by no means seeking to advocate a particular approach to software development. I was merely trying to emphasize the difference between software development as it really is, more or less in all its forms, and as many on this forum seem to view it, which might best be described as "somebody spontaneously generates a bug-free finished product that is in all ways exactly what I want."
Haha. I laughed. In a good way. Haha.
Notch's choice has had many consequences, both good and bad. Minecraft has gotten the seal of approval from the internet and as a result of that he now has the funds to develop Minecraft and future games (if he desires). On the other hand, as you said it has a generated a large community, mainly consisting of "immature-update-hungry-internet-users," which judge every alternation and addition made to Minecraft.
maby im just a super smart genius but i realized that the game that i bought was offerd at a discount because it was UNFINNISHED.
maby people should realize that they wernt forced to spend there money and if they wanted a fully working game, they should not have bought incomplete product.
its like someone restoring an old car and not being able to compleete it so they sell it as an incompleet rebuild and they buyer gettign pissed because it does not work.
Emily, Argent, Baggins, Arlo (I think I got you all): Thanks for the interesting discussion on coding development practices. My computer science classes haven't covered anything remotely similar, so, it was interesting reading to say the least.
That seems to be the procedure of an MMO development team, such as Runescape, a never ending cycle. There are clear differences between Alpha and Beta stages in development. That fact you call yourself a developer concerns me.