DayZ Critique - Part 11/13 - Update #1 (Patreon)

Good evening folks. Hope you've had a lovely weekend.

Thanks for participating in the poll from the start of the week. It helps gauge where general opinion is and helps me avoid potential missteps when it comes to starting projects. It appears that most people fancy another video-essay piece where I waffle on about stuff related to DayZ. And I am more than happy to oblige.

On the bullshittery front though, fear not. The next episode on that will start as soon as possible. I just need to massage things to keep all parties happy and hopefully provide some content variation. Both for the audience and my editing brain. Which is relishing a break from constant keyframing.

It's been a fantastically productive week however. I've felt energised, confident and laser focused.

I've managed to get lots of audio recording done (usually at night when there's reduced background noise in the city) and have cut half of the episode into its near final form. 

This has been very helpful because, in the words of MauLer, an excellent video-essay Youtuber who I strongly recommend: "draft, review, re-draft, repeat". Meaning that hearing my own points spoken back at me has helped me identify where my points in my draft have been weakest. Allowed me to redraft and re-record. I'm going to make sure I have complete audio from beginning to end before I really work on the visuals.

So this particular part of the series is Part 11 - Wasted Development. In which I discuss the importance of specific roles within a SCRUM development team. And why it's sometimes quite important to have someone internally who is intentionally critical of the work being done. Almost abrasively so. For the sake of overall product quality. Someone who is actively asking questions like "why are we doing it like that?", to make sure the answer is sufficiently convincing when voiced openly around the table.

I'm doing this because I feel there are multiple moments during my dev blog notes that stand out as unusual. Where non-essential work is being put forward too early. Where mechanics are being made more advanced despite the user story seemingly having been satisfied. Where effort is being put into features that are clearly very edge case (very rare). Or where complex mechanics are put into place which are almost certainly going to be rendered obsolete when the modders arrive.

The episode itself is quite speculative however. Since unless you're part of the development team you just can't know. But I'm hoping it'll prove interesting window insofar as how SCRUM teams need to think. Or at least show why it's important to test internal logic, without necessarily surrendering to every good idea immediately. Like part 10, I'm hoping it'll prove more interesting to those who have no exposure to software development. Less about the material and more about the process.

So in terms of time estimates, I'm afraid this episode looks like a biggie.

The episode in text only form is about 8,500 words. That puts it in the 35 to 40 minute duration range. The timeline is averaging about 25 audio cuts per minute, meaning it's about 1000 cuts. Whilst most of the audio has been recorded, I'm only up to about 500 cuts in 5 work days. So by the end of next week I should have complete audio at least. 

What I could always do then is intentionally focus on the visuals for the first 20 minutes? And if that goes well, release it to you guys to get your opinions. Then you can decide whether I should continue to completion, or park it and start the next bullshittery.

As always, I edit to your pleasure.