Skip navigation
All Places > In the News > Blog > Author: dayo

In the News

5 Posts authored by: dayo
dayo

Growing in breadth and depth

Posted by dayo Aug 14, 2019

If you want real speed, it pays to be smooth. Put another way, to give your customers the truly responsive and reliable service they expect, not only must your core principles and working practices work in harmony, but also your key assets – your people. Are they working together as smoothly as possible? Do they have the skills they need to do this? And if not, how do you get there? 

 

At Access Worldpay, this work means encouraging its people to grow in breadth and depth. What does this mean? Breadth-first: “It’s about how we can get our developers and cloud engineers to work together to become full-stack developers,” says Andrew Davison, a Principal Cloud Ops Engineer at Access Worldpay.

 

Pairing is sharing

To this end, every project squad within Access Worldpay practices pairing, where software developers and cloud engineers work together. “Pairing really helps for getting the knowledge-sharing going,” Andrew continues: “It’s always good to get a different perspective when you’re working on something.”

Expanding the breadth of individuals and teams is then complemented by increasing the depth of each person’s technical skills. “Traditionally, a developer might gain some rudimentary knowledge about the cloud but fundamentally they might focus and specialize entirely on the software side of things,” says Shravan Jadhav, a Senior Software Engineer. Within Access Worldpay, however, the objective is not only crossing disciplines “but fully understanding those new disciplines and developing your skills.”

 

Making the investment

Enabling people to deepen their knowledge of new disciplines requires investment, which is why a key principle of the Access Worldpay team is to reserve 1.5 days from every 10 day period to improve skills and thereby boost individual and group productivity.

 

For a development group, part of this time is spent re-examining fundamental working principles and practices. The rest is used in ‘personal days’, where individuals can talk to their managers about their training requirements and go on suitable training programmes.

 

Shravan has seen that developers are keen to improve their infrastructure skills. “They might have touched on it a little bit in the past,” he says, but have not developed a depth of understanding that is genuinely useful. “From my point of view, it’s always been ‘I can write this code but then how do I actually use it?’ because obviously, I can’t just run it on my laptop. Being able to deploy that code properly and have a full view of the end-to-end flow, that’s the bit I’ve always missed.”

 

Testing in the cloud

For cloud engineers, meanwhile, the primary focus is learning how to bring test-driven development (TDD) into the cloud. “There’s been a big, strong push to adopt TDD in the cloud and it isn’t always easy to understand how to write or implement a test in the infrastructure world that works well,” says Andrew. “A lot of cloud engineers are looking to learn how to write tests – lots of us did an infrastructure testing hackathon recently to try and get hands-on with writing infrastructure tests.”

 

The fundamental purpose of growing in breadth and depth is about helping developers and cloud engineers to work “across principles,” Andrew says. “So we have cloud engineers tackling dev approaches like TDD, but we also have developers working on cloud infrastructure, learning about how we do things and working with us to get the product delivered.”

 

Shravan agrees, saying that developers’ familiarity with TDD has proved useful when learning about infrastructure. “When you’re making changes in the cloud, using tests allows us to see if our changes are working even if, at first, you don’t fully understand the tools that cloud engineers use.” The process of testing and checking gradually allows developers to increase their understanding: “it’s a much safer way of upskilling, and a safer way for developers to be able to contribute to infrastructure right off the bat.”

 

Breadth, depth and beyond…

Although the push to increase breadth and depth has certainly helped drive improvements within this particular area, its rationale does not end there. “We’ve focused a lot on testing because TDD is just fundamental, but obviously this isn’t just restricted to that,” says Shravan.

 

Instead, he believes this shared approach can help with all the new concepts and technology that Access Worldpay wants to use. “Everything we do consider tends to be more holistic, so one of the ways we’re trying to grow in both directions is by bringing everyone onto the same page in the first place,” he says. “If you’re working on the same thing then it doesn’t matter whether you’re a cloud engineer or a developer – we can have just the one, single approach.”

 

To experience the breathless pace of software development today, just think about the constant cycle of app updates on your phone. It’s no different for Access Worldpay, but with greater stakes – instead of providing extra levels for Candy Crush, its releases improve and protect financial platforms trusted by some of the world’s largest organizations to secure the personal data of millions of customers. So where does continuous integration fit in?

 

For a payments organization like Access Worldpay, the ability to respond quickly and reliably to customer demands is less a competitive advantage than a business necessity – it is simply today’s operating environment. It is also the impetus that drove the team’s adoption of the Agile approach to development, which it refines wherever possible to improve efficiency still further.

 

Team: dynamic

Ben Haswell, Engineering lead, explains that the same considerations lie behind continuous integration. This enables a large team working on a single project to work as quickly as possible by minimizing code clashes and the delays they cause each new release. 

 

Each developer works on a small, specific task and then commits the changed code to a shared repository which holds the code for the whole project. Given that each team has five or six developers, each making changes on a potentially hourly basis, the repository can easily receive dozens of changes every day.

 

“Having lots of people working off the same repository means that everyone’s getting the latest changes at the same time,” says Ben. The alternative, he explains, is to commit multiple changes later on, “but the longer you leave your commits, the greater your chances of getting code clashes.”

 

Ben Haswell and Oludayo Fafiolu

 

Clearing hurdles

Once a developer has committed a specific change to the shared repository, it goes through the build pipeline – a process with lots of hurdles, or ‘stage gates’, which run the change through a suite of tests to verify that the change has not damaged any other code in the repository. “Nothing can get through if it breaks any of the gates,” says Ben, so passing the tests “proves that the change works – you don’t have to do a whole load of heavyweight testing.” This gives developers an underlying degree of confidence in their work: “you don’t have to worry that the application might not start at all, or that odd behaviours are down to a fundamental breakage.”

 

Keeping the build working – or ‘green’ – is key to enabling frequent releases, so should a change committed to the repository fail any of the tests, the team is alerted immediately. “Any fail is a ‘stop the line’ event and you’ll get the team swarming to get the build back to green,” says Ben.

 

As a result, problems are quickly identified, “and the earlier you spot a problem, the easier it is to fix,” he continues. “If you batch several changes together, all at once, chances are you’ll get a lot of code conflicts” which take far longer to identify and resolve. Continuous integration, therefore, is like untying a series of individual knots in a long strand of wool before it becomes a tangled mess.

 

Trunk-based development

The need to resolve problems quickly is particularly important because the team practices trunk-based development. Instead of developing code on different branches, every developer commits each change to the master code. “It means the master is always updated with what everybody’s doing, so it’s always releasable,” says Ben. “You don’t have people working in isolation, where a change may work on their own branch but cause problems when merged into the master code. This way, you’re getting feedback as soon as possible.”

 

Combining continuous integration and trunk-based development enables robust, reliable code to be produced by a sizeable team very quickly. Given that the team releases a new version of its master code approximately every two weeks, this is essential. “If you want to be able to react quickly and release quickly, you want continuous integration. It means that whatever’s on your master is valid and up to date and can be released as soon as possible.”

 

Responsive and responsible

This swift release of updated and improved master code is essential for Access Worldpay to continue serving its customers effectively and, therefore, competing successfully in its business environment.

 

“When a customer wants changes made, continuous integration is absolutely fundamental to how we respond,” says Ben. “Only with continuous integration can you make those changes, validate them quickly and get them to the customer promptly.” Put most simply, continuous integration enables Access Worldpay to be both responsive and responsible and thereby deliver rapid, safe change.

dayo

What does TDD mean to us?

Posted by dayo Jul 25, 2019

Global companies rarely get to write software from scratch, reappraising existing code, methods and assumptions before deciding whether or not to apply them. Access Worldpay provided such an opportunity and the team seized the chance to refresh their approach by embedding test-driven development into their work. Two years on, we asked two engineers for their views.

 

Most software engineers recognize test-driven development (TDD) as best-in-class methodology, and within smaller businesses, it has become standard practice. However, large organizations can struggle to embrace it, partly because of roadblocks caused by legacy software.

 

Changing Mindsets

Another issue is the “change in mindset” that TDD demands, says senior developer Ignas Traskevicius. Engineers need to concentrate not on the precise code needed to satisfy one specific task but, instead, focus on the larger goal the software aims to achieve. That sounds straightforward but, he says, it represents a “complete inversion” of traditional approaches to development that requires engineers to “write an automated test for code that is not yet there… to think up with the most convenient interfaces for this component, even in the abstract, and then use them within the test although such interfaces may also not yet exist.”

 

Such mental gymnastics are difficult but, continues Ignas, they deliver significant benefits. These include “better abstractions and leaner interfaces, with cohesive code brought together.” Moreover, TDD-led components are less coupled to others, so changes made in one component are less likely to affect others. This all results in software with robust architecture and maintainable code, which becomes more important as the software becomes increasingly complex over time.

 

The intellectual rigor involved is precisely why TDD has become fundamental to Access Worldpay’s approach – so much so that the maxim “If it’s not tested, it’s broken” is one of the team’s guiding principles. But exactly what impact has TDD had in practice?

 

the team at Worldpay

 

Code to the test

“The important difference TDD has over other forms of tested software is the ‘driven’,” says Alastair Donlon, principal developer. “You start from the ‘test’ first – it drives everything else.” Ignas adds: “You have to design the test in the abstract, without thinking about how it will affect implementation. Only once the test is complete can you start working on the production code to satisfy it.”

 

This process pushes engineers to start by breaking down the code to the point where they can control its dependencies. As a result, every individual piece of software is written with sound architecture and clear code which engineers can continue to support, even when combined into much larger packages.

 

By contrast, says Alastair, “a test-afterward method creates software with intertwined dependencies that make it harder to test the code in isolation. It becomes very difficult to move past that, to write a test for that code and to use it in other places.” Ignas goes further: “Applications that aren’t covered by TDD or some form of automated test are broken – if not immediately, then sooner or later.”

 

Tests breed success

Since it was introduced, TDD has worked well for the Access Worldpay team. “Wherever TDD is used, I see successful software,” says Alastair. “We’ve never seen any types of bugs or issues going into production and applications are more robust and easier to develop.”

 

Of course, any software development, whether or not TDD is involved, faces the possibility of under-testing. This is the chance that one or more test cases, if overly limited, may fail to address some functions and so leave them unproven.

 

Triangulation testing

The Access Worldpay team tackle this issue by using more tests to triangulate their code. A simple example is an addition. Engineers would start by writing a test to give a specific, expected and minimal solution (e.g. 2+2=4) and then hard-code the response to be that solution. They would then triangulate this code by designing another test for the same code. The second test would have slightly different inputs, expected to produce slightly different outputs (e.g. 3+3=6).

 

To make the code pass the second test, they make very simple changes that may, initially, be architecturally unsound. Once the test has been passed, however, the engineers can refactor the code to ripple throughout the software, and then test again. “This looks better from an architectural point of view and you still have the tests showing you that you haven’t broken the code,” says Alastair. Further triangulation testing can then identify other functions that remain unconfirmed.

 

First principles last

Ultimately, the team has found that using TDD encourages them to clarify their thinking and go back to first principles, says Ignas. “The test is the very first component – it gives us the chance to put software that hasn’t yet been written through its paces,” he says. “It allows us to think about the interface and to consider the most convenient and comfortable way to use each component. Indirectly, TDD drives the user experience.”

 

 

Further reading:

  1. General articles on the TDD cycle and rule
    1. The cycles of TDD
    2. Test-driven Development
  2. More specific information on triangulation
    1. Getting Stuck While Doing TDD. Part 3: Triangulation to the Rescue!
    2. The Two Main Techniques in Test-Driven development, part 2
  3.  An overview of some research on TDD practices
    1. The Evidence For TDD

It’s almost a parallel universe. Although part of a global organization with vast reach and huge responsibilities, Access Worldpay remains a small, autonomous unit with the freedom to choose its own working principles and methods. Not only can it adopt best practices, but it can also hack these as necessary to meet its needs. Co-lead Build Chapter, Pat Bateman explains how his team’s approach to QA demonstrates its independent, entrepreneurial spirit. 

 

The starting point, he says, are the objectives. Access Worldpay is expected to turn work around fast and to a consistently high standard. “Predictability is one of the big things here. We want to get stuff out of the door really quickly and if there’s no predictability, then the business has a difficult time working with a customer.”

 

Goodbye Waterfall

Such imperatives immediately made the team determined to streamline its working processes. Quality assurance (QA) was a prime candidate for reform. Standard practice separated the QA function from software development. “They were almost two different organizations,” says Pat. “Software developers would write the code; when it was finished, they’d give the application to the test department for validation.”

 

This approach made the interplay between QA and development slow and inflexible. The long feedback cycles in the Waterfall approach to software development also made it expensive. “You’d have these massive cycles to find out something was wrong and the expense of going back and fixing the issue was immense,” Pat says. “And often what you thought you were building, in terms of set requirements, had changed.”

 

Improving Agile

The shorter cycles within the Agile approach helped a little, but not enough, so the team explored further refinements. “Even in Agile, the QA function remained similar to the old methodology of ‘test after’,” says Pat. “What we’ve discovered is that you can make more change the earlier in the product’s life-cycle you go.”

 

This is ‘shift-left’: moving the quality assurance to the left – to the start of the cycle. It means that QAs can work alongside the product owner and the developer to help ensure that the requirement is correct and agree on the acceptance criteria. “This makes our whole life-cycle more efficient because you’ve done much more detection of fault or quality at the beginning of the requirement description,” says Pat. “So by the time the developer starts coding, they’re going to find fewer problems with the requirement.”

 

Expanding the role

The QA function also extends to exploratory testing. “QAs come up with extra hypotheses, also at the beginning, thinking about the other scenarios we haven’t documented,” says Pat. “They’ll ask ‘does it work in this situation?’ and they may find some edge cases we hadn’t thought about, so they’re coming up with some requirements we’d missed.”

 

And, name aside, shift-left does not confine QAs to the start of the cycle. They still perform their traditional role at the other end, confirming that the software engineers have met the requirement and fulfilled the acceptance criteria. In practice, therefore, QAs are now available throughout the cycle, helping software engineers as needed to ensure that they are interpreting requirements and acceptance criteria correctly. “The QA becomes a more important person in the delivery squad,” says Pat: “They’re constantly being used.”

 

Widening the search

Although shift-left has improved the team’s productivity, the shake-up it involves can make recruitment somewhat tricky. For example, software developers are now expected to automate all their tests, whereas beforehand they shared that responsibility. And Pat recognizes that traditional QAs find shift-left to be “a difficult transition.” He continues: “We are essentially asking them to change their job – to move much more to a product view of the world. It’s very difficult to find people who understand it thoroughly.”

 

To mitigate this challenge, new recruits receive “lots of support on the job,” he says. Access Worldpay bring in QAs with shift-left experience to help new colleagues at the initial, refinement stage – “they help them go through exemplar requirements and acceptance criteria, and we iterate this to keep helping them improve.” QAs and product owners also have a two-day workshop, where external experts go through the whole process and teach them how to find out whether what requirements are viable.

 

“A bigger impact”

Pat is convinced that this extra effort is very worthwhile, not least for QAs themselves. “Traditionally, the QA function has been at the wrong end of the process,” he says. “You can feel like you’re an afterthought, pushed into very tight timelines because earlier parts of the process have run over, so you’re just sat there, checking stuff and filing bugs without any feel of the process.” By contrast, he says, shift-left “places you at the front, with a bigger impact on the product definition; it makes you one of the most crucial people within the product you’re trying to deliver. For QAs right now, this is an exciting time.”

dayo

Access Worldpay people

Posted by dayo Jul 16, 2019

Access Worldpay is our new set of APIs that is fast, supports simple integrations with fault-tolerant, micro, and scalable services. Our developers have created a set of APIs that are readable by humans and machines, thanks to a simple JSON schema. And with Hypermedia, our APIs simplify complex payment journeys for our customers. Learn more about our APIs here.

 

Access Worldpay is a project run by developers, for developers. At the center are smart, spirited and supportive people.

 

What's behind the doors of Access Worldpay?

 

The project kicked off in 2016 from our London and Cambridge offices. The vision? Creating an easy-to-use platform, powered by our engineers.

 

In 2018, Worldpay and Vantiv became one organization, and the doors opened for collaborations of many different teams across the ocean. Our colleagues in the US had been working on microservices that offered an excellent opportunity when combined with our Access Worldpay product. This resulted in a unique and inclusive way of working together.

 

Our engineering squads are responsible for the design, build, release and operation of our APIs and services. This allows for full end-to-end control of the product but also gives people opportunities to grow as teams and individuals. Squads are autonomous and accountable for progress, which makes the project highly flexible.

 

Teams are working on an API set that is not only the industry standard but also uses a full REST maturity model. Our aim is to build a quality service, guaranteeing 100 percent uptime. Living by the principles such as: “If it’s not tested, it’s broken”, our approach to testing and “Requirements before solutions” means that our APIs and services are quality-assured throughout the development lifecycle.

 

What’s coming next?

 

We want you to meet and get to know the people behind Access Worldpay. In the coming weeks, we will be publishing a number of articles. This will include interviews relating to method, processes, and principles we use in and out of development. You can expect to read about topics such as Test-Driven Development (TDD)our approach to Shift-left in QAGrowing in Breath and Depth and many more, stay tuned.