You know the magic has gone out when everything is reduced to a dichotomy between miniscule speed increases and enormous manageability increases. Of course the answer is obvious when it's phrased that way; of course it's a false dichotomy. At the very least, "readability" is in the eye of the beholder; performance, usually a bit more objective.
The ScrumMasters responsibility is to support the Organization to implement Scrum, thats all.
Right, of course. They are, as scrummasters say, involved in the project. They aren't fully committed the way the developers are, the ones who could lose their jobs if the project goes south.
And that's where the snake oil alarms go off; the scrummaster is someone that, according to scrum, is committed to the project in a visceral way. It's just not true, and it's dishonest right around the part where the scrum evangelist's job is on the line.
As for my own situation... I'm barely affected by scrum at all; supposedly we do it, but I can get my job done without caring what process is being used. I notice that we have more meetings now than when I wasn't in an organization doing scrum, and that interrupts my programming time; but overall it doesn't have much noticeable effect of any kind.
Scrum doesn't slow our project down, it doesn't accelerate it; it has zero effect. And that's the most damning thing - scrum doesn't matter. If it doesn't matter, why bother buying books, going through training, hiring more people... why spend all that money?
...if [test-driven development] is cut from Scrum, the project is doomed to fail...
I'm not going to argue against the value of test-driven development, but lack of test-driven development doesn't doom any project. Letting bugs get out the door can doom a project, but there are many-many ways of preventing that other than compulsive unit tests.
I have written a thesis about this problem - almost all project that "used agile development" methods and then failed, were trying to cut too many corners and modified a developed methodology breaking it in the process.
Yes, yes, if a project is agile but modified the Holy Process as defined in some book, and then failed, the failure is because they didn't follow the process. I covered this already. However, you make clear even in this one sentence that you aren't prepared to argue the opposite - that a survey of successful agile projects will show them using scrum (or XP, or...) precisely and without modification. The danger, as you put it, comes from cutting "too many" corners.
Simple question: do you agree that scrum masters should be fired if their project fails? After all, clearly the project wasn't following scrum properly, and it's the scrum master's job to make sure they are, so clearly the job was not done. In fact, the scrum master's failure caused the failure of the entire project! So, what should be done with the scrum master of a failed project?
I've worked with scrum, and it sucks. It only works if people work together, are largely self-organising, and don't deliberately chuck roadblocks into other teams paths to get them off their own joblist.
I believe the latter of those in particular gives away pretty bad organizational problems, scrum or no. They would probably manifest themselves just in a different way if you tried to do things different on the surface.
And a team that works together, is largely self-organizing, and doesn't deliberately screw other teams is worth its weight in gold without scrum, too.
You actually have to do it more or less properly for it to work.
No, you really don't. You need the other ingredients: a self-organizing team that works together and with the other groups in a company. You add scrum to that, you've got a great team. You add a few bits of scrum to that, you've got a great team. You add some standard corporate culture to that, you've got a great team. Are you seeing the pattern here?
I'm a big fan of a team following good processes (testing your work, gathering feedback, being realistic in schedules), I'm a big fan of a team being invested in their work, and I'm a big fan of open communication. Scrum argues for some of the same things, and it's good that these scrum proponents are arguing for all of these things. But you don't need a scrum master to get the good stuff, and I don't think scrum will turn a bad team into a good team - it will just turn a team that isn't doing scrum into a team that isn't doing scrum right.
No, it's not. "I know you tried to do scrum, but you had a failed project, so you did it wrong."
In my experience, scrum is just snake oil. I don't think it's very good to begin with, but worse is that a) everyone modifies scrum to some extent to fit their organization and b) if a project using slightly modified scrum fails, it was because they modified scrum.
Of course, the solution always seems to be hire more good scrum masters, who are "rarer then you would think!" That's really the part that is snake oil, in my mind. It's a business model for consultants, and the trainers of those consultants. This is even more clear with the scrum model's insistence that a scrum master has a "pig" role.
Maybe all the scrum organizations should promote the idea that every time a scrum project fails (yes, even with modifications, which is how it always works), the scrum master gets fired. Here, "fails" should probably mean over budget or over schedule, by a dollar or a day. That might give the scrum master a role where they feel like their bacon is on the line. But of course that won't happen; scrum masters aren't team leads (as you point out), they're not managers, they're just coaches... one more person not doing the actual work who has to be involved, but with less accountability and more power than anyone else in the project.
Depending on what you're browsing. SomethingAwful? NYTimes.com? Stack Overflow? It can't hurt to encrypt the traffic and make it harder to sniff. Banking, buying stuff from Amazon? Sure, PKI is important there to maintain a chain of trust that makes it harder for your identity and money to be stolen.
Right now, we have the second half, and that's it.
Why is there any unencrypted HTTP traffic going around? Encrypt everything, absolutely everything, traveling over the wire. Then, when it's important, you should also worry about whether the machine on the other end is who they say they are.
There's not going to be a simple answer to your questions. If you want to make games, make games. You can write them in Flash or Objective-C or Perl or PHP or Lisp or C++ or... Obviously you'll have a little trouble writing an iPhone game in Flash, or a Flash game in !Flash, so choose the right tool for the job; but if you're in college, your goal shouldn't be to learn a single tool and then pretend that all the jobs you might get later in life use that one tool.
Also, most of the game industry doesn't care about your degree(s). They care about what you can do, and in particular how you've demonstrated that you can do things by having done things. So do things, and get them done. Get the degree to help you have a career to start on, a career to fall back on, and a career to move on to... burn out is common, and doing this your whole life and then retiring is ridiculously rare.
This from the guy who says in his signature: "Main difference between the BSD license and the GPL license: one is from California and the other is from Massachusetts."
You haven't invested the time in this issue to understand it, never mind make pronouncements on it.
Errr, nope, I work on modern commercial games and Emacs works great. We exceed 10kloc by orders of magnitude, we have the budget for great tools, and Emacs is what I choose.
Warren Spector has been outspoken against MMOs as a particularly terrible example of "multiplayer" for a while too. I can understand that he doesn't want to work on them, but that doesn't make them any less fun, and I think he's failing to recognize the challenges of enabling meaningful emergent play.
Small fees for one-time things are showing up in a lot of online games these days, no question. Guild Wars, City of Heroes, World of Warcraft, all support one-time fees for things like extra character slots, server transfers, and cosmetic (or complete) respecs. These are things that don't affect gameplay, are uncommon purchases for any individual player, but do improve player enjoyment (they also enhance revenue something fierce). Should they be free? Sometimes yes, sometimes no. It makes sense for Warhammer Online to offer free server transfers right now to help balance populations, but in general players are closely tied to the community on their individual servers - so it makes a certain amount of sense to regard it as a value-added feature. Likewise, City of Heroes hands out free respecs like candy, but if you still can't get enough of them... sure, it makes sense to charge.
And then there are games that are free to play... they have to have some revenue model. Games like Puzzle Pirates demonstrate that a game can be fun, balanced, and robust, while still selling all manner of things that affect game play. The key with that approach, I think, is to use a dual currency model (as Puzzle Pirates does, as Iron Realms pioneered back in the '90s) that allows players - who never pay a cent - to trade with other players for all the benefits of spending money.
Of course there's also the Korean free to play model, or the model common for Facebook games where it is "free to play" but you have to pay in order to really enjoy the game (or worse, there is a subscription but you still have to engage in microtransactions in order to really enjoy the game) - I think this is the model players don't like, and fear every developer is planning on when they say free-to-play or microtransactions. I think developers and publishers know players hate this model, and are aware of the backlash they'll see if they use it; that doesn't mean they won't ever try it, but it does mean they'll tend to tread carefully and consider other models first.
On the other hand, that doesn't mean subscriptions are going away, because clearly a lot of players like to just pay a subscription, know how much they need to budget on a game, and know they don't risk a fevered drunken night of transactions running up their credit card bill. It's unlikely to go away, but it is going to have to start sharing the limelight with other models that address the needs of different segments of the population.
To me, it's weird that you would separate programmers who enjoy doing the job away from career programmers. In my experience, it's most professional programmers, and certainly the best ones I've worked with love doing it. But biased towards programmers who enjoy programmers? Hell yes, it's an article talking about tech startups, of course it's going to make some assumptions about programmers in the audience.
Is CmdrTaco unaware that del Toro directed the first Hellboy movie? He certainly didn't have quite the same license to create his own vision then as he does now, but he is the guy who got the first one so very right.
That just seems silly. I'd like to see performance tests on a system where the disk's performance affects the end result, rather than all of the results being homogenized by the operating system's poor I/O capability. Given Vista's adoption, it's not even a test of what disk performance will be like "in the real world."
I'm not sure what they recommend, but I can tell you what every company or organization I've worked with did, when they had more load than a single computer with a single CPU and a single disk (or RAID) could handle. They added more machines with a single CPU and a single disk (or RAID), and put it all behind a load balancer.
Databases are a bit different, in that most DB vendors make it more expensive to cluster/load balance machines than to beef up your existing machine, and indeed database servers benefit more from extra CPU than do web servers. So there are a lot more beefy multi-CPU database systems out there. . . but consistently, the first step in improving database performance is to pull it away from the web server.
The price/performance ratio involved in using a single beefier box to do everything is simply too poor compared to that.
Slashdot Mirror
You know the magic has gone out when everything is reduced to a dichotomy between miniscule speed increases and enormous manageability increases. Of course the answer is obvious when it's phrased that way; of course it's a false dichotomy. At the very least, "readability" is in the eye of the beholder; performance, usually a bit more objective.
Perhaps that's why it's not glorious work anymore. :-P
...not that I ever looked at it as glorious stuff to begin with...
Right, of course. They are, as scrummasters say, involved in the project. They aren't fully committed the way the developers are, the ones who could lose their jobs if the project goes south.
And that's where the snake oil alarms go off; the scrummaster is someone that, according to scrum, is committed to the project in a visceral way. It's just not true, and it's dishonest right around the part where the scrum evangelist's job is on the line.
As for my own situation... I'm barely affected by scrum at all; supposedly we do it, but I can get my job done without caring what process is being used. I notice that we have more meetings now than when I wasn't in an organization doing scrum, and that interrupts my programming time; but overall it doesn't have much noticeable effect of any kind.
Scrum doesn't slow our project down, it doesn't accelerate it; it has zero effect. And that's the most damning thing - scrum doesn't matter. If it doesn't matter, why bother buying books, going through training, hiring more people... why spend all that money?
So then what's the product owner? How many different titles and concurrent positions need to be held by facilitators at once?
I'm not going to argue against the value of test-driven development, but lack of test-driven development doesn't doom any project. Letting bugs get out the door can doom a project, but there are many-many ways of preventing that other than compulsive unit tests.
Yes, yes, if a project is agile but modified the Holy Process as defined in some book, and then failed, the failure is because they didn't follow the process. I covered this already. However, you make clear even in this one sentence that you aren't prepared to argue the opposite - that a survey of successful agile projects will show them using scrum (or XP, or...) precisely and without modification. The danger, as you put it, comes from cutting "too many" corners.
Simple question: do you agree that scrum masters should be fired if their project fails? After all, clearly the project wasn't following scrum properly, and it's the scrum master's job to make sure they are, so clearly the job was not done. In fact, the scrum master's failure caused the failure of the entire project! So, what should be done with the scrum master of a failed project?
And a team that works together, is largely self-organizing, and doesn't deliberately screw other teams is worth its weight in gold without scrum, too.
No, you really don't. You need the other ingredients: a self-organizing team that works together and with the other groups in a company. You add scrum to that, you've got a great team. You add a few bits of scrum to that, you've got a great team. You add some standard corporate culture to that, you've got a great team. Are you seeing the pattern here?
I'm a big fan of a team following good processes (testing your work, gathering feedback, being realistic in schedules), I'm a big fan of a team being invested in their work, and I'm a big fan of open communication. Scrum argues for some of the same things, and it's good that these scrum proponents are arguing for all of these things. But you don't need a scrum master to get the good stuff, and I don't think scrum will turn a bad team into a good team - it will just turn a team that isn't doing scrum into a team that isn't doing scrum right.
No, it's not. "I know you tried to do scrum, but you had a failed project, so you did it wrong."
In my experience, scrum is just snake oil. I don't think it's very good to begin with, but worse is that a) everyone modifies scrum to some extent to fit their organization and b) if a project using slightly modified scrum fails, it was because they modified scrum.
Of course, the solution always seems to be hire more good scrum masters, who are "rarer then you would think!" That's really the part that is snake oil, in my mind. It's a business model for consultants, and the trainers of those consultants. This is even more clear with the scrum model's insistence that a scrum master has a "pig" role.
Maybe all the scrum organizations should promote the idea that every time a scrum project fails (yes, even with modifications, which is how it always works), the scrum master gets fired. Here, "fails" should probably mean over budget or over schedule, by a dollar or a day. That might give the scrum master a role where they feel like their bacon is on the line. But of course that won't happen; scrum masters aren't team leads (as you point out), they're not managers, they're just coaches... one more person not doing the actual work who has to be involved, but with less accountability and more power than anyone else in the project.
Depending on what you're browsing. SomethingAwful? NYTimes.com? Stack Overflow? It can't hurt to encrypt the traffic and make it harder to sniff. Banking, buying stuff from Amazon? Sure, PKI is important there to maintain a chain of trust that makes it harder for your identity and money to be stolen.
Right now, we have the second half, and that's it.
Why is there any unencrypted HTTP traffic going around? Encrypt everything, absolutely everything, traveling over the wire. Then, when it's important, you should also worry about whether the machine on the other end is who they say they are.
There's not going to be a simple answer to your questions. If you want to make games, make games. You can write them in Flash or Objective-C or Perl or PHP or Lisp or C++ or... Obviously you'll have a little trouble writing an iPhone game in Flash, or a Flash game in !Flash, so choose the right tool for the job; but if you're in college, your goal shouldn't be to learn a single tool and then pretend that all the jobs you might get later in life use that one tool.
Also, most of the game industry doesn't care about your degree(s). They care about what you can do, and in particular how you've demonstrated that you can do things by having done things. So do things, and get them done. Get the degree to help you have a career to start on, a career to fall back on, and a career to move on to... burn out is common, and doing this your whole life and then retiring is ridiculously rare.
This from the guy who says in his signature: "Main difference between the BSD license and the GPL license: one is from California and the other is from Massachusetts."
You haven't invested the time in this issue to understand it, never mind make pronouncements on it.
Errr, nope, I work on modern commercial games and Emacs works great. We exceed 10kloc by orders of magnitude, we have the budget for great tools, and Emacs is what I choose.
Warren Spector has been outspoken against MMOs as a particularly terrible example of "multiplayer" for a while too. I can understand that he doesn't want to work on them, but that doesn't make them any less fun, and I think he's failing to recognize the challenges of enabling meaningful emergent play.
Small fees for one-time things are showing up in a lot of online games these days, no question. Guild Wars, City of Heroes, World of Warcraft, all support one-time fees for things like extra character slots, server transfers, and cosmetic (or complete) respecs. These are things that don't affect gameplay, are uncommon purchases for any individual player, but do improve player enjoyment (they also enhance revenue something fierce). Should they be free? Sometimes yes, sometimes no. It makes sense for Warhammer Online to offer free server transfers right now to help balance populations, but in general players are closely tied to the community on their individual servers - so it makes a certain amount of sense to regard it as a value-added feature. Likewise, City of Heroes hands out free respecs like candy, but if you still can't get enough of them... sure, it makes sense to charge.
And then there are games that are free to play... they have to have some revenue model. Games like Puzzle Pirates demonstrate that a game can be fun, balanced, and robust, while still selling all manner of things that affect game play. The key with that approach, I think, is to use a dual currency model (as Puzzle Pirates does, as Iron Realms pioneered back in the '90s) that allows players - who never pay a cent - to trade with other players for all the benefits of spending money.
Of course there's also the Korean free to play model, or the model common for Facebook games where it is "free to play" but you have to pay in order to really enjoy the game (or worse, there is a subscription but you still have to engage in microtransactions in order to really enjoy the game) - I think this is the model players don't like, and fear every developer is planning on when they say free-to-play or microtransactions. I think developers and publishers know players hate this model, and are aware of the backlash they'll see if they use it; that doesn't mean they won't ever try it, but it does mean they'll tend to tread carefully and consider other models first.
On the other hand, that doesn't mean subscriptions are going away, because clearly a lot of players like to just pay a subscription, know how much they need to budget on a game, and know they don't risk a fevered drunken night of transactions running up their credit card bill. It's unlikely to go away, but it is going to have to start sharing the limelight with other models that address the needs of different segments of the population.
To me, it's weird that you would separate programmers who enjoy doing the job away from career programmers. In my experience, it's most professional programmers, and certainly the best ones I've worked with love doing it. But biased towards programmers who enjoy programmers? Hell yes, it's an article talking about tech startups, of course it's going to make some assumptions about programmers in the audience.
I fix the bugs first. Duh.
Errrr, how are you playing Starcraft - WINE, right? What makes you think SC2 won't run in WINE?
Personally, I thought the ads were great.
Way better than Windows Vista, too.
Is CmdrTaco unaware that del Toro directed the first Hellboy movie? He certainly didn't have quite the same license to create his own vision then as he does now, but he is the guy who got the first one so very right.
Nuts, I was hoping I could be the lowest in this thread. Still, at least there haven't been any 2-digit killjoys!
That just seems silly. I'd like to see performance tests on a system where the disk's performance affects the end result, rather than all of the results being homogenized by the operating system's poor I/O capability. Given Vista's adoption, it's not even a test of what disk performance will be like "in the real world."
There is no amount of time I could spend training myself in QWERTY that would keep it from hurting my hands and wrists.
Say what huh? That doesn't even make sense.
You can even get a dual DVI SDO card, providing the OP with exactly what they want.
I'm not sure what they recommend, but I can tell you what every company or organization I've worked with did, when they had more load than a single computer with a single CPU and a single disk (or RAID) could handle. They added more machines with a single CPU and a single disk (or RAID), and put it all behind a load balancer.
Databases are a bit different, in that most DB vendors make it more expensive to cluster/load balance machines than to beef up your existing machine, and indeed database servers benefit more from extra CPU than do web servers. So there are a lot more beefy multi-CPU database systems out there. . . but consistently, the first step in improving database performance is to pull it away from the web server.
The price/performance ratio involved in using a single beefier box to do everything is simply too poor compared to that.