3 ms·
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 b
by 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 agoHear 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 agoTesting (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.