4 ms·

Not exactly related to the interview, but I remember reading about you from some of Andy Gavin's series on Crash, and wondering what the transition from Naughty

Not exactly related to the interview, but I remember reading about you from some of Andy Gavin's series on Crash, and wondering what the transition from Naughty Dog to ITA was like? I just imagine that personally, I would struggle to transition from game programming where even with great engineering standards, lots of things are more 'get it done fast and close enough to right, and if something just won't work, kluge it together because we have to ship in a week and if there is a collision detection problem leading to a crash because a player jumped from this particular pixel at this particular speed, just put a crate right there so they never can jump from there' and you're doing a AAA title with less than 10 people in less than a year (or whatever the short time horizon was on Crash) to something like ITA where I would imagine there is a lot more rigor and having a tax rule incorrectly applied could be the cause of hundreds of thousands of dollars of loss for you or a client, not to mention it takes five years to build a product. My question would be, are there any good resources you can point to that would help someone trying to understand what the truly important engineering practices a software developer needs to follow are?

dmbaggett 11y ago
You're right that it was a bit different between the two projects. Part of the reason for that, though, is that the tools themselves evolved a lot between the beginning of Crash and the middle/end of ITA. And ITA was a linux SaaS shop, so we benefited from all the improvements to tools in that stack. With respect to resources on practices, I think most of the agile literature is reasonable. In all the domains I've worked in, the biggest challenge with doing things agile-ly has been testing: the domain complexity makes it very hard to comprehensively test the software. In the case of Crash, we just dealt with it with huge amounts of human testing (and we fixed the hundreds of reported buts). At ITA and Inky, we had/have more custom automated testing infrastructure. One lesson is that a system like ITA's or Inky's basically can't be correct unless it's exhaustively tested.
- deleted 11y ago
  [deleted]
- edwinnathaniel 11y ago
  Hear Hear. My previous employer is in the field of network and application performance management. Even with unit-test, integration-test, and some functional-test, we can't be 100% sure we've covered everything (e.g.: different network setup) due to the domain complexity. Having said that, "testing" has always been the biggest issue for any shop that call themselves "Agile" and it's also my screening test when interviewing with any company that claim themselves "agile": "let's talk about automation test..." :)
  - aidenn0 11y ago
    Testing (particularly integration testing) is just as important in non-agile shops. The difference between companies that do a lot of regular testing (whether automated or just with a big testing department) is huge.

dmbaggett 11y ago

You're right that it was a bit different between the two projects. Part of the reason for that, though, is that the tools themselves evolved a lot between the beginning of Crash and the middle/end of ITA. And ITA was a linux SaaS shop, so we benefited from all the improvements to tools in that stack. With respect to resources on practices, I think most of the agile literature is reasonable. In all the domains I've worked in, the biggest challenge with doing things agile-ly has been testing: the domain complexity makes it very hard to comprehensively test the software. In the case of Crash, we just dealt with it with huge amounts of human testing (and we fixed the hundreds of reported buts). At ITA and Inky, we had/have more custom automated testing infrastructure. One lesson is that a system like ITA's or Inky's basically can't be correct unless it's exhaustively tested.

deleted 11y ago
[deleted]
edwinnathaniel 11y ago
Hear Hear. My previous employer is in the field of network and application performance management. Even with unit-test, integration-test, and some functional-test, we can't be 100% sure we've covered everything (e.g.: different network setup) due to the domain complexity. Having said that, "testing" has always been the biggest issue for any shop that call themselves "Agile" and it's also my screening test when interviewing with any company that claim themselves "agile": "let's talk about automation test..." :)
- aidenn0 11y ago
  Testing (particularly integration testing) is just as important in non-agile shops. The difference between companies that do a lot of regular testing (whether automated or just with a big testing department) is huge.