silentflute

Author: Amo

  • Review: Your Next Five Moves by Patrick Bet-David

    This is an unsponsored review of the book “Your Next Five Moves” by Patrick Bet-David.

    Buy now on Amazon UK

    Patrick Bet-David (PBD) is an American business owner who is the host of the Youtube! channel Valuetainment with over, to-date, 2.9M subscribers. PBD went from Iran to founding his own financial services firm PHP and has become a leading Youtube! personality with a number of compelling video interviews with the likes of Ray Dalio, Kevin Hart and the late Kobe Bryant.

    His 2020 hardcover book “Your Five Next Moves: Master the Art of Business Strategy” is about 280 pages and covers the idea that a majority of today’s most successful business leaders and organisations are successful because of their ability to look ahead, to see what is in front of them, to see the plays coming up and behind able to react, to outstrategise or out-think the competition where it counts.

    Like the game Chess, PBD argues, the top players in the field of business and use clarity, strategy, tactics, insight, experience to frame the opportunity, risk, investment and payoff; mixing foresight and hindsight, data, analytics and ideas into strategic plays.

    The five moves are:

    1. Master knowing yourself
    2. Master the ability to reason
    3. Master the building of the right team
    4. Master the strategy to scale
    5. Master the power plays

    Told through a prism of stories, Your Next Five Moves, frames the five moves through PBD’s personal storytelling of his personal journey with success, failures and what he learnt from it and links it to one of the five moves.

    As such, the book is part-auto biography, part-business thinking and part-advocacy, and frames ideas of introspection, goal setting, the ability of removing emotion when approaching difficult conversations and using strategy to position outcomes to your favour through negotiation and offering something in return.

    From the outset, the book starts from the position you must get clarity of who you are, where you are at, where you want to be, who you want to be, and what are you willing to do to get there. Introspective activities include a Personality Audit, and a challenge to use the Five Whys to keep asking why until a purpose is revealed.

    Post introspective ideas, later chapters talk about the reasoning and sense making when making decisions, one of the ideas PBD offers is that of an Investment Time Return (ITR) formula that he encourages his team to embrace in every deal, or opportunity.

    PBD also offers the idea that in meetings, using stoic thoughts or analysing what is being said all be parts of the plays one makes to ensure high emotion can be avoided.

    One tool PBD advocates using when making strategic decisional making is a Solve for X worksheet (which is included in the book) where he advocates his employees and himself to use to evaluate the real underpinning cause, and align this with urgency, people needed, the available solutions, to list possible negative outcomes and what new protocols can be birthed.

    In move 3, PBD reiterates the idea you can’t get to the top of the mountain by yourself. You’re going to need a team, and the more strategic thinker will ask what the make-up of the team will be, how do you attract and keep talent beyond simple financial compensation models.

    In move 4, PBD mentions that if you want to be strategic – you need to think long term, that your business needs to work without you, that to move from the solo-business to the micro to the macro business you’re going to need to scale. Although the materials of scaling aren’t included, it would seem that PBD links team, processes, internal and external competitiveness, branding and marketing together to create a golden thread of what scaling actually means.

    Finally in move 5, PBD outlines a list of strategic power plays that may help when things aren’t going well, and conversely; what to do when things are going well

    One of the things that comes across from the book is PBD’s competitiveness, and imposing a demanding approach to his team to be as competitive as himself, with processes, systems, discussion and techniques to ask his team not only to move quicker, but ask how to get better.

    Whether it’s forcing his employees to read books, write reports; or if its asking his team to be analytical – its clear that continuous improvement, process and being competitive is very important to PBD; whether its replicable I’m not sure.

    The book is well written, is throughly from a storytelling perspective. If you’re expecting the book to be technical, I’m sorry to disappoint you. The book is not a tactical playbook chock full of strategic plays that one can play; I think this is a bit of a shame, considering how the book was marketing and how PBD framed it. I recall in his videos PBD would state how it took him over 2 years to write the book, and how over 100+ strategic business books have influenced his thinking. Given this, one might expect a consolidation or curation of what these business books have taught him and how they reflect against the five moves he advocates. However, this does not occur.

    Concretely, the book offers a few worksheets and a website with resources and other books to read. It offers ideas that perhaps you can use to help frame your current situation and see how it might apply. However, the book given its position from a storytelling perspective is not a book about corporate level strategy, or how a micro business might use the same plays to be competitive. In this regard, the level of strategy offered is surface level, personal level; and this is fine.

    From a critique point of view, the book sometimes conflates situational awareness with strategy. Perhaps this is intentional. Many times the examples given are just situational awareness, how to develop it, how to react to it, how to predict it. In this way, I think its fine to do this. But just don’t expect book-smart, corporate level strategy. It doesn’t consider how Porter’s Five Forces actually works in the real world. It doesn’t look at how McKinsey or other big-name c-suite consultants use strategy (which I think is a shame), and it doesn’t say – “this is how they do it, but this is how we do it in the real world, and this is what you should learn from it”.

    One of the formula’s given is the ITR (Investment, Time and Return) formula. There is tendency that PBD has to frame everything from a transactional point of view. And I’m not 100% convinced that every decision that a business makes is transactional, or has a capitalist foundation. Despite this critique, I feel such forumlas are timely, useful reminders to readers that business owners must not only be situationally aware of the offer, but also the payoff. Despite its pull, a business case may not be the only qualifier of whether a decision is a worthwhile one to pursuit.

    Given all of this, I think the book is very good; well written and has some good reasonable ideas in it that can be re-read and can help re-iterate that the difference between a solo business, micro business, macro business and big name business is processes, systems, methods, strategy, the ability to be humble, to learn.

    I would say its a worthwhile read and would recommend reading it. Just don’t expect a corporate level critique of book academic strategy and real-world strategy.

    Overall: 7/10

    Buy now on Amazon UK

  • Moving hosting

    I apologise for not updating my blog as much as I’d like to, but recently I’ve been rethinking whether or not I need a blog, whether or not things like medium, substack, twitter, youtube and other platforms have actually disrupted blogging.

    I am intending to move hosting, or just push everything to a free hosting site such as the official wordpress platform as I’m finding it increasingly frustrating how poor security is with my current host is, but also with the WordPress platform in itself. I’ve been looking at JamStack, or using a static site generator, or something similar where security is first, I can post without worrying about attempted bot attacks on the site.

    Another issue I’ve been looking at it is what is this site meant to be, is it my own personal thoughts or is it a lead-in to get some sort of sale or appointment. I think the two things are different. They are different brands, different channels and have different goals, and thus looking at alternatives at how the content I create (or lack thereof) can be hosted.

    I’m hopeful I can get something sorted very soon.

  • No code: A game changer?

    For many years web site owners may have had to go to expensive web designers, web developers, e-commerce specalists to craft their next winning website. Whilst this trend isn’t really going away soon, there is a trend that suggests using no code tools may offer a cheap, fast and effective way of prototyping, testing and launching new products.

    What is no code and why should you care?

    No code relates to the idea of leveraging software tools to create digital products, content without knowing how to program.

    It is seen as a game changer, as it fundamentally shifts power away from web creatives to the consumer. Further, it offers the potential for new product ideas to be created, and validated really quickly.

    For myself, I am looking at using Notion or GitHub or JAMStack tools for hosting my primary website as increasing costs and security risks are my main concern.

    Don’t develop the value chain, leverage it

    If we look at the value chain of a digitial product, it could be characterised as:

    Content creation > Generating demand > Capturing Demand > Customer Service

    Here are some cool ideas for each layer.

    1. Content creation

    Sketch, After Effects, Figma, Keynote, Premier, etc

    2. Generating demand

    Instagram, Twitter, Youtube, LinkedIn, HypeFury, Creator Studio, Substack, Notion, etc

    3. Capturing demand

    Calendly, Shopify, Webflow, Stripe, Gumroad, Product Hunt, AppSumo, Reddit, etc

    4. Customer service

    Zoom, Loom, Keynote, Slack, Whatsapp, Google Workspace (formly GSuite), Microsoft Teams, Trello, MightyNetworks, TrustPilot, etc

    Summary

    If you want to quickly validate your product idea quickly and at at scale, then no code tools can offer you a quick path at any part of the value chain.

    Other resources to check out

    Product hunt:
    https://www.producthunt.com/search?q=no%20code

    100 No code resources:
    https://trello.com/b/A4OmiAWb/100-no-code-resources

    No Code Founders:
    https://nocodefounders.com/

    The future is no code (E-book and Interviews):
    https://www.adalo.com/the-future-is-no-code/intro

    The guide to no code marketplaces:
    https://guides.everythingmarketplaces.com/

    WeLove NoCode showcase:
    https://welovenocode.com/showcase

    No Code MBA (Learning):
    https://www.nocode.mba/

  • The difference between innovation and invention

    Innovation and invention. From the outset, they look very similar; and often the words are used interchangability – but is there a difference?

    What is innovation?

    Innovation is great ideas realised.

    Dr Nick Spencer, Northumbria University

    It’s the churn of creation, development and implementation of a new product, process, service or intervention with the aim of positively impacting a stakeholder, a situation, a context through improved efficencies, effectiveness or competitive advantage.

    Innovation, generally, is seen to sit within 4 areas: Incremental, Sustaining, Disruptive and Radical; as per:

    Source: Viima (2019)

    A common meme on the subject,

    Innovation = Invention + Commercialization

    Source: MIT Technology Review and Kenneth Morse (founder and managing director of the MIT Entrepreneurship Center).

    Of course not all innovation is necessarily commericalised. It could be an internal processes, intervention; or it could be framed through a charitable or voluntary interaction.

    Regardless, innovation can give organisations the edge in a given situation or context, be it a new market, new product, new service, new processes, new interventions or interactions.

    What is Invention?

    According to the Cambridge dictionary, invention is defined as:

    something that has never been made before, or the process of creating something that has never been made before.

    Source: Cambridge online dictionary

    And according to Wikipedia,

    invention is a unique or novel device, method, composition or process. The invention process is a process within an overall engineering and product development process. It may be an improvement upon a machine or product or a new process for creating an object or a result.

    Source: Wikipedia

    So, what is the difference?

    Invention is about creating something new, whilst innovation introduces the concept of use of an idea or method for a given context or situation.

    Invention infers something “new”, whilst innovation infers an improvement, or contribution to an exisiting product, process, service, intervention or interaction.

    The main difference could be the pressure for organisations to been seen to creating something wholley new, when quick, innovative wins can be equally as positive.

    My take on the difference between innovation and invention

    My take: Innovation and invention aren’t necessarily seperate, some examples like the iPhone are both an invention and offers innovation through its design, user experience and leveraging other inventions and features.

    Inventions can be protected through intellectual property and patent procedures, whereas innovations may not hold the same weight in a court of law.

    The microchip is an invention; however, the Pentium chip or Intel chip are examples of innovation. However, the microchip in itself is an innovation on previous inventions such as the telegraph.

    Another example: the car is an invention, but innovations may tackle the underlying reasons behind why a car is needed or may offer transport options.

    My take is that innovation and invention are really part of the same thing, to positively discover, develop and deliver new ideas and bring them to market.

  • Thoughts & Notes to a future Multidisiplinary Innovation student

    Since completing my Masters in Multidisciplinary Innovation at Northumbria University (link) back in 2018; I’ve been approached by prospective students asking me – What is the course like? And of course, the more interesting question; is the MDI course worth it?

    Since completing the course; I’ve had a number of times to reflect back on the key insights and lessons I’ve learnt from the course; had time to digest on what I liked, and what I perhaps have critique of; some of which I will share in this blog post.

    My original motivations for doing the course was that I needed to shake up my career. Having spent the previous few months unemployed, getting nowhere with interviews and job applications; I felt that my own skills needed upgrading. In the fast paced world of computing, coding and software development, it can be very easy to be left behind if you are not constantly improving, pushing out a product.

    In some ways, being in the chair of a web and app developer; especally in those early days of pre-2018, we perhaps didn’t get a good chance to ask why? or what problem is it solving? To the owner of the business it was a sale, transactional, and the faster we got it out, the faster we got paid. We got paid on results, on outputs, on artifacts, not on outcomes.

    Further still, I felt that the world of concrete transactional websites and apps seemed to miss something; a clarity of why, who it affects; and all the work that needs to be done before a single line of code is written. In short, the value. The value to society, to the end-user, the business, how it reinforces innovation and marketing efforts and keeps businesses competitive, but has an interplay outside the scope of the transactional into the transformative.

    This may sound incredibly fluffy. It did to me before the course; but having since completed the course, it did open my eyes to the prospect of the three main spaces: problem space, solution space, market space and how innovation isn’t necessary a medical product, or a new invention; but could be framed through design.

    If we imagine innovation as two primary world spaces, the world of exploration and exploitation as best described by Alex Osterwalder (@AlexOsterwalder) in his book Invincible Companies; then the former (exploration) is where MDI sits; it looks through ideas, themes, design briefs through specualtive, explorotory work; however this does not mean that students cannot test ideas with either offline or online customers (there were times that we did this).

    This can be difficult to process for many, I found it quite hard to grasp at first; having spent most of my career (as many do) in the world of the concrete, or as Alex Osteralder describes it, exploit; then it can be hard to put yourself in positions where you don’t need to get it right first time, that its okay to explore ideas without first putting constraints on it. It was difficult because I framed everything through the lens of business cost first and mitgitating risk.

    This is where I feel the MDI course sits, and plays well in; the idea of exploration, speculative; but also through framed experimentation, students can test ideas and then create a provocation to a client.

    Most of your time is on live client work, working in teams; using techniques as diverse as project management, strategy, design, scoping, pitching, crafting documents and reports; it is similar in scope to a design consultancy, but also has themes of a management consultancy, or an agency.

    To this end, I feel it is important to note that the course is NOT a traditional course in the sense of academic theory, exams, etc; but rather, its about the discovery, weight of argument, and reflective learning garned through the course.

    To reinforce this point; I thought I’d reflect on an email I recieved some time ago from a propsective student who wanted to do the course, but wasn’t sure whether it was worth it. Rather than posting the full email, I thought I’d share the most important insights.

    What do you do on the course?

    Its a 12-month course, aimed at a wide range of people, and you use design-led innovation working on live client projects, building up a portfolio, and your objective is to deliver innovate ideas, thoughts, provocations, solution drivers for those projects; work in teams, use strategy, ideation, design thinking, agile practices, pitching, presentations.

    It is more about the process than the outputs. Its more about the lessons and insights you learn about yourself, about the problem space, of continious improvement and how you worked with others, including the client.

    Does it have exams, how much theory is it?

    There are theoretical lessons, though we didn’t take exams. On a side note, even though the course has project management; do not expect a certification in Prince, Agile, SCRUM or indeed any other formal certification to support your exit from the course. If you require a professional certification, I would recommend a different route.

    It is mostly self-directed; I think it’s important to underscore this — it is self directed; are you comfortable with this?

    For some it can be a bit of a shock to move from a traditional top-down teaching approach to self-directed style; in this way, the teaching and academic “hand-holding” is light touch.

    Practally you will be exploring all sorts of live client facing projects in different domains. One week it might be a charity another time it’s a major utility company. Each has its own unique challenges.

    So is it a UX course?

    No. Its not a UX course. There is UX in it. But it is not directed, taught. There is nothing to say that you cannot learn UX, CX; in fact you should be; and then test the ideas of CX, UX on the project.

    Further, you can use your experiments to form the basis of your reports.

    Will I learn Photoshop or [Insert tool of choice]?

    No. Again, it’s not about tools. Its about the process. However, that does not mean you cannot learn Photoshop or, whatever tool of choice. In fact, you may be in situations where you have to learn it, and fast; this is where you learn the most about yourself.

    Why should I do this course?

    Your reason for doing the course will be different to mine. For me, it was about refreshing my career opportonities, getting a fresh perspective on my domain; understanding that I can leverage my abilities in discovery, finding unmet needs, or using constraints to test scope. I found this the most enjoyable.

    As always with courses it’s really down to you, your reasons, your goals and where do you want to be and who do you want to be.

    General advise

    Watch the videos on their site, check out testimonials, case studies, do a virtual tour; ask previous students what they got out of it, what pitfalls to look for, what they didn’t like; then ask yourself is it for me?

    Be creative in the delivery

    So when you create your delivery work package to the client or whomever it might be; try to be creative and break the cycle of death by powerpoint. Want to make a newspaper, go do it? Want to make a video of the problem, go for it. Want to present the ideas in a comic? Go for it!

    Get outside the building

    To quote Steve Blank, “get outside the building”; by this I mean, its very easy to be in the bubble of your group and think “we got this”; its hubris, and you should try to test it — this could be with interviews with the public, online surveys, facebook groups, graduates, industry, you name it.

    I would like also to add to this that you should try to make connections with industry; go to events, introduce yourself, the team, MDI, etc. It could be your ticket to a job, or at the very least gets you into doors for your final presentation.

    What are the pitfalls?

    I think its three-fold. One is yourself, your confidence in your own abilities, not necessarily self-image, but being able to push yourself to complete the task; job at hand, to take it seriousily, to learn, to identify when your getting “hot” and being able to identify areas where you’ve grown.

    Second, I would say is working with a team, this can be very hard to do and you may spent most of your time managing relationships within a team.

    Third, is managing expectations of the client, of the people you present to.

    You mentioned there are critiques of the course, what are they?

    My views are based on my contextual background within computing / software development and my expectations of what the course could and should be looking at.

    So, I felt there wasn’t enough exploration of new business model frameworks; such as the Amazon flywheel model, or what is disruptive innovation; how do you know when your business is disruptive, and what are the materials needed.

    There was a lack of theory; but this is so you can do client work. I recall my past software engineering course had 3-4+ hour lectures on C++; there is nothing like that here.

    I wanted more stuff from the insights from product / tech startups, what is product ownership, how did these organisations become successful; I did spend some time reading up on it, so it wasn’t really my expectations of this were not within scope of what the course could realistically offer.

    Finally, since leaving the course; I’ve found it quite hard to explain to prospective employers what we actually did, why its relevant to them; part of this reason is that employers are in the world of the transactional, the concrete, or; to put it more bluntly, in exploit mode. So it can be hard to explain to them why they should hire someone who is more interested in exploring the why, the what, the impacts and unintended consequences, or how design can be used to reframe the problem space.

    To add to this, I’ve found a number of innovation roles require some level of certification, be it Prince or SCRUM; so please bare this in mind.

    So was it worth it?

    For me, yes; It was worth it; but at the same time, I wish I had more — more lectures or theory on the things I’m interested in, especially from the current high tech space (be it how Amazon works, how NetFlix disrupted Blockbusters, etc); more chances to test ideas with the public.

    Also, I missed chances to explore what commericalisation of innovation looks like; what is presented to investors, etc.

    Regardless of these gaps, It did show me that I do enjoy the explore side of things much more; and I feel MDI can be worthwhile for any prospective student, however; if you feel you need a hard science masters, then it may not fit your requirements.

    As always, I would advise try to do a bit of due diligence on any course.

    Good luck.

  • So, what should you look for when picking an agency to build my website or app?

    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.

  • Movies where the action hero is above the material makes me want to switch it off

    I’m not exactly sure who started this trend, but I’m not a fan of action films where the hero seems to be above the material he/she is in.

    I’m talking about movies where the hero is talking out of the side of his/her mouth, cutting one liners all the time, makes snide or snarky comments or doesn’t take the situation seriously.

    I was trying to watch 2017’s Hitman’s Bodyguard starring Ryan Reynolds and Samuel L. Jackson and I switched it off as I couldn’t deal with the amount of times Reynolds or Jackson seemed to mouth off in the movie, not taking the threat in the movie as serious, or worth the effort; as if they’re in on the joke.

    I think other movies do this too, like Deadpool. I switched it off after 10 minutes because the hero is practically takes the threat in the movie as one big joke.

    Sorry — but if the hero in your action movie doesn’t feel threatened, or doesn’t take the threat posed to them in the film seriously; why should I?

  • Charlies Angels (2019) – Review

    Charlies Angles (2019) , Directed by Elizabeth Banks. Link: IMDB

    Charlies Angels (2019), directed by Elizabeth Banks, was an action reboot / remake of the 1970s TV classic of the same name and a series of movies from the early 2000’s that starred Cameron Diaz, Drew Barrymore, and Lucy Liu respectively.

    Whilst the former two movies from the 2000’s were tongue in cheek, mixed comedy with action sequences that took homage from The Matrix (1999) and other, similar Hong Kong action wire-fu movies; this movie takes itself a lot more serious, relies on subversion of expectations to deliver what amounts to an empty movie that lacks edge, feels lazy; and whilst enjoyable in parts, is very bland and forgettable.

    The plot of this movie surrounds a young company whistleblower who alerts the Angels of the theft of a new energy source that is capable of being weaponised.

    Playing in about 120 minutes, the movie sometimes has elements of humour with some sometimes good action sequences. The chemistry between the three main actors was at least good.

    For me, the movie just was very flat, and didn’t connect with me. It lacked a creative edge or vision; and lacked a connection with the audience. Some of the fight sequences just weren’t very good; and the heroes never seem to go through the normal hero arch or any real struggle.

    The movie, influenced by James Bond-esque sequences, and other spy genre movies, uses deadpan quips, dry and droll humour tries to push a commonly repeated cinematic narrative trope: the “strong woman in a man’s world” where the female actors look great whilst kicking ass.

    Despite this, the movie performed poorly at the box office and with audiences both domestically and internationally.

    According to 2019 Deadline article (How ‘Charlie’s Angels’ Fell From Grace At The Box Office With An $8M+ Opening), the movie had a poor $8.6M domestic US opening with an even worse opening in China. Deadline’s article points to script problems and an IP with no drawing power, adding that “[this is] what happens when you have IP, but there’s no reason for telling the story.“

    In addition, there was a bizarre choice by the director, to attack a key demographic for not going to the cinema to support the movie.

    Banks’ interview with Fast Company on Youtube seemed to coalesce this bizarre marketing choice. (Source: Youtube).

    Whether this bizarre choice to attack the audience actually lead to poor box office seems unclear – regardless, it certainly did not help matters.

    I get a general sense that it was combination a number of factors that caused the movie’s failure — from franchise fatigue, to the disruptive innovation caused by online movie streaming services such as Netflix; to the poor script, to an IP that had no real drawing power.

    All of this seemed to fashion a final product that was poorly crafted, ultimately, leading to poor box office numbers.

    How this movie should have drawn inspiration from the “Girls with Guns” era

    From a Hollywood perspective, perhaps it may feel that there isn’t that many female lead action movies; of course, in response, many counter this statement with Sarah Connor from the Terminator series, or Ripley from the Alien franchise, or 2019’s Alita Battle Angel or Atomic Blonde. There are examples, and plenty of them.

    However, as a thought experiment; I feel this movie would have been much better if it drew inspiration from the Girls with Guns craze from Hong Kong and Taiwanese cinema, of the ’80s and early ’90s. These movies were fast-paced and offered high octane action coupled with strong performances, with interesting characters.

    I’m talking about Iron Angels 2 (1988), Yes Madam! (1985), Killer Angels (1989), the Angel Terminators (1992) series; or drew inspiration from actresses like Michelle Yeoh, Moon Lee, Yukari Oshima and others then perhaps Charlies Angels wouldn’t have been as bad.

    For more information on the Girls with Guns era; I suggest reading Back Row’s in-depth article on the subject (link: Girls With Guns in Hong Kong: Beyond Michelle Yeoh & Cynthia Rothrock).

    As example, I’ve linked a short clip of Angel (1987) which showcases a style that I feel this movie could have drawn inspiration, and innovated from.

    Angel (1987) – (Youtube)

    Summary

    Charlies Angels (2019) was not the right creative vehicle to explore the idea of a female centric action cinema movie; and whilst it is enjoyable at times – is ultimately flat, feels lazy and forgettable.

    Rating: 4 / 10

  • Single responsibility can be a real headache!

    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;

    Clean Architecture
    Clean Architecture diagram
    Source: CleanCoder

    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:

    A messy visualisation of all the things involved in a credit/debit against a simple struct

    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:

  • How SwiftUI can change the way you write views

    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.