Category: General

Recently, I had a conversation with a client who wanted to build an app, and was bamboozled by the options, didn’t know who to trust, who could do a good job, or knew what they were selling; or could spot any warning signs before picking an agency to build their idea.

It was dishearting, I always assumed, perhaps wrongly, that the terminology, the technology, the common interaction we now increasingly in society have daily with computers and devices meant that being able to spot warning signs and pick an agency to go with would be pretty straight forward.

Before transitioning to innovation; I spent the better part of my earlier career in web design, working at web agencies and app companies; it never once occured to me what a client should look out for in actually picking an agency to work with. I just assumed they knew.

It goes without saying that the interactions between a prospective client and agency is two-way; its a relationship, built on conversations, trust, evicacy and how well client expectations are managed.

In terms of a project; I think there are three main levels, with varying costs:

• DIY – Do it yourself. (£)
• Do it with help / Do it with you. (££)
• Done for you (£££)

Of course, there will be some interactions that cross the different levels; and this comes back to themes of scoping a project, project management, roadmapping and managing expectations.

There are some basic pre-work that can be done before picking an agency; and there are some warning signs or red flags and some general notes that may help;

Authority – Offline and online

• Does the agency have a good track record via their online authority, check Google, Facebook, TrustPilot or other online reviews out there. Don’t just go on how many followers on social media they have.
• Check if they have case studies, testimonials; just be aware, in today’s world testimonials can be bought. See if you can do some due diligence on the testimonials. Telephone or email one of the case studies and ask them how it was like to work with the agency; what was the one thing they liked and what was the one thing that you should be looking out for
• Do they have a portfolio? Some big name agencies do not publish or disseminate a portfolio
• Ask for a referral or get invite for pitch. You can do this through organisations such as a University, or a business advise organisation.

Getting a feel of the agency

• It can be intimitading, bamboozling or frustrating working with “tech” companies who may use or drop technical language in a conversation. If you are unsure of what a term is but do not want to reveal it in your early conversations with an agency, write it down and check it later online
• Are you talking with a sales person / account manager or the team that will actually design, build the product in question? A sales person is there to sell, a team will try to define and reign in scope of the job.

Scope of the job

• Sometimes it can be hard to know what the scope of the job looks like or feels like, especially if you’ve never done anything like this before. As an exercise, before talking to any agency – get a few sheets of A4 and start jotting down all the things you want the app to do. Be as divergent as you like in this first stage. Then, maybe the day after – question it; why is each desire important. Naturally, the more complex the job; the more likely it will cost time, money, effort, etc.
• If you’re still uncertain or unsure about scoping out a project of this kind there are free organisations you can talk to. Organisations like Sunderland Software City, or a University; the organisation you talk to should have no conflict of interest with any specific app agency — usually they will have programs designed for small businesses. They may even connect you to funds, or part financing as well. So it pays to do some initial leg work before you starting paying big bucks to agencies.
• Reducing scope doesn’t always mean its cheaper to build; Some companies will try to reduce the scope of work to be undertaken; but do not assume that this directly impacts cost; but do ask.
• Some organisations will offer you a MVP – which stands for Minimum Viable Product. Some people actually differ on what MVP is actually meant for. In the context of a website product or app being delivered and launched, the idea would be what is the minimum number of features you can get away with to test the idea, and how quickly can your refine or rescope the project to fit intial customer needs and requirements. In some cases MVP can be a cheap way of proving to yourself that the product solves a problem. However, if you feel the product you are making needs to be right first time (for whatever reason), then an MVP may not be right for you.

Getting a pitch

• Some agencies/companies no longer pitch or will bill for it. So please be careful before asking for it.
• If an agency does sends you a pitch document, invariably, it will be a template or may feel it doesn’t really line up with what you originally asked for — this is because agencies rarely have the time to spend to map out all the challenges, or technical work or hours that will be required on your project; this includes any time spent on testing, development, or fixing bugs.
• “Yes, we can do it” – Promise now, deliver later. In this concept, an agency may say yes we can do it. But look at their portfolio, look at their track record. Look at any case studies. Have they really done anything like this before? See if you can talk to their team directly through a free discovery call. If its a wholly new product, or its a company that actually thrives on new challenges; then this may mitigate this.
• “Yes, we can do it at that price” – Undercut now, bill later. Some agencies will undercut the competition to win the bid, then price up later jobs under the banner of “outside of scope” or “overruning costs”.
• “Inflated ROI” – The wow factor. Do not assume the numbers presented in a report, pitch are accurate. They are there to win you over.

Who owns the code, assets and IP?

• This is an easy one to miss; who owns the code created for your app, who owns the account created to launch the app on Google or iOS; do you want to own it, or are you okay to have the agency own it and you rent it from them? It may be very important to know this especially if you are going for investors or want to sell it on in the future; because the app, its code, it’s IP are assets!
• Some of the more transparent companies will give you view-only access to a code repository. You can see check-ins, code being created. This may give you peace of mind that they are doing the work.
• Ask for all code, art assets, IP, etc to be transferred to your account or available via a secure process; this may be useful if you need to transfer your app, website or domain to somebody else.

On-going support and maintenance

• Retainers and monthly maintenance costs. A lot of agencies use this, its their bread and butter. In web sites, it may cover security updates, code fixes, etc. In native mobile apps, they can be similar in scope. However, for apps I’d be very weiry about setting up paying maintenance fees without asking for what you get. Is it hours? Is it a number of revisions or code fixes? In what time frame do you get the fixes done? You may even ask for monthly reports about where the time was spent, and who did the work.
• Retainers for app maintenance – This is a real bug bare for me. I’ve met some app agencies in the past who charge quite a lot for app maintenace but don’t actually do any fixes or maintenance of any kind; unless there has been an outside intervention (ie: The mobile app’s software has been upgraded) — Again, my tip here is — ask them why are they charging maintenance, what does it cover, how many hours, can you get reports, etc. I think a pro tip would be — Have a service level agreement, minimum hours with logs baked into your contract.
• Get a website app vs Getting a product partner – So there are two main schools of thought for app / websites. One is purely transactional; you pay for the building, hosting, maintenance, launch and general up-keep of a website or app. The other is more consultative, and more in-depth; and can be more expensive. But if you’re looking for results and not just a transactionary project, this might be up your street. If you are looking for a partner, try to ascertain how they work; what the relationship will look like – how long will it work for, etc. Set a budget, set expectations. It may be 3-month, 6-months or longer.

The above list is not exhaustive, but shows a breadth of the interaction journey with an agency from discovery through to delivery then; post-delivery.

It can be daunting to get a project off the ground, knowing what agency to pick, the issue of trust, managing client expectations, gauging the level of on-going support or assistance you might need to get the project up and running.

I feel, as a general rule of thumb – the more up-front paper and pencil work you can do on the idea before you go to an agency, the better the experience.

I hope this has been of help.

The trade of keeping it simple stupid vs keeping code clean for Swift mobile apps

Single responsibility apps are a headache to code, to remember, to even parse visually; when it comes to simple apps — isn’t it just easier to keep it simple, stupid?

---

So I’ve been reading up on the idea of Single responsibility, which is aligned with the principal of SOLID, as popularised by “Uncle Bob”

Single responsibility is defined as:

The single-responsibility principle (SRP) is a computer-programming principle that states that every module or class[1] should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by the class, module or function.

Wikipedia – https://en.wikipedia.org/wiki/Single-responsibility_principle

Visually illustrated;

The idea behind SOLID, and that of single responsibility, is to ensure that your apps are de-coupled where business logic, the use-cases that sit behind your application are de-coupled from your models and thinly applied.

It is in-effect, separation of concerns.

I’ve seen a few VIPER design patterns that try to follow SOLID too; and to be honest, they are a real pain to understand, visually follow — and the same can be true for single responsibility.

The issue I have is that it can easily become really, really hard to visually read, understand or try to ascertain what is responsible for what.

So; I tried to do an experiment on a simple task – a Wallet class where the following two use cases apply:

• A Wallet can be credited coins (Int)
• A Wallet can be debited coins (Int)
• Validation of coins added, spent are outside of scope

To keep it very simple, the Wallet simply is a struct with cash represented by an Int

---

struct Wallet {
   var cash: Int
}

This is a model of a Wallet which holds coins/cash, represented by Ints.

Now, in the past I’d actually put my functions in this model; and it can become quite a mess.

But upon reading and trying to get my head around the concepts and ideas of Single Responsibility I’ve realised that putting functions, use-cases inside my models is not a good idea; and should be handled elsewhere.

Okay, so lets make a class where we have our functions.

class WalletHandler {
    var wallet: Wallet
    init(wallet: Wallet) {
        self.wallet = wallet
    }
}

extension WalletHandler {
    func credit(amount: Int) {
     wallet.cash += amount
    }

    func debit(amount: Int) {
       wallet.cash -= amount
    } 
}

Okay, cool — I’ve omitted any validation, and normally I’d put the functions into their own extensions.

But how is this any different to what we had before? All I’ve done is moved the code somewhere else?

So, as I understand single responsibility; the functionality of this module/code should follow seperation of concerns.

Okay, so this means we need something to do the work; I believe this is called an Interactor in some design patterns.

The Interactor is the thing that handles the business use cases; so let’s code that; not only that, we’ll seperate the use cases of credit and debit into their own delegate patterns.

The following code is visual pseduocode only and may not work.

class WalletInteractor {
   var wallet: Wallet
   var creditDelegate: CreditDelegate?
   var debitDelegate: DebitDelegate?
...
   func credit(amount: Int) {
       self.creditDelegate?.credit(amount: Int)
    ....
}

So the delegate (which could be itself via extensions) could handle the work

But this still isn’t good enough. The interactor knows about the model directly, and shouldn’t. The delegate patterns mutate the model directly, and shouldn’t — and so forth.

So that means we need more stuff.

We need a class that only do the Credit, another just to do Debit.

We need to inject the interactor with a protocol so that it has no knowledge of what model its working with; only that it has a protocol composition and now we must undertake actions against it.

So it would look something like this (again, pseduocode)

class WalletInteractor {
    var walletHandler : WalletHandler // reference to a class that holds the struct
    var creditDelegate ...
     var debitDelegate ...
}   

The credit delegate would perform actions against the `WalletHandler` which is just a class that holds the model.

Example:

class WalletHandler {
    var wallet: Wallet 
    init(wallet) ....
}

But this still isn’t good enough. The Wallet Interactor has knowledge of a class and is still is interacting with it, mutating it — and again; it shouldn’t.

Protocol all the things!

So; okay — lets go a little bit more extreme — and use protocol composition to make the Interactor only deal with protocols that I inject into it; the WalletHandler must also conform to protocols. This is going to get very messy!

We know we have 2 use cases: Credit and Debit

So let’s make protocols just for that: And we’ll add throwing too

// 2 use cases now added
protocol CreditUseCase {
    func credit(amount: Int) throws
}
protocol DebitUseCase {
    func debit(amount: Int) throws
}

We know that we need to credit and debit a wallet; that means we need a reference to functions to do this

protocol WalletCreditUseCase {
    func credit(walletHandler: WalletUseCase, amount: Int) throws
}
protocol WalletDebitUseCase {
    func debit(walletHandler: WalletUseCase, amount: Int) throws
}

But we can’t reference the class here or even the struct; that’d break stuff — so we need another protocol; a wallet use case:

protocol WalletUseCase {
    var wallet: Wallet { get }
    var balance: Int { get }
    var creditDelegate: CreditUseCase? { get }
    var debitDelegate: DebitUseCase?  { get }
}

The wallet use case gives us a get access to the Wallet struct; also a variable balance we can use to get to the cash value; plus we need to reference the protocols in variables for usage.

We’re going to use this stuff in our WalletHandler class;

class WalletHandler : WalletUseCase {
    private(set) internal var wallet: Wallet
    private(set) var creditDelegate: CreditUseCase?
    private(set) var debitDelegate: DebitUseCase?

    var balance: Int {
        return self.wallet.cash
    }

    init(wallet: Wallet) {
        self.wallet = wallet
        self.creditDelegate = self
        self.debitDelegate = self
    }
}

So what this now means is we can inject the Wallet Interactor with anything that conforms to the WalletUseCase; rather than the class directly.

Oops, seeing as we have declared creditDelegate and debitDelegate to be self, we need to add these functions:

extension WalletHandler : CreditUseCase {
    func credit(amount: Int) {
        self.wallet.cash += amount
    }
}

extension WalletHandler : DebitUseCase {
    func debit(amount: Int) {
        self.wallet.cash -= amount
    }
}

So here we have the actual meat and potatoes of actually adding coins or subtracting them; inside a class which holds a reference to the original struct.

But, what about the Interactor I hear you ask?

We know that the Interactor will have use cases of its own, it needs a reference to the wallethandler via the protocol named WalletUseCase; and we also need a reference to the two protocols WalletCreditUseCase and WalletDebitUseCase. Why these? Why can’t we just use CreditUseCase?

The reason is because the wallet has its own usage of the use cases; plus we need to know what wallet we are interacting with.

So lets code up a protocol to hold all the use cases that the Interactor will use:

/*
 * Protocol that defines the Interactor's use case.
 */
protocol WalletInteractorInput: class, CreditUseCase, DebitUseCase {
    var walletHandler: WalletUseCase? { get }
    var creditHandler: WalletCreditUseCase? { get }
    var debitHandler: WalletDebitUseCase? { get }

    var balance: Int { get }
}

The Interactor can now be created.

*
 * The Interactor responsible for implementing
 * the business logic of the module.
 */
class WalletInteractor : WalletInteractorInput {
    internal var walletHandler: WalletUseCase?
    internal var creditHandler: WalletCreditUseCase?
    internal var debitHandler: WalletDebitUseCase?

    var balance: Int {
        return walletHandler?.balance ?? 0
    }

    init(walletHandler: WalletUseCase) {
        self.walletHandler = walletHandler
        self.creditHandler = CreditUseCaseHandler()
        self.debitHandler = DebitUseCaseHandler()
    }
     ... // code trimmed
}

The wallet interactor will have 2 functions;

• credit and,
• debit

In both cases they will call a handler (CreditUseCaseHandler and DebitUseCaseHandler) respectively.

So something like this (pseduocode follows)

// inside the Interactor
func credit(amount: Int) throws { 
   do {   
      try creditHandler.credit(walletHandler, amount)
   }
    catch {
      throw error
    } 
}

The above code isn’t complete; its just representative.

Okay, so now we need 2 more classes; the credit and debit class.

// Credit Handler
class CreditUseCaseHandler : WalletCreditUseCase {
    func credit(walletHandler: WalletUseCase, amount: Int) throws {
         if try canCredit(walletHandler, amount) { 
             try walletHandler.creditDelegate.credit(amount)
         }
     }
}

Both classes follow a similar pattern, and again; the code is not representative of functioning/working code.

Phew.

A gist of the actual code used can be found via:

https://git.io/JfxAE

So we have lots of code, and now it’s a real headache to figure out what the hell is going on; who is responsible for what; and where the business logic is actually happening.

If I were to draw it out; it’d look something like this:

It feels like we are kicking the ball further and further away from the original model.

The wallet struct needs to be fed into an interactor; but the interactor can’t know “too much”; so we end up stuffing the Interactor full of protocols and delegates (which isn’t the issue).

There are now 2 models; one, the original struct and on the right is the object as used and manipulated by the app which I guess is fine?

What makes this poor for me is that you can simply just call the struct directly and make your manipulations – thereby by-passing all the nice throwable validation you’ve written. Or, you could call the WalletHandler class

This seems like a mess — and it is!

So whats the insight here? What have I learnt?

Sometimes its just easier to make things stupid and simple; have my interactor but that does all the work and ignore all this other junk.

But; for bigger projects I can sort of see how it might be used; and that’s the real responsibility of this design pattern.

For me, the biggest insight is that this design pattern concept is just that — its just a concept; its not a hard rule, its a CHOICE to do this; for me, I just want to get my app done rather than getting it “right”.

References / Sources:

• GIST of project:
  https://git.io/JfxAE
• Secret behind single responsibility
  https://medium.com/hackernoon/the-secret-behind-the-single-responsibility-principle-e2f3692bae25
• Clean coder
  https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
• Uncle Bob presentation on SOLID / Single responsibility
  https://www.youtube.com/watch?v=Gt0M_OHKhQE

I’ve been experimenting recently with SwiftUI, whilst I’m not great at it; I really appreciate the fact that its now much easier to layout views without all the un-necessary constraints which usually end up breaking. Further, it seems to be much easier to support bigger devices, landscape mode and yes, even dark mode.

Whilst there are concerns about tableviews (in SwiftUI they are called lists) and how slow they are with a list of a lot of rows and not all the UIKit is 1:1, I do feel it can change the way views can be coded.

One of the principles that SwiftUI tries to evoke into programmers is that the view is a struct; meaning any changes discards the old view and it re-renders. Further, if you want to tie your data to the view, then you can also feed it a struct.

What this means is that view controllers follows more of a MVVM style; rather than baking everything into the view controller.

This has changed the way I write legacy code, I now try to feed views structs which may share some properties with an entity; but they are seperate/abstract, which keeps the dependency between models and views a bit looser.

I think I will spend more time in SwiftUI as it increasingly improves. All the examples I’ve seen online have impressed me to at least experiment with it.

Recently I decided to try and learn a bit of Core data from the ground up. I’m not familiar with all the aspects of Core Data, however, since starting to program with Core Data I remembered why I hated it so much.

Its really painful to setup, use or understand why things work the way they do. Using XCTests to test whether background saving is working is also a pain.

When comparing it with Realm, its night and day. I find Realm really easy to setup. Its easy to understand how the threads work; however, its still not 100% great. One of the aspects is exporting it to Github. Its a very large file, but there are ways to get around it.

I’m hopeful given the advances in SwiftUI, which is fantastic, I hope someone comes back to Core Data and makes it better.

If I stick with it, I’m sure I’ll pick up Core data more.

Over the past two or so years the public sector has seen an increase in service designers. One only needs to look at the influx of service designers in Leeds and other areas where they are looking at services in Pensions, and other verticals.

Given that service design works with the idea of placing the user/human at the centre of a service, and the main beneficiary; I’ve given some thought and wondered:

“Is the purpose or goal of service design employed in the public sector to get to more yeses?”

When we look at service design blueprints, and user journeys, often we will see a pattern that shows the “golden path”, a route where positive outcomes are framed.

However, this got me to thinking — sometimes, a user may get an answer that is akin to a “no”. Given this, the user may think that the system is poor, at fault or didn’t care about their issue.

The basic idea is this: If you got a “no”, does it mean you got a poor service?

I’m not sure. There may be very good reasons a user got no, but that doesn’t mean all services must be positively framed/goal orientated. But it’s an interesting question that I would like to follow up on.

So I overheard a conversation recently where someone was connecting the dots between the increase felling of trees and the creation of a 5-G network; the idea being that 5-G’s biggest issue is that trees block or interfere with the signal.

Now I don’t know if this statement is true or not, thats not my call; I’m sure there’s lots of tests from academia, business, etc that supports these claims.

However, I think there is another possibility. If we apply Occam’s razor, my hypothesis is this:

Council’s have very stretched budgets, the maintenance of trees cost a lot of money at scale; thus, they have decided to cut trees to save money.

Now, that’s not to say 5-G is connected; it’s certainly a beneficiary, but I don’t see it as a major driving decision.

Lately I’ve been thinking about innovation as a career path; having completed a Masters in the area and spent over a year helping businesses and SMEs innovate, clarify thinking and helped identify near-term and long-term goals, I’ve thought how do consultants sell innovation?

By all accounts, I’ve found innovation hard to sell. It’s intangible and is seen by many as something other people do. On the hierarchy of basic needs, a business would always rank cash, revenue, operating costs and profitability more importance.

And yet, innovation is necessary for growth. Whether it’s an internal process or an actual product/service, innovation lies at the heart of a company’s strategy.

But is innovation soley for big companies with the capital, resources and people to do it? Or can the little guy, the small business also benefit from design thinking, service design and applied innovative thinking?

I think so, for small businesses its important to look at what are the emerging opportunities for them now and what is the why behind it all.

Why I enjoy innovation consultancy is that its speculative, future-casting, its casting a vision of a positive outcome near-term and long-term; only through further refinement and co-creation with clients can businesses conceptualise and formalise the next steps.

Having attended a small business festival’s workshops, where people could attend small classroom like rooms and listen to speakers, I realised that I really don’t like classroom locations where the audience is listening to speakers.

I actually think the traditional small classroom speaker audience relationship must change. The traditional model is a speaker talking to an audience, in a lecture type environment where its assumed the speaker is an authority and through lectures delivers content.

If you’ve ever sat in such environments, there’s almost a feeling of being lectured at. I don’t like such environments, and feel the traditional orthodoxy that the speaker knows all and is sharing his/her knowledge from a pedestal must change.

Lets try inverting the relationship. So, instead of a presenter talking to an audience, get the audience speaks to the presenter.

Of course this is not a new or novel concept. The idea of participatory workshops, or small sprint teams or where the audience explores and challenges ideas using co-creation techniques has been around for a while.

There are many benefits to this.

1. It gets people talking
2. Random collisions between people might uncover shared traits, skills, connections or beneficiaries; how else would you know that a person on a table might actually offer a shared skill
3. The volume of insights generated are greater, richer
4. The audience feels they are working through the challenge, and new questions, ideas and solutions can be framed from this discovery technique.

Whilst I do not advocate using this technique all the time, I do feel business events with speakers must try to ask themselves, what is the key piece of information or take-away you want to impart to the audience; what do you want them (the audience) to do?

Given the right context, I feel if we invert the presenter-audience relationship, we can explore greater avenues of possibilities, and innovate together, rather than in silos.

Back in the early 90s, Channel 4 put on a series of Jackie Chan and other Hong Kong action movies. I remember watching them, throughly enjoying Police Story, Armour of God and Wheels on Meals.

This general interest lead me to buying and collecting Impact! magazine (until I stupidly got rid of my collection) and going to rent, watch action cinema from Hong Kong. For me, action movies from that period of time was so unique, fast paced and different from the slow, plodding sequences from Hollywood.

What’s more, the heroes in these movies were mostly “every man”, whereas the brute force action heroes of Hollywood were big, slow and strong; whereas people liked Stallone and Arnold, I was into the fast paced action of Jackie Chan, Jet Li and even female action heroes like Cynthia Rothrock, Michelle Yeoh, Michelle Khan, and others.

Whilst Hollywood had its spectacle, big budgets, big set pieces; Hong Kong (and asia) offered frenetic, fast-paced action sequences, where heroes often outnumbered, or put into difficult odds.

Lately I’ve been re-watching some of the older Jackie Chan movies; and yes, I agree – his work from the 70s through to the 96 is way better than anything he ever did in Hollywood (yes, I include Rush Hour into that).

So this lead me to the question; just what is Jackie Chan’s best movie.

One could look at this from a financial point of view, from importance to his career point of view, etc. I wanted to look at it from purely a personal point of view.

I don’t expect you to agree with me. It’s just my opinion.

Here’s my take on what’s his best movie: Police Story (1984).

Yes, there’s an argument that Miracles (1989) was a more important work (being Jackie’s passion project). There’s an argument that Dragons Forever (1988) has more action. And yes, you could argue that Armour of God (1986) was more fun, or that Police Story III (1992) had more stunts; and yes, Drunken Master II (1994) won more awards and is considered to be, by many, Jackie’s Magnus Opus.

For me, Police Story (1984) is Jackie’s best movie. Whether its the mall sequence at the end, or the fact it was Jackie’s direct retort to his bitterness over The Protector (1984/1985); there is something about Police Story that I really enjoy.

Sure it has some weak parts and there are sequences that go on a bit too long, or are perhaps lost in translation, I do find and enjoy Police Story just that bit more — maybe its the way its shot, or that Chan’s character “Chan Ka Kui” is a loose cannon, only to have his redemption at the end.

Overall, I feel perhaps this movie encapsulates Jackie’s style – it has his patented stunts, it has the multi-man fights, it has a good enough story and offers Jackie as an everyman hero following a redemption storyline and is certainly a movie you should see.

With so many re-boots, re-imaginations of the Terminator franchise, timeline, storyline; its hard to keep up whether the latest instalment, Terminator Dark Fate, offers something new, or repeats the mis-steps of the other movies.

How many times must James Cameron, the director of two of the Terminator movies, come out and put over the latest Terminator movie; only then to put coded messages out in press junkets that he didn’t really much care for the movie. It’s become so bad, that I’m wondering if people can ever take Cameron at his word again.

So what exactly is the issue with The Terminator franchise, why does every other movie after “T2 – Judgement Day” try to retcon other Terminator sequels. Why still do they fall short? And why, does this movie not learn from these mistakes?

Put aside the many writers, re-writes and plot leaks this particular version, or the poor first trailers which did little to sell the movie.

Put aside the snide comments by Youtube! posters who declared that this movie was going broke because it went woke.

I’m not interested in such commentary. Such commentary doesn’t look at what the movie fails to bring; and that is, in my opinion, something new.

The original 1984 Terminator movie can be seen as a horror-thriller-chase movie, it’s sequel, offered multiple strands of character arcs framed by special effects and stunt set pieces.

As many other commentators have stated, the series was pretty much done after T2. Scenes edited from the movie, available through blue-ray, saw an ageing Sarah Connor narrating a hopeful future; and cementing the fact that there is “no fate but what we make“.

This core, central message underscored the whole movie and wrapped the whole series up. And yet, despite this; producers in Hollywood still wanted to make money from this. I can understand why, but from a story point of view, there is little direction the series can move to.

I’ve heard ideas from people that the third movie should be about a whole army of Terminator’s being sent to the past, or that the entire movie should be set in the future war that we see glimpses of in Terminator 1 and Terminator 2. Whilst both ideas are different, unless they wrap up the John Connor storyline, they too fall pray to breaking the idea of “no fate“.

If we look at Dark Fate, the core message of “no fate” is killed within moments of the first movie by a poor writing decision to eliminate a key figure from the storyline. This decision undoes the second movie, to the point that it ignores the central core message for its own end, to sell more tickets.

This is the key issue that all the other sequels also employ: They must ignore the issue of no fate, because there wouldn’t be a movie otherwise. There must be no end, storyline be damned.

So why does every movie following T-2 seem to fall short of audience expectations, and why does every movie seem to want to retcon the central core theme, and seem to want to retread steps.

Even in Dark Fate, the movie retreads steps that we’ve already seen in previous incarnations. They replace SkyNet with another AI; which is SkyNet in all but name only. They reheat themes, beats and storylines from other movies. They remove key figures from the mythos, only to replace them with other people that are exactly the same.

Whilst I’m sure most of these have been done to lay the foundations for another set of Terminator movies, I for one, am not sure if the series is already damaged, that it was already lost; and it doesn’t matter how many times it attempts to fix its own timeline, it can’t seem to bring anything new.

The one thing that connects this movie with other movies (be it the Ghostbusters remake, Star Wars, or others), is the use of nostalgia marketing to draw audiences.

I’m sure Dark Fate will have its audience, it will draw ticket sales and fans worldwide; however, it’s not for me.