EVE General Discussion

Just like with PvP in EVE: You fail horribly often enough, you will eventually get good at fighting. You die, you learn. It's the EVE way.

the hamster breeding program, they now have thoroughbred ones by this stage.

Practice.

Lots of practice; and After Action Reviews. Look at what you got right, and wrong, so you can keep doing the right things, and not do the wrong things.

and QA.

In short, continually striving to become better than last time. It's a near-constant effort and, as you see, it pays off very handsomely. Always looking for optimisations and improving our estimations and risk assessments, and we know we can keep going and do better!

EDIT: Shameless plug - here's an example of a large change we made.

CCP is not trying to shove a half a baguette in their mouth anymore, they are eating a slice at a time.

Continual process improvement. If you have standardized build and deployment processes, then you can a) automate them, and b) you can improve them as you re-use them. However, if your processes rely on ad-hoc and/or manual steps, then every process is unique and thus cannot be re-used which means no process improvement. Meaning every ad-hoc/manual step has probably only been tested once or twice (or not at all) in a QA/pre-staging environment by your SCM/deployment team before being run by hand during the production deployment (which occurs during off-hours when everyone is brain dead.) Manual steps are not a recipe for success on the first try.

Follow the damn Process: (aka "fast isn't fast, smooth is fast.") Taking short cuts, at best, tends to result in a gain in the immediate short term. Some of the time. For a few people. Short cuts, in the average case, tend to make more work because your shortcut tends to get someone else downstream screwed, e.g. a developer who "re-uses" a ticket to check-in instead of creating a new one has saved themselves a few minutes of work, but now the QA team isn't going to get an accurate build report and will waste time re-testing the wrong thing, thus the check-in will contain untested code, which could introduce bugs, which will confuse the prod support team (according to the patch notes, that system wasn't changed, so we didn't troubleshoot it!) which results in the developer having to work extra and/or off-hours to find the problem and check-in the fix. A fix that requires the following people's time to implement: dev, dev manager, dev ops, change control board, SCM, QA, spouses & children, etc..

Following and Improving the Processes tends to result in smoother dev cycles, i.e. more time working and less time fighting fires. This is in turn reduces stress, results in people getting more sleep (i.e. less off-hours bug-hunting, fewer people needed for off-hours deployments, etc.) Which in turn results in a better quality of life for your teams, which results in happier employees, which results in lower turnover, which results in more experienced devs, and expreienced devs are many, many, many more times more efficient than a horde of newbies.


tl;dr - Only a moron (aka a bad developer) calls it red tape.

/rant off

Feeding QA people will beer would be counter productive...

At least nothing has gone skynet again, so baby steps.

QA is hugely important in many things.

My line of work is far removed from making games (aircraft engineering) but there is always a drive to follow process and improve it too. That's not to say...."workarounds" don't happen.

Stoicfaux what you were saying is anything but a rant.

Tbf that video is nearly as long as the patch. Can't you just issue 5 minute voiceover summaries of these vids with Mr G doing the shower thing?

To answer the OP, nothing has changed. Pretty sure we can still bellyache about something.