4 ms·

Oh, and I also have a possible theory as to why this is. Game developers are, for the most part, quite smart. When a game company, or any tech company, for th

Oh, and I also have a possible theory as to why this is. Game developers are, for the most part, quite smart. When a game company, or any tech company, for that matter, runs into a problem that needs solving, they generally try and solve it in-house to start with. The normal traits that make a developer good at his job (problem solving skills, intelligence, confidence in his/her abilities, etc) sometimes are their own worst enemy, as they feel that they can solve that particular problem. Very rarely have I found smart developers that understand and recognize their limits to the point that they suggest bringing in outside, professional help, rather than tackling the problem themselves. This makes them look bad to management and their peers, and can damage their ego. And it may seem like a fun challenge as well. They honestly think that they can figure out a solution to just about any problem, even if that problem is way outside of their skill set or experience. Personally, my experience is in architecting large, scalable, fault tolerant systems, like online banking, offshore gambling, government stuff, and online global gaming systems. I've been brought into more than a few situations where this has been exactly the case. Sure, the in-house devs have come up with a solution, and they're doing everything that a smart person would do for the first pass at a solution, but they don't have the experience to know what will or won't work down the road. Their first iteration ran into the same problems that every other first iteration had, but their timeline, budgets, and marketing pressures don't afford them the luxury of improving it to where it should be. I have the luxury of the experience to come in with knowledge of the 20th iteration of a solution, and can apply them early on in the process. My current contract is just like that... I made design and implementation decisions early on that seemed to make no sense to the devs, even after I explained the reasoning, but now that we're 8 months down the road and they see those designs in action, they get it. And a lot of that also has to do with the devs lack of experience and understanding of what an operations team needs to run the system. Anyway, this has been some of my experience, and it wouldn't surprise me to find that it could quite possibly be the case here.

uriel 17y ago
> Very rarely have I found smart developers that understand and recognize their limits This is the greatest problem in all areas of software development, not just games.
CWuestefeld 17y ago
I made design and implementation decisions early on that seemed to make no sense to the devs, even after I explained the reasoning, but now that we're 8 months down the road and they see those designs in action, they get it. To what degree does this refute the YAGNI principle? If the initial phases of the project don't need those sophisticated aspects, why would you design them in at the beginning? Don't interpret that as an attack. I'm really trying to resolve two principles that both seem obvious, but are in tension to some degree.
- nettdata 17y ago
  >> If the initial phases of the project don't need those sophisticated aspects, why would you design them in at the beginning? Because history has taught me that it will be a definite requirement later on (as in when going live), and the amount of work involved with going back after the fact and incorporating it is insanely high versus designing it properly up front. So that's not YAGNI, that's You Just Don't Know That You'll Need It. That's where the experience comes in. We're not talking about simple refactorings, etc., but major design decisons like technology stacks, architectures, etc. For instance, the biggest issue I've run into is having a live MMO that had the "new" requirement to be able to troubleshoot and debug a single user among hundreds of thousands. That is something best handled by a proper initial design, not a slight reworking later on in the process. As far as I'm concerned, too many people take YAGNI too far. There's a compromise there, and that's where the experience comes into play.

uriel 17y ago

> Very rarely have I found smart developers that understand and recognize their limits This is the greatest problem in all areas of software development, not just games.

CWuestefeld 17y ago

I made design and implementation decisions early on that seemed to make no sense to the devs, even after I explained the reasoning, but now that we're 8 months down the road and they see those designs in action, they get it. To what degree does this refute the YAGNI principle? If the initial phases of the project don't need those sophisticated aspects, why would you design them in at the beginning? Don't interpret that as an attack. I'm really trying to resolve two principles that both seem obvious, but are in tension to some degree.

nettdata 17y ago
>> If the initial phases of the project don't need those sophisticated aspects, why would you design them in at the beginning? Because history has taught me that it will be a definite requirement later on (as in when going live), and the amount of work involved with going back after the fact and incorporating it is insanely high versus designing it properly up front. So that's not YAGNI, that's You Just Don't Know That You'll Need It. That's where the experience comes in. We're not talking about simple refactorings, etc., but major design decisons like technology stacks, architectures, etc. For instance, the biggest issue I've run into is having a live MMO that had the "new" requirement to be able to troubleshoot and debug a single user among hundreds of thousands. That is something best handled by a proper initial design, not a slight reworking later on in the process. As far as I'm concerned, too many people take YAGNI too far. There's a compromise there, and that's where the experience comes into play.