Enforcing Test Driven Development into an Existing Project

In an earlier post I wrote about my observations of a book I have recently read called ‘Test Driven Development: By Examples’ by Kent Beck. The book talks about Test-Driven Development (TDD) and how to apply it practically. From this I wanted to get going with the concept as quickly as possible but without having to make an entirely new project. 

I started to think about how I could apply the practices taught into an existing node module I have written - and blog about too often - hosted on npm. 

In the chapter “How do you switch to TDD midstream” Kent describes how you might transition into using TDD and the issues that might rise from doing so. I have taken the liberty of summarising from my own perspective and will discuss how I implemented it into my latest football simulation engine code (blog). 

After reading TDD and considering its application, there were 4 main factors (tips) for enforcing TDD in existing projects:

·     Test the requirements, not the code

·     Start with new features/bugs

·     Refactor code with testing in mind

·     Ignore working code

As I opened the code and assessed my kingdom the extent of the problem became apparent. There were no tests, but the project was thousands of lines of code, had 3 main exported functions and around 50 functions throughout with no test data or examples to be used by the end user.

Kent says in his book ‘The biggest problem is that code that isn't written with tests in mind typically isn't very testable’. Which happened to be my first thought as I dug into the large functions I had made. Where do I start? I began to write a list of what of the different parts and split them into a simple table with the headers Test, Ignore, Refactor - keeping in mind “What you don't do is go write tests for the whole thing and refactor the whole thing”. I wanted to decide what could be tested, what should be tested and what shouldn’t be tested. 

Test: A new test should be written to test the functionality I expected from the requirements.

Ignore: Large bulky functions which called other functions and needed a lot of intense work to make it test ready.

Refactor: Code that could be refactored to make it testable.

Test	Ignore	Refactor
Input Validation	Move Ball	Set Freekick
Closest Player to Ball	Find Possible Actions	Set Corner
Closest Player to Position	Resolve Ball Movement	Set Penalty
Check Offside	Decide Movement	Formation Check
Split Number into N		Shot Made

The first and easiest on the list was Input Validation, so I began to write the first test for when a games initiation input JSON was validated. The first test was simply that we got an object back. Success! This led to a quick imitation for the other two main functions of the project; start second half and play iteration.

 I then wrote some negative test cases by purposely inserting input data that shouldn’t be valid. Importantly, the question I asked myself was, what tests cases were valid based on the requirements and not the code that had already been written. This caught a number of validations I was not already catching in the validation functions.

An example was when I removed the ball from the play iteration function input and the test failed - by not failing. How can a football simulation work without the ball? This is why Tip 1 is: Test the requirements, not the code

mocha.it('playIteration no ball with team',async() =>{

      letprovidedItJson= './test/input/badInput/noBallWithTeam.json'

      try{

        letoutputIteration= awaitvalidation.playIteration(providedItJson)

        expect(outputIteration).to.be.an('Error')

      } catch(err) {

        expect(err).to.be.an('Error')

        letexpectedOutput= 'Provide: position,withPlayer,Player,withTeam,direction,ballOverIterations'

        expect(err.toString()).to.have.string(expectedOutput)

      }

    })

Having fleshed out all the required checks on the input validation for the three main functions (using mainly negatives) I felt assured that the code would be able to tell the user when their input was wrong, and more specifically - why it was wrong. 

At the same time, I was doing some house cleaning of the code and some general refactoring. Additionally, a few bugs were raised in the GitHub repository by users of the module. 

Some related to queries on parameter names, others were refactoring suggestions, but some referenced specific issues being seen in the code. Players were getting stuck, the closest player to a position was incorrectly assigned and the ball was moving too quickly. Investigations also caused me to raise my own issues which I could also test. 

Bugs and new features for existing code mean that the requirements are set out before any changes or new code is written. The code should behave in a certain way and currently doesn’t. From this you can essentially work on a blank canvas in terms of writing tests (using TDD). Tip 2: Start with new features/bugs. 

For the bug of not calculating closestPlayerToBall, there was no way to validate the issue because there were no tests. I started to write a test case by placing players on the ‘pitch’ where I knew which player was closest to a position or the ball. The test then is simple - does the function, when given the input data, correctly identify which player is closest to the ball? 

Once we run the first test - and potentially get a FAIL, we can start TDD from the beginning. What is the simplest thing we can do to the existing code to make it PASS? By then following the TDD method the code was altered until it passed the conditions successfully. At which point we had a passing test for the closest player using TDD as the method. 

Writing tests for the whole project in this way and then ensuring they PASS would conform the project to TDD and I believe would reduce the number of small bugs that end up being raised in the Github repository. However, it is a long process and would take up a lot of productive time, when there are other big fixes and new features to address.

Another major issue was the way that shots are made. A player makes a shot, a bunch of logic plays out and then either the goalkeeper has the ball or it’s a goal kick. All without so much as a little ball or player movement. This leads to the next step in the introduction of TDD - Tip 3 - Refactor code with testing in mind.

The shot made function had been several hundred lines long and included a variety of methods within. This doesn’t test easily. As code was edited for v2.1.2 I started to make changes to make it as simple as possible, abstracting out functionality into smaller functions and thus making each component easier to test using TDD. 

It’s important to remember that this isn’t the time for TDD yet. TDD is the process and steps for creating code that passes the test. Following the rule of only writing tests for new features or bugs this extraction of logic into smaller forms sets us up for TDD without investing unproductive time into its making.

In the list I created at the start there appears to be no real difference between some of the functions in the ignore and the refactor slots. There are a number of reasons to ignore specific functions. For example;

-      The function is very large and/or complex

-      The function cannot easily be split into smaller functions

-      The tests would take a long time to write

-      The function isn’t broken

For example, in FootballSimulationEngine - Decide Movement cannot easily be split into smaller functions and is very large, Find Possible Actions would both take a long time to write tests for (because of its complicated logic) but also the function simply isn’t broken. Resolve Ball Movement requires a lot of random number generation and mathematics which makes it difficult to test and Move Ball isn’t broken either. 

This analysis focuses heavily on the code I have written and not the requirement which goes against tip 1, but this is mainly because of Tip 4 - Ignore working code. If it isn’t broken, don’t fix it.

Put in another way, it has taken two years (more or less) to get the code to where it is today, with time etched away from weekends and evenings. To use TDD in the whole project would mean to essentially start from scratch. In his book, Kent states “Spending money without making it is generally speaking not a sustainable process.” And as a subscriber to the statement ‘time is money’ it seems more responsible and a better use of time to slowly introduce TDD as bugs appear and are fixed, or new features are included. 

By v2.1.2 the list looked a big better. In future editions I can see some of the ‘Ignore’ items moving into the ‘refactor’ bracket, the ‘refactor’ tasks moving into the ‘test’ section and removing the ‘test’ tasks as tests are completed for them. See below for the table as of the commit of v2.1.2.

Test	Ignore	Refactor
Input Validation	Move Ball	Set Freekick
Closest Player to Ball	Find Possible Actions	Set Corner
Closest Player to Position	Resolve Ball Movement	Set Penalty
Check Offside	Decide Movement	Formation Check
Split Number into N		Shot Made
Shot Made

 If you want to see a wider use of TDD in the FootballSimulationEngine code I’d love to see more enhancements raised in the Github repo. Thanks for reading. 

Observations of Test Driven Development

I was recently recommended the book ‘Test Driven Development: By Examples’ by Kent Beck in order to evaluate the methods engaged when dealing with coding challenges and working methods. Below are my observations on what Test-Driven Development is, its impact on real-life projects and how it might change the way we work. 

https://www.oreilly.com/library/view/test-driven-development/0321146530/

Test Driven Development (TDD) is a practice for creating clear, simple and defect/bug free code by writing tests first and then building code that makes the test pass. Tests are written one at a time in order to create the minimum required code but also to improve the reuse of code as thought is put into passing the test and just the one new test being introduced at a time.

In a typical TDD cycle a new test is added, all tests are run (with the new test either passing or failing), a change is made if tests fail, test is run in order to create success before finally refactoring to remove duplication. In this was a series of new tests can be created whilst constantly reusing existing functionality and staying focused on the issue at hand.

The process challenges the way development methods are normally implemented and thought about because of the subtle difference between writing tests for code and writing tests for requirements and writing code that causes the test to pass. It should be noted that TDD is not a replacement for performance, stress or usability testing. 

My first observation was that TDD is a slight move away from the Agile approaches I have seen on real-life Projects, in that many Agile projects have taken too literally the idea that documentation is secondary to building code, which isn’t helped by ‘Agile’ change process which means designs can quickly become obsolete. TDD is reliant on good documentation in order for tests to be written that achieve the goals and objectives of the project. The ‘How’ is agnostic but the ‘What’ isn’t.

An additional benefit in the TDD world is that the tests themselves describe the code better than standard documentation can, and it is factored into the test development. As code changes and test changes we find that the documentation the tests provides is also updated meaning it won’t go out of date.

Another observation when thinking about implementing TDD into real-life projects is that it really will work, especially with Agile as it allows projects to clearly define goals. This can be used to reduce scope creep and to ensure completion falls under the test definition. 

The book itself shows the low-level detail of splitting projects into small bite-size chunks using python and Java as examples. Specifically, it shows very small steps undertaken in order to demonstrate the method. This does help and (sorry to harp on...) works with Agile because tasks can be split into Sprint cycles but also because it makes the work specific and easier to understand, additionally whilst a large task as a whole might be difficult to implement, it may become easier when smaller parts of it have already been completed. Think of it like inserting libraries into a project where you create the small independent libraries yourself before merging them to make the end project.

From this perspective, nobody will ever go quite as slowly as the book shows the implementation, at least, not whilst also delivering at the pace that generates income or delivers targets - which is recognized in the book:

   “TDD is not about taking teeny-tiny steps, it's about being able to take teeny-tiny steps”

   “Am I recommending that you actually work this way? No. I'm recommending that you be able to work this way”

As with every method, the solution should always begin with best intentions. It will perform everything it is intended to, following good practices and standards. The difference is that as tests are being written before the work begins, both the tests and code are evolving at the same time whilst being refactored to remove duplication and obsolete code. In theory, we get quickly to the simplest solution, an increased reuse of code and tests that pass.

In real-life projects prolifically tend to overrun or removes scope or cost more money. Time, Scope and Cost. Unfortunately, as development becomes more rapid towards target deadlines so too does the elimination of anything not very importantwhich often means tests. Not all tests, but coverage gets overlooked as an ‘easy’ thing to disregard. If the happy path is working, we had better move on to the next important thing. 

The book asserts how there is a correlation between fatigue and judgement as well as between stress and testing in that increased stress reduces the number of tests. Anecdotally, when I have worked with development teams at high octanes over short periods of time - including evenings and weekends - I find it takes that extra conversation for things to be understood, or that extra bit of time to find and understand a bug.

The theory is that by applying TDD, tests won’t be disregarded as Time and Cost begin to cut into Scope. Instead, tests will catch the issues regardless of the stress, fatigue or reduced judgement project deadlines bring.

The additional value is that once the tests are written, they become the regression tests for all new feature inclusions which keeps the project on track despite potential side effects of changes in other parts of the environment. 

Throughout reading the book I found I was constantly thinking how TDD could be applied to my existing projects: Chatbot, FootballSimulation, API Development and more. The persistent thought was that actually testing a lot of real-life systems won’t be easy, especially past the unit test level where functional and integration tests come into place. 

Take for example a chatbot, how do I test a chatbots conversation has the relevant output from each input when a good chatbot will have lots of different outputs. How can I use TDD to get conversation direction whilst making the chatbot seamless?

In another example, how might I use TDD in a wider project such as during the deployment of an API Gateway? Do I test that I can make calls? that I can deploy policies? Is this even a valid scenario to use TDD? 

Part of the solution is in the use of mocking to mock parts of the flow. For chatbots there is an existing repository for ‘botkit’ https://github.com/gratifyguy/botkit-mockas an example of how mocks can be used in TDD. This does raise other issues in that creating good and effective mocking can be difficult, especially the more complicated the project and potential outputs become.

There are other concerns that can be raised such as knowing when to stop. In the past there have been test suites which have tested every hour of the day for a year. It took a long time to run as part of the suite, used up vital memory and added very little to the overall code of the project we were running. It’s important to know when to stop making testsby covering a wide range of scenario e.g. edge cases without testing every scenario.

My final thought is that TDD will require a lot of teamwork. Someone working alone to perform TDD will soon find themselves swimming upstream against a river flowing ever faster. The team would need to collectively agree the approach from the start with measures in place to ensure continued acceptance of the approach. There will also be a need for continued understanding of changes to the requirements as they are made and confirmed. 

An architect meeting leads to a change of requirements e.g. all traffic must be secured through mutual authentication. Tickets are raised, developers are informed, and tests updated to reflect the new requirement. 

In current projects, the tickets may become stuck in the backlog, it might be implemented only in some environments or the tests not updated due to time constraints. However, with test-driven development the tests are updated first, and all environments fail until changes are made to match.

There are obviously massive benefits to TDD in order to turn the approaches we make to projects on its head. Bringing tests to the forefront makes sense, gives a clear end goal to reach, gives a clear definition of done, becomes its own documentation and can be as specific or as loose as a project desires in terms of tracking implementation. 

I can see clear benefits in programming, API development and even in wider integration projects. I look forward to using it soon. I would love to hear where you have implemented TDD, the pros and cons and how I might avoid falling into common gotcha’s. 

You can email me here

Football Simulation Engine v2.1.0, v2.1.2 and v2.2.1

The football simulation engine node module has been available for just over a year now and has a couple of hundred downloads, and an interaction of a fair few people via GitHub. Part of that interaction has led to requests for changes to be made to the modules functions to either make the game easier to control or alter. 

Whilst making the changes other issues were thrown up such as the ball not continuing to move with the players when they were in possession, and in other cases the ball remaining in the players control after it had been kicked. The new versions - specifically version 2.2.1 - resolves these issues and provides a much better and more reliable output.

Refactoring 

The first big change was the removal of the async module. Two reasons for this were that a) it didn’t need it, b) I’ve grown a distaste for dependencies in my NodeJS programs. On top of this there were changes to allow for the latest node version to be used which included using let, const instead of var which good practice dictates and the general removal of promises which were also not necessary. 

General input from https://github.com/dashersw has been instrumental which has included improving error throwing as well as removing repetition. As such the code has been regularly reduced or made easier to understand with game examples now available.

Testing 

Part of my own journey has been to begin looking at Test Driven Development (TDD). Unfortunately, I could only apply it in this module retrospectively but will be adding test cases for all new functionality before I code it in future. 

For now, I have added testing for the three main exported functions and testing of validation of input. This is because it is where users are most likely to get stuck. My new goal is also to raise tests around whatever issues come through. One example is https://github.com/GallagherAiden/footballSimulationEngine/issues/33 where tests were added to validate the “ClosestPlayer” functions.

Adding tests has improved the game, because it has caught a number of interesting ‘perks’ of the code written where tests that should have passed actually failed. Which is good, as it shows TDD in action. 

Finally, part of the testing now includes End to End testing through Match Simulation of varying team ratings which shows expected results for teams of different skills.

New Functionality

After a review of the games being played there were a few obvious changes that could be made. Allowing more tackleswas one such whereby players rarely were able to take the ball off each other before, this has now changed and with it comes an improved risk of players committing fouls. 

The greatest new functionality was to stop the ball moving instantaneously, instead the ball moves over a period of iterations. This includes an x, y and z movement which factors in the height of the ball against the height of another player. This has allowed even greater play by introducing interception of the ball as it moves. 

Another big new function to the simulation was in the calculation of offside and the beginnings of some simple player marking. Other improvements have been possible with the ball movement change which includes; direction of player movementso players attack in the right direction, and better passing to stop players constantly passing to the keeper.

Finally, the way shots were taken, calculated and checked for so that own goals are awarded to the correct teams and shots occur over time. This has also led to an improvement of the ability for keepers to save shots as the ball enters their area.

Finally, a player fitness parameter has been added however this has no impact on the game currently and is merely additional information for people using the simulation engine as a manger game. This also includes an action parameter for each player which allows the move performed by each player determined by the simulator to be overridden.

Fixes

There have been a number of little fixes such as elimination of incorrect reporting of player possession of the ball. Changes have been made so that the closest player to ball or a position now gives a more accurate output.

Players now move with the ball at their feetwhich was quite a major bug in previous versions.

The changes made have had a massive impact on game play which you can see on the video I created for the latest version.

There are other changes coming in version 3 which looks to make the iteration json read better and make it more accessible. Other possibilities will be the removal of players from game play e.g. by red or yellow cards and the ability for team rating and other skills and fitness to have a greater impact on individual player performance.

I would love to receive feedback and requests for improvement which can be added here: https://github.com/GallagherAiden/footballSimulationEngine/issues

Alternatively you can email me here.

Happy footballing and thank you for downloading and using the module. 

A brief history of Banks, Payments and Technology

During a recent frenzy of reading on banking systems, payment types, technology and trade I began to note down what I was learning in the hope of sharing that information with others without the need to jump between lots of different sources. Hopefully it is of some use to someone.

Firsts in trade and banking

Around 10,000 years ago, early human beings began to swap hunter gatherer lifestyles for crop planting and animal husbandry. In the process, a specialisation took place whereby communities began to become very good at certain skill sets; wood cutters, fishers, farmers, miners, hunters and gatherers produced specific goods. Each good had its own demand, and so it became sensible to swap one set of goods for another [1].

Early trading would have been the swapping of the physical goods, whether necessity or luxury items. Historians believe one of the first long distance trades to have been conducted could have been as early as 3000BC with goods from Mesopotamia arriving in the Indus Valley in Pakistan and corresponding traded items being delivered in return [2].

With the extended usage of metal in daily lives, its value for trade in both its raw and final form led to its demand in trade encounters. The Greeks, for example, had no early raw metal access and so traded art, food and services with the Kingdom of Lydia for electrum (a natural alloy of silver and gold) coins. It was this supply of coinage that is believed to have led to widely adopted usage of coins across the ancient world and with this circulation came the need for people who were able to swap sets of coins and able to receive money for safe keeping from proprietors and traders and other banking like functions [3]. 

Bankers in ancient Greece and Rome lent money from temples and exchanged coins from different cities both within and from outside the empire. Investments could be made as capital for loans, which would incur interest at rates of over 6% which could be paid using exchange bills without the need for coins. In Ancient Egypt, the Ptolemaic king’s revenue was collected by an intricate banking system before being paid out as paper transactions [4].

Later, in the time of the independent Italian states bankers - known as Lombard’s within the Banking system of Venice - became the first notorious `bank`, which performed its role for the needs of its government. With each governmental war came a need for cash income whereby the populace was forced to pay into the loan system with cash stored in a chamber of loans. 

Whilst the Venetian chamber ceased with the independent state, the Bank of Amsterdam followed a similar set of practices before the Bank of England - chartered in 1694 - became the first of the modern banks, built also upon the principle of capital for loans of which bank notes were given [5].

Banking systems continued to be adopted until it had gained global usage as a means for storing capital, generating interest, producing loans or receiving capital from others such as wages or rent. Payment methods have traditionally been favoured in cash either through coins or bank notes, although cheque payments - a written order for a payment makers bank to transfer funds to a third party - has been used since the 17^th century with the earliest surviving Bank of England cheque written in 1659 [6].

The use of cards for payments has had a long history, in the UK, a financial credit company called Provident began to provide clothing and supply vouchers in 1880 as credit for working-class families who could make repayments on the loan over time [7]. This was followed in 1914 by metal cards known as ‘metal’ which allowed deferred payment for card holders [8] which continued to evolve over the next hundred years to provide wider card access to all markets in both credit and debit form. 

Modern Times

The goal in modern times is still about making trades of one good for another, with work services traded for money - now almost exclusively into a bank account - and then credit in the bank traded for other goods and services. The difference is that now the banking industry, consumers and merchants are pushing for faster, easier, more secure and more reliable payments.

In order to achieve this the banking industry has looked to build technological systems that facilitate growth, make it easier to spend and save money whilst improving payment security to prevent fraud whilst keeping customer engagement through the sentiment analysis.

In the 1920’s, accounting machines, punch cards and typewriters were utilised to improve processing time in repeatable processes whilst simultaneously reducing the cost of employment and accounting errors [9].

Task automation and further operation streamlining continued throughout the 1930’s, 1940’s and into the early 1950’s with cooperation between US and European technology companies during in the WW2 era allowing greater sharing of ideas and innovation with trips across the Atlantic galvanising large banks to adopt ever more sophisticated techniques such as standardisation of documentation across the industry [10].

Centralisation of ‘service factories’ to process even the most trivial of items like coupons gave the banks an infrastructure to cope with the rising middle classes who were most likely to use banking services. Problems emerged from the mid-30s as the weight of the work being performed meant the longevity of the machines were less than expected causing machines to need constant repairs or replacement.

In the UK, Barclays - the biggest UK bank of the time - were looking to demonstrate their ability to innovate with foresight. A new ‘computer centre’ was created in Drummond Street, London to demonstrate their computing prowess, significantly, the Emidec 1100 machine which was ordered for delivery in 1961 [11].

In the branches the Burroughs TC500 were also introduced as systems that allowed customer information to be fed into the main computer system from the branch. It took some time to complete the switch, but it is thought most banks has fully moved to the computer-based systems by early 1970s.

One inspiration for Barclays was a partnership between the Bank of America and the Stanford Research Institute which led to the creation of the Electronic Recording Machine - Accounting (EMRA) in 1955 where the level of involvement the bank had in the design of the computer made it facilitate business needs over scientific needs [12].

Further innovation continued for Barclays after British inventor John Shepherd-Barron proposed an automated teller machine (ATM) to the then Chief General Manager in 1965. The idea - stemming from the inventor arriving one minute after the bank shut - was for a cash dispensing machine that would work similarly to a chocolate dispenser. Barclays liked the concept and installed the first ATM at their Enfield branch in North London on 27^th June 1967 [13], [14].

At the same time that the ATM was being designed, Barclays also conceived of the Barclaycard in 1965 through Derek Wilde and James Dale who were managers at the firm. In the UK, the idea of the plastic card for issuing credit was a relatively novel even though the practice of the issuing of credit had been occurring for some time, with some local shops allowing purchases ‘on tick’ - meaning to be delayed until payday [15].

The ability to withdraw cash, anywhere and anytime continued to propel the public view that their cash should be available and spendable anywhere and anytime and with the credit card this was now possible, but the endeavour had no infrastructure, no user base and would take until 1972 before profit could be made. Over the Atlantic the Bank of Delaware issued the first debit card in 1966 for regional use, simply requiring a card and signature - the same as with the credit card. 

Whilst credit cards extend loans to the card holder to be repaid at some set later date, a debit card is the spending of money held by the account holder in their account. In the UK, it took until 1987 for the first debit card to be released, once again the front runners were Barclays through the Visa Delta Card [16].

There were still problems for UK payment makers despite frequent substantial change to the way banks were doing business. For example, each week or month, payments would be made to employees through envelopes of cash, and payment of bills such as rent, gas, electric and paper subscriptions were paid face to face and usually behind a queue of other payers.

To help solve this problem and alleviate the need to pay either face to face or specifically with physical money handed from one person to the next, the Bankers Automated Clearing Services (BACS) was introduced helping to reduce processing time of transaction from weeks and sometimes months.

When Dennis Gladwell’s idea was implemented in 1968, the introduction of Electronic Fund Transfer (EFT) between banks meant payments could be handled via computers, eliminating the need for repetitive writing of transfer notes between banks and thus making the movement of money simpler and quicker [17]. 

Whilst the changes being made were allowing more cash to flow in the rising middle class, and that savings had been made with greater efficiency, the 1970s emerged with just as many new challenges as there had been before. The first was the sheer number of customers now using different card types which were manually initiated and entered into the system - a process that was prone to error and slow to complete.

The solution would end up being a method for quickly relaying the information of a card holder using information stored on the card itself, which would be easily accessible without too much human intervention.

In the early 1960s, IBM Engineer Forrest Parry had seen the benefit of attaching magnetic media to a card such as in high security buildings like CIA offices to track personnel information through the magnetic stripe. Forrest would explain that his wife had suggested ironing the magnetic stripe to the card and with that a technology that would serve billions of dollars and billions of transactions entered the technology world. 

Initially the system was used by transit systems on the London Underground and California’s Bay Area Rapid Transit to match travellers with their tickets, but with further standardisation - helped in part by IBM who did not patent the technology - banks had begun to use the technology, heralding an era of greater technical prominence within the banking system [18].

From the retailer’s perspective, cash registers - in order to count and audit payments - had been in existence since 1879 when Ohio based James Ritty and his brother wanted to limit the ability of employees to steal money when handling saloon payments. Over time, the cash register adopted the LCD screen, magnetic stripe technology and wider computer integration throughout the 1970’s. 

By adapting and adopting each new technology, the cash register transformed into point-of-sale (POS) systems or at least POS compatible systems, which were primed for future use as a method for card holders’ payments to be pushed through to bank backend systems and back to the retailer for confirmation of payment [19].

Whilst retailers and banks had improved technologically, so too had telephonics. Home telephone lines had become more popular and obtainable by the early 1980s, simpler to setup, use and cheaper to have in the home. This brought with it a new way that people could conduct their affairs, more importantly, without leaving the home.

In the early 1980’s a partnership between the East Midlands bank The Nottingham Building Society, Bank of Scotland and British Telecom (BT) allowed home service users to connect a bank terminal to their home network or use their personal home computer through the telephone line and television, which enabled bank customers to transfer money, pay bills and arrange loans [20].

Gradual improvements both in quantity of people who owned home computers, the quality of network connectivity and the number of services that could be performed made online banking the convenient way to bank and thus its number of users progressed to a point where bank face to face stores are seeing a shake up in the way they operate and in some cases closing all together.

As access to cash became easier for customers, so too did it become easier for fraudsters who, by 2004, were costing banks £129.7 million in fraudulent activity. To tackle this the UK made a communal switch to chip & PIN on February 14, 2006 following a similar move in France in 1993 [21].

 Chip & PIN (Personal Identification Number) was not exactly new, with Scottish inventor James Goodfellow patenting the mechanism in 1966 it was already a necessary part of ATM transactions. The concept was simple, a chip was inserted into the card instead of a magnetic stripe and required a four-digit pin in order to access the cards services at the computer terminal.

The system was seen as an improvement on signature-based verification which was easy to forge, leading to a greater prevalence of card cloning and a surge in incidents of driving heavy vehicles through walls which hold ATM’s (ram raids) in the late 2010’s [22]. 

To make modern purchasing quicker and easier, a new method was introduced in 2007 through a partnership by Barclays and the Transport for London in order to offer contactless methods of payments for commuters and purchases across any participating retailers. The service would gain in popularity and by 2017 contactless payments accounted for 30% of all UK transactions [23].

By inserting Radio Frequency Identification capabilities into a card, card readers are able to get customer card data through radio signals, with the primary allowance being for purchases of £10 or under, with occasional verification required by the card holder completing a Chip & PIN transaction to keep security integrity [24].

At the same time as companies were pushing to get online, mobile phones technology was improving, with the adoption of internet connectivity into mobile devices in 1996. From here on out, card users could access internet banking services through their mobile, making transactions possible anywhere with internet connectivity.

Of the types of mobile phone payments, the simplest takes place through a regular browser which may or may not have been adapted for the mobile phone’s usage. Shoppers add items to an online ‘basket’ before making payments by entering their card details on an online web form. The webpage then makes a request of the banks system to initiate a transaction which the user confirms. 

Traditional banking and moving of money were to be challenged throughout this period, giving a real driver for existing financial services. In 1999, a company called PayPal was created that allowed individuals to send money to each other through their mobile phones. By using the mobile as a ‘wallet’, users didn’t need their physical wallet, money or cards on their person and could instead pay merchants and, more importantly, each other directly from their phone.

Increasingly more prevalent is the use of mobile applications to complete transactions for specific companies, where traditional cards details are held in the ‘wallet’. This is also true for the device as a whole, where a ‘wallet’ can hold the users bank details and the phone can be used to make payments using Bluetooth or WIFI technology against the card reading device held by the retailer.

Mobile Applications have also allowed banks to shift away from the terminal/home computer-based telephone line internet banking. Instead the method for accessing bank details, making payments and completing other bank services is now available through Bank provided mobile phone applications. The first of which was made available by the Royal Bank of Scotland in May 2011 [25]. 

Digital wallets continue to gain in popularity, with Apple Pay providing the service on Apple Products such as the iPhone and even the Apple Watch as recently as December 2014. The added benefit being that now mobile phones can use greater security feature such as two factor authentications where a secondary authentication method was required, such as face ID, touch ID or a form of passcode.

Whilst bank users, transactions and cash spending has continued to grow over the decades of technological advancements, there has also been an increase in the amount of scrutiny placed on existing banking systems. New online innovation has allowed financial services to emerge to help handle a user’s money effectively or without charges applied by regular banks. 

One example is the smartphone-based bank service Monzo. Whereas before, bank customer would be required to pay a fee to access their money abroad, using modern technology the company were able to offer the service for free.

The Future of Banking

Through government regulation the competitiveness of the major banks has continued to be questioned. In the EU, regulations meant that APIs needed to become available to allow third parties to perform banking functions for bank customers. This dramatic shift mandated in the UK from 2018 meant that customers would be able to access all their different bank accounts data from a single access point such as a mobile application [26].

Whilst this approach is looking to address competitiveness in the market, the financial crash of 2007 has continued to cause a reduction in the number of smaller independent banks available for customers to switch to, with over half of independent banks in the US disappearing over the last 50 years [27].

In this case, if the number of banks is decreasing and the volume of transactions increasing it is easy to see why bank competitiveness is being questioned and why regulations like the Payment Service Directive (PSD2) which envisions easy switching of account types, mortgages and saving funds from a third party is seen as a massive benefit to banking customers. 

What is becoming increasingly obvious is that banks and technology companies do not and perhaps have never been too different. The innovation technology can bring has a dramatic advantage on the banking system through ease of making payments or receiving payment for services or goods. 

The Crystal Ball

Whilst researching I had a couple of thoughts on how the way we handle and deal with money, banks and payments might changes. Below are a few of the thoughts I had, please feel free to comment with your own ideas for the future or harangue me for my own stupid ones...

In the next few years, it seems unlikely that anything but a face scan, voice identification or fingerprint will be required to do our shopping, even less so will there be a need to enter card details into your own device. 

Money management will soon move away from individuals with mortgages, savings accounts and investment all handled by an application which finds and switches to the best deals to get the best monetary return for the end user.

It's also possible that payments for rent, water, gas and electric could be further abtracted away so that the money never truly enters the account holders account, but instead is deposited directly to the end target.

----------------------------------------------------------------------------------------------------

References:

1. Lannoye, V. (2015). The History of Money for Understanding Economics. 2nd ed. CreateSpace Independent Publishing Platform.
2. Ahmed, M. (2014). Ancient Pakistan - an Archaeological History. 1st ed. Amazon.
3. Seaford, R. (2004). Money and the Early Greek Mind. 1st ed. Cambridge: Cambridge University Press.
4. Adkins, L. and Adkins, R. (1998). Handbook to Life in Ancient Rome. OUP USA.
5. Hildreth, R. (1840). Banks, Banking, and Paper Currencies. Whipple & Damrell.
6. Flinders, K. (2009). Cheque is 350 years old today, lingering death expected. [online] ComputerWeekly.com. Available at: https://www.computerweekly.com/news/2240088409/Cheque-is-350-years-old-today-lingering-death-expected [Accessed 20 Feb. 2019].
7. Provident Careers Site. (2018). About Provident - Provident Careers Site. [online] Available at: https://providentcareers.co.uk/about-provident/ [Accessed 20 Feb. 2019].
8. Parker, D. (2015). A Brief History of Payments. [PDF] Available at: https://www.polymathconsulting.com/Cache/Downloads/A-Brief-History-of-Payments-from-Polymath-Consulting.pdf [Accessed 20 Feb. 2019].
9. Archives & Histoire BNP Paribas. (2019). Chronology | Archives & Histoire BNP Paribas. [online] Available at: https://history.bnpparibas/chronology/ [Accessed 20 Feb. 2019].
10. Bonin, H. (2004). The development of accounting machines in French banks from the 1920s to the 1960s. Accounting, Business & Financial History, [online] 14(3). Available at: http://boninhub.free.fr/files/documents/machines%20%E9lectrocomptables%20I%20anglaisRABF100108.pdf [Accessed 20 Feb. 2019].
11. Emidec.org.uk. (n.d.). EMIDEC 1100 computer. [online] Available at: http://www.emidec.org.uk/emihme.htm [Accessed 20 Feb. 2019].
12. About Bank of America. (2019). Bank of America revolutionizes banking industry from Bank of America. [online] Available at: https://about.bankofamerica.com/en-us/our-story/bank-of-america-revolutionizes-industry.html [Accessed 20 Feb. 2019].
13. Telegraph (2017). The story behind the world's first cashpoint. [online] Available at: https://www.telegraph.co.uk/personal-banking/current-accounts/story-behind-worlds-first-cashpoint/ [Accessed 20 Feb. 2019].
14. BBC (2007). The man who invented the cash machine. [online] Available at: http://news.bbc.co.uk/1/hi/business/6230194.stm [Accessed 20 Feb. 2019].
15. RONSON, J. (2016). Barclaycard: 50 years of plastic money – the story from the Archives – Archives Hub Blog. [online] Blog.archiveshub.jisc.ac.uk. Available at: https://blog.archiveshub.jisc.ac.uk/2016/05/31/barclaycard-50-years-of-plastic-money-the-story-from-the-archives/ [Accessed 20 Feb. 2019].
16. WOJCIECHOWSKA, I. (2017). How debit cards stack up. [online] Fin. Available at: https://fin.plaid.com/articles/how-debit-cards-stack-up [Accessed 20 Feb. 2019].
17. G, A. (2016). Honey, who moved my money? A Brief History of Direct Debit. [online] Elementary. Available at: https://www.chargebee.com/elementary/what-is-direct-debit/ [Accessed 20 Feb. 2019].
18. Ibm.com. (2019). IBM100 - Magnetic Stripe Technology. [online] Available at: https://www.ibm.com/ibm/history/ibm100/us/en/icons/magnetic/ [Accessed 20 Feb. 2019].
19. Merchantproexpress.com. (2017). A Brief History of POS Systems. [online] Available at: https://www.merchantproexpress.com/news/a-brief-history-of-pos-systems [Accessed 20 Feb. 2019].
20. FEDER, B. (2019). BRITISH MOVE FAST IN HOME BANKING. NY Times. [online] Available at: https://www.nytimes.com/1984/01/02/business/british-move-fast-in-home-banking.html [Accessed 20 Feb. 2019].
21. 10 Years of Chip & PIN: 2006 to 2016. (2019). [PDF] www.theukcardsassociation.org.uk. Available at: http://www.theukcardsassociation.org.uk/wm_documents/10%20Years%20of%20Chip%20%20PIN%20report%20%282%29.pdf [Accessed 20 Feb. 2019].
22. Staffordshire Live (2019). Shocking figures reveal high number of ram raids devastating shopkeepers. [online] Available at: https://www.staffordshire-live.co.uk/news/local-news/shocking-figures-reveal-high-number-753815 [Accessed 20 Feb. 2019].
23. Card Expenditure Statistics. (2017). [PDF] www.theukcardsassociation.org.uk. Available at: http://www.theukcardsassociation.org.uk/wm_documents/Card%20Expenditure%20Report%20-%20April%202017.pdf [Accessed 20 Feb. 2019].
24. newsroom.barclays.com. (2007). Barclaycard OnePulse leads the way to a futuristic London with unique three-in-one credit card. [online] Available at: https://newsroom.barclays.com/r/1225/barclaycard_onepulse_leads_the_way_to_a_futuristic_london [Accessed 20 Feb. 2019].
25. Rbs.com. (2019). Banking app, 2011. [online] Available at: https://www.rbs.com/heritage/rbs-history-in-100-objects/history-in-100-themes/going-the-extra-mile/banking-app-2011.html [Accessed 20 Feb. 2019].
26. PwC. (2019). PSD2 – a game changing regulation. [online] Available at: https://www.pwc.co.uk/industries/banking-capital-markets/insights/psd2-a-game-changing-regulation.html [Accessed 20 Feb. 2019].
27. McCord, R., Simpson Prescott, E. and Sablik, T. (2015). Explaining the Decline in the Number of Banks since the Great Recession. [ebook] FEDERAL RESERVE BANK OF RICHMOND. Available at: https://www.richmondfed.org/~/media/richmondfedorg/publications/research/economic_brief/2015/pdf/eb_15-03.pdf [Accessed 20 Feb. 2019].

A Year In Books - 2018

At the end of 2017, I set myself a couple of ambitious goals for 2018. One of which was to read 20 books by the end of the year. As of the 26th December 2018 I had read 25 books - just over two per month. In this post I'll give my overall rating and a little description as to why.

Books in reading order left -> right

NOTE: War & Peace looks like a single book but I split the three volumes into different reading chunks.

1. David Mitchell - Bone Clock (2014) [8.8/10]

As the first book of the year, I was surprised by just how good it actually was. It had the feel of the mythical; about cults, magical powers, other beings etc. which is not always my cup of tea. But it was so well written, it really drew me in and I could hardly put it down.

It follows several stories which combine from almost mini stories as part of a wider plot - which although it might seem difficult to follow, was actually an incredibly easy read.


2. Andy Weir - The Martian (2011) [8.4/10]

Having watched the film of the same name, I couldn't help but hear Matt Damons voice and see his face - similar to many younger Harry Potter readers who can never unsee Hermione, Harry and Ron.

The book is extremely funny, believable from a scientific view - for this lamen at least - but was also pretty tense throughout. Once I started reading, I finished the book in just a couple of sittings over two nights.


3. Homer - The Odyssey (1200 - 800BC) [5/10]

I'd wanted to read Homer for a while and had previously read the Illiad. Both epics were written in similar styles, with the familiar "Aiden who was son of Patrick who was son of Harold who was son of..." littered throughout. The odyssey was a much easier read than the illiad but was still not easily digestible.

The epic follows Odysseus on his 10 year journey home from Troy where he falls upon all forms of mishaps and woe. It also follows his wife Penelope and son Telemachus who have to fight off suitors. The intention is for the epic to be orated, but I'm not sure I would have got away with muttering away to myself for several weeks.


4. Bernard Cornwell - Lords of the North (2006) [9/10]

Following the story of Uthred (son of Uthred) - this third in the series novel - was as compelling a read as the two before had been. It was easy to read, engaging and makes you feel like you were in ancient England in person.


5. Douglas Hulick - Among Thieves: A tale of the kin (2011) [7.7/10]

An organised crime spy in a fantasy world where magic is forbidden must piece together clues from a series of events to save the criminal world he inhabits. Whilst the first few paragraphs come across as very 'samey' for the genre it picked up pace and the story really started to pull you in - so much so that I order the next in the series as soon as I had finished reading.


6. Nick Srnicek and Alex Williams - Inventing the Future: Postcapitalism and a World Without Work (2015) [6.5/10]

The book began well by examining the history of the left, how it had failed and what the left needs to do in the future to bring around the general populace to left policies by emulating neoliberal strategies.

The next few chapters look at how shifting work availability, greater automation and a non-working class of people who cannot or will not be suitably employed is raising problems for the left, standards of life as well as - to a degree - business.

The four points raised are; fully automate, reduction of the working week, a universal income and the diminishment of the work ethic. As a 'left' leaning person the reduction of the working week seems reasonable and should be encouraged. However the premise of the book leans heavily on the automation aspect which suggests that automation means less work.

In my opinion this doesn't hold true. Historically the industrial revolution, introduction of irrigation, computing, machine processing and many other concepts should have eliminated work, but instead society and the world adapted, generating a need for different jobs. The book was generally good, but the urgency placed around the falling job numbers and the need for the four solution didn't quite ring true.


7. Douglas Hulick - Sworn In Steel: A Tale of the Kin (2014) [7.6/10]

Following from the original adventures of Drothe. Drothe must now use his new position to solve different intrigues. As in the first book the fight scenes seem realistic, the book is a nice easy read and the plot keeps you guessing. I would have purchased the next in the series but as of yet there is none.


8. John Stack - Ship of Rome (2009) [7.8/10]

As a Rome enthusiast this book gave a new perspective of the Romans which was exciting and enthralling. Focusing around the early Roman need for ships against the Carthaginians and their journey to becoming moderately good shipwrights made for a novel approach to typical roman adventures whilst keeping a similar style to what you might read by Simon Scarrow.

What helped put the book into perspective was that I was also listening to History of Rome podcasts by Mike Duncan and his fantastic description of the Punic Wars.


9. Margaret Atwood - The Handmaid’s Tale (1985) - [8/10]

Dystopian tales are my jam, and this one left the right amount of intrigue and historical background to what led to the 'new world' to really leave me satisfied. What I really enjoyed was seeing the transition into the new totalitarian state from the eyes of Offred.

Although the cliffhanger leaves a lot to be desired, I was beginning to struggle to see where else the story could really have gone to. It didn't exactly make me want to watch the tv series. That being said it did teach a very important piece of advice "Nolite te bastardes carbatorum".
 

10. Agatha Christie - Murder On The Orient Express (1934) [8.2/10]

Having watched the film first, the book was never going to surprise me in the same way. However, the ending is fantastic and the book is so magnificently written that it surpasses its age. It doesn't seem to be written in over 70 years before like you might find with a C.S Lewis or Enid Blyton novel. Fantastic read, great ending, brilliantly written.


11. Bernard Cornwell - Harlequin (2000) [8.3/10]

I originally read this book as a young boy, and it kick started my childhood joy for building bows and arrows from pieces of cane. The adventure is exciting, the historical context and placement - as with all Bernard Cornwell books - makes you feel like you are there in person. A great book, well written.


12. Ben Elton - The First Casualty (2005) [7/10]

Whilst the flow is a little off at times and can be a little difficult to get into at the beginning, the story really transports you as a reader into the horror and misery that was the trenches. The Inspector Kingsley is somewhat annoying which appears to be intentional, whilst vitriol toward the pointlessness of the war is much easier in hindsight the book is a good read with lots of intrigue.


13. David Moody - Hater (2009) [7.4/10]

Hater was a reread from my first year in uni, and it was good as I remember it to have been. The book focuses on a 'hatred' that appears in many people, often displayed through the eyes of the 'haters' themselves. As escalating violence erupts across the nation, panic ensues and Danny must protect his family from the haters. Genuinely good book which was a lot different to other horror stories I've read.


14. David Moody - Dog Blood (2010) [7.1/10]

Having just finished Hater, I had already pre-purchased the next in the series as I was enjoying the first so much. The second follows Danny as he navigates around a much different world. I don't want to give away spoilers to the first book. But this one only dipped slightly, the writing was as good as the first but obviously there was less intrigue in the second.


15. Ross Leckie - Hannibal (2008) [7.7/10]

Following the podcast for the History of Rome about the Hannibal era I saw this book and couldn't not buy it. It was a great read and dramatisation of the life of Hannibal that was not too dissimilar to the history in the podcast. It follows Hannibal's life right through to his death showing the pride, loyalty and commitment he had for Carthage but also the intense hatred he held for Rome and all Romans.


16. David Moody - Them Or Us (2011) [6.8/10]

By 'Them or Us" the pace and intrigue had really been impacted in the series so I couldn't quite enjoy the third book as much as I could "Hater" or "Dog Blood". Had it been written as a stand alone I'm sure it would have rated better - I really enjoyed the first in the 'Autumn' series for example which has a similar feel.

The story fantastically displayed how the human race at the end of its life might be torn apart by infighting, bullies and tyranny. The writing is fantastic and the scene setting is perfect. My downside would be the bleak outlook on the end of days but that's because I'm all about sunshine and butterflies.


17. Anna Sewell - Black Beauty (1986) [7.9/10]

The life of the horse 'Black Beauty' shows the different ways that horses live amongst humans. How they are loved, ignored, used for their beauty or as a symbol of wealth, mistreated through ignorance and malice and the relationships they might build with each other. Anna Sewell shows the greatest of empathy and understanding of horses and their lives, making this a beautiful read.


18. Ted Chiang - Arrival (2002) [6.8/10]

If you have watched the film Arrival, the book is a collection of short stories of which one happens to be the 'Arrival' from the film. Ted Chiang is an interesting writer with a world of imagination that he conjures on the pages. Unfortunately, this makes it hard to follow at times.


19. Bernward Cornwell - Vagabond (2002) [7.8/10]

The theme of the year has been that the second book to a series is never quite as good as the first. Maybe that's just me and the books I've read this year? Vagabond was a continuation of my boyhood dream to be an archer fighting for England, hunting deer and beating the French, great read.


20. Leo Tolstoy - War and Peace Vol. 1 (1869) [7.1/10]

I watched the TV series on the BBC before reading the book which made comprehension of what was going on much much easier, as I could put faces to names and scan over the names much easier. The book is somewhat hard to read, being written in the style of the time which for some reason begins with a long preamble around history, a city or the writers opinion on a subject before moving onto the story itself (This happens in Les Miserables too).

I really enjoyed the intrigue of the life of the gentry shown in the book and its very easy to become attached to the characters and want them to succeed, hate their enemies and feel like you are resting in a Russian townhouse or joining in a great hunt.


21. Leo Tolstoy - War and Peace Vol. 2 (1869) [6.5/10]

The second book slows considerably and I'm not entirely sure why I struggled so much more with the centre piece. The war progresses throughout volume two and the circumstances the characters find themselves in seems much of their own making which is frustrating - a sure sign that the author has done a good job at evoking feelings in the reader.


22. Leo Tolstoy - War and Peace Vol. 3 (1869) [7.2/10]

Tolstoy describes in this part how the ebbs and flow of war were not directly contrived by important figures of the day. There is an obvious adoration for Kutuzov who he obviously sees as a wise, sickly man who was able to see the bigger picture in everything he does against the brash arrogance of Napoleon.

Having never been a fan of the slow, almost idiotic fighting of the era (standing in squares with slow reloading guns) this is the first time the Napoleonic Wars have ever interested me. Tolstoy is a magnificent story teller who obviously studies and gave great consideration to the invasion of Russia.


23. Stephen King - The Green Mile (1998) [7.8/10]

As with all books by Stephen King the story was mysterious and believable in equal measure. It was well written with intrigue throughout.


24. Tom Beaumont James - Winchester (1998) [6.2/10]

This book describes Winchester through time in cold hard facts. It describes architecture, burials, population - size and origin - throughout Winchesters existence in a factual and informative way.
It might have benefited from a couple of folk stories from the area, such as perceived notions of King Alfred time in the city - even if described as unfounded with no evidence. The reality is somewhat disheartening and loses Winchester some of its magic.


25. Iain Gale - Four Days In June (2006) [8.9/10]

This novel was one of the best I have read all year. I couldn't recommend it highly enough. It describes the rolling, unimaginably complex formation and distribution of Napoleonic armies perfectly to present the difficulties and intricacies the wars of the times held.

The story telling was brilliant and well described. There was obvious bias towards Wellington over Napoleon which tried to show the fall from grace the French commanders and leaders had felt. Obviously well researched, it was a fantastic entry point into the world of Napoleon and Wellington.