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

In the News

7 Posts authored by: dayo

 Workplace distractions are an indigestible all-you-can-eat buffet. It starts with the sugary snacks, like Twitter, Instagram, Amazon or eBay. They’re garnished with carb-heavy coffee runs, lunch options, and office gossip, along with some protein: side-projects, meetings and Slack. You still think you’re fine until finally, cruelly, the server piles on a great fatberg of emails that block you up and slow you down.

 

When you’re tasked with building a brand-new, cutting-edge payments platform like Access Worldpay, it’s hardly ideal. So it’s no wonder that the leadership team chose to remove as many distractions as possible from the people tasked with delivering it all.

 

Less gets more

Perhaps counterintuitively, they decided the best way to increase teams’ productivity was to reduce their time together. For context, Access Worldpay uses the Agile approach to software development. This maximises speed and flexibility via small teams working in 10 day ‘sprints’, during which they plan, build and release software.

 

Careful examination of these sprints revealed that their productivity was frequently diluted. “Oftentimes you’ve got lots of other things cutting in and distracting teams so typically people can only contribute 85-90% of their time to sprints,” says Sean Simmie, Co-Lead (Build Chapter).  

 

Demarcation brings protection

The solution was to “segregate those distractions as much as possible” by reducing the sprint length from 10 to 8.5 days. Reserving sprint time solely for sprint work “protects” the teams so that they can focus properly on the task at hand. It also allows the remaining 1.5 days to be reserved for issues that are equally important but not sprint-specific.

 

Most of this time – a full day – is invested in ‘chapter time’. But what are chapters? “With Agile delivery, you take all the people you need to produce the outcome you want and put them in a team,” Sean explains. “If you need more than one team, generally you’ll want them all to be aligned so you don’t duplicate effort. That’s where chapters come in.”

 

‘People over process’

Access Worldpay has several chapters, all working to standardise best practice, share experience and expertise, and establish common principles and practices. “The chapter day is about the cross-cutting concerns and different chapters have different areas to align on,” says Sean. “For example, the build chapter has done a huge amount to standardise our approach to software engineering.”

 

Moreover, Agile delivery emphasises ‘people over process’, so “empowering people to contribute and make decisions is important,” says Sean. Investing in a specific, demarcated chapter day makes it “a distinct, protected thing that gives our people the opportunity to contribute rather than the leadership team simply micro-managing things.” He continues: “If we don’t give people real time and space to do this, it doesn’t happen – we’ve seen that time and time again.”

 

 

Now it gets personal

The final half day is reserved for personal development. “Again, it’s people over process,” says Sean: “We take our commitment to our people seriously because they’re our success, our biggest strength.” Behind this commitment lies a clear business case, he explains: “We need full-stack developers that can handle infrastructure, the front end and everything in-between, so we’re looking for people to grow in breadth and depth, to constantly improve on the engineering side.”

 

Individuals discuss their career aspirations and personal development plans with their manager. These can involve improving soft skills, such as presentations, or learning new disciplines. “One engineer uses his half-day to address and work on UX-related topics,” Sean says: “He set up a mentoring programme in which he would discuss, collaborate and review his work with a member of the UX team.”

 

Libraries and lunches

Investment in personal development also extends to extra time for conferences or essential training, such as Scala or Cassandra. It also happens less formally on the desk with line managers providing specific support and continuing performance management, and at regular ‘lunch and learn’ sessions. “It’s a chance for people to come together as a community,” says Sean. “Three of our engineers are the lunch and learn co-ordinators so instead of being management-led, it’s a grassroots effort, which is valuable.”

 

Beyond these lies a universe of courses and libraries online, including Linux Academy and Pluralsight. “We try to offer as much as possible and some people use their time to do certifications themselves,” says Sean. “The key thing is that it has to be something that the individual wants to maximise – if they feel they’re already getting enough from on-the-job experience, that’s fine as well.”

 

‘Production takes priority’

Although these 1.5 days are protected, they aren’t sacred. “Production takes priority over everything,” says Sean. “We have a duty of care and responsibility to our customers so we can’t have folks taking time out to read from Safari Library if our systems are crashing in production.”

 

“The thing is, they wouldn’t do that,” adds Ben Haswell, Engineering Lead: “Our teams have ownership and they know it.” It’s a natural consequence of Access Worldpay’s culture of empowerment and, ultimately, it’s the dividend yielded from a sustained investment of time, training and trust.

Faced with a pile of LEGO, any child knows that building something from scratch involves lots of decisions – about who can help, what to build, and whether it can be adapted later on. Those decisions can transform a simple LEGO plane into a sea-plane, jet-plane, biplane or triplane. Enough good decisions could even, one day, create the prototype Megafast UltraCool StarSurfer 2000.

                                                                                        

That’s a complicated vehicle, obviously, but it’s nowhere near as knotty as Access Worldpay, which has required decisions of a quantity, complexity, and consequence to make LEGO heads spin. Still, the brief was clear – to build a set of payment services and interfaces that could deliver Worldpay products quicker, more safely, more simply and with better service quality than anyone else. It also had to be easily scalable globally, both in capacity and cost. All told, “a reasonably non-trivial request”, says Simon Welland, Co-Lead of Access Worldpay.

 

Stating the obvious

Simon and his colleagues began with some “obvious” decisions, starting with the judgment that Access Worldpay had to be “cloud-first”, because the alternatives “simply couldn’t deliver the scalability and speed we needed.”

 

They also chose to go open-source. Besides using standard tools, such as GitHub and Nexus, they opted for proven open-source software, “because typically it offers the best engineering and innovation, and also the best quality and good value for money,” says Simon. To help ensure a viable supply chain, Access Worldpay decided to invest in key open-source providers and to share any future developments or improvements made by their engineers to open-source projects. 

 

Autonomy and automation

The imperative for high speed, responsiveness, and service-quality triggered important decisions. “We felt that only very high levels of automation and rigour in our approach would enable us to meet the required pace of change and level of quality of service,” Simon explains: “So we really pushed for investment in automation, in testing and in the use of software agents to have zero defect pipelines.”

 

Another choice involved fully harnessing “the power of the squad”, says Pat Bateman, Co-Lead (Build Chapter): “The squads are full of incredibly capable people who are at the coal face, living the problems on a daily basis, so we push as much autonomy in their direction as we can.” Reinforcing this, the team’s BRO model (Build, Release, Operate) gives squads responsibility for building and releasing software and then maintaining it too, thereby improving service quality.

 Oludayo Fafiolu, Patrick Bateman, Paul Wright and Simon Welland

First, principles

Since autonomy is about decision-making, success requires clarity – specifically, clear guidelines, principles, and leadership. One founding principle was to leverage individual knowledge and experience through extensive collaboration – for example, helping Worldpay colleagues understand wider applications that may sprout from the team’s decisions, and also discussing experiences informally with developers working for their customers.

 

Another guiding principle is test-driven development (TDD). “We test everything,” says Simon: “If it’s not tested, it’s broken.” Although TDD is commonplace for software developers, it represents a new frontier in cloud and infrastructure engineering. Consequently, the team’s cloud engineers have had to “rewire their brains to think about things a little differently,” says Paul Wright, Head of Cloud Engineering. “As head, my job has been to ensure people feel comfortable in this journey, understand the challenges and are clear that this is the agreed direction.”

 

Just-enough, just-in-time

Setting clear guidelines and principles – however challenging – has empowered squads to make the decisions necessary to fulfill the task at hand. “We ask the squads just to try and meet the requirements they’ve been asked to meet and avoid a whole bucket list of hypothetical things that could happen in the future,” Pat says. This helps create a “just-enough, just-in-time, every time” architecture that enables squads to start producing results very quickly.

 

Effective autonomy also requires clear limits and, therefore, leadership. “You need a strong feedback loop,” Pat says, because some decisions matter more than others. “If they come up with any significant decisions they can bubble them up to the leadership team,” he continues: “If it’s a really important decision we’ll try to make it for the entire team because it can help an awful lot of the other squads who’ll also hit these problems at some point.”

 

Four-wheel decisions

The leadership team consists of Simon and three others, including Paul and Pat. “It means you’ll have a difference of opinion, which is good,” says Pat. “With a group of three plus Simon, who’s the constant check and decision-maker, you end up making a lot more sensible decisions based on everyone’s collective knowledge and experience and opinion. It feels like a very safe environment as a result.”

 

Simon adds: “We bring over 100 years of systems leadership experience into the group and we do use that in our decision support.” It also helps them develop the knowledge and skills necessary for squads to use their autonomy to best effect. “We’ve worked hard on supporting our people to grow to the full-stack – which, today, extends from front-end to back-end to infrastructure,” says Simon: “We’re developing those skills in individuals so that, ultimately, we can take our architecture decisions anywhere within our team.” Paul agrees: “That’s what we decided from the start – to build strong, cross-functional teams that know what they’re operating and owning.” Just imagine what they’d make with some LEGO.

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.