I’ve always been taught to use the Testing Pyramid¹.

The basic idea is to write the most unit tests, as they are the smallest in scope and fastest to run. Then you write fewer integration tests, which are larger in scope and slower to run, before you finally write an even smaller number of end-to-end tests, which are the largest in scope and slowest to run.

I’ve always been taught to use Test Driven Development²³ (TDD).

The basic idea of this is that you should write your tests before you write any code. Your tests codify the required behaviours of the software you then write, giving you an easy way to know when the feature you’re working on is complete. This should also document the context of the code you’ve written, making future changes theoretically easier.

But I keep observing common issues with unit testing on the digital delivery teams I’ve worked with over the past several years.

Recognise either of these from projects you’ve worked on?

Problem 1: Lack of test confidence – Your application fails when you deploy it, despite all the unit tests you’ve written for the change you’re making and high test coverage.

Problem 2: Testing stalls change – You make a simple change to your code, but you then need to totally restructure lots of unit tests in order to do it.

Problem 3: High cognitive load – You want to understand the behaviour of a section of your codebase, but reading the unit tests provides little help.

I’ve observed these problems dozens of times and they’ve always frustrated me because they seem to directly oppose the entire point of testing!

I believe good testing provides several significant benefits in software delivery:

1. Good tests should give us confidence in the correctness of our changes
2. Good tests should allow us to make changes more quickly
3. Good tests should document how our system behaves

Introducing the Testing Trophy

The culprit is the Testing Pyramid. It’s outdated and obsolete.

I’d like to introduce you to the Testing Trophy⁴⁵⁶ as a replacement. This is also sometimes known as the Testing Vase or Testing Honeycomb, but it’s essentially the same thing.

Integration tests are now the widest layer

The goal of these tests is to codify business logic. This typically means each test maps to either an individual acceptance criterion or an obvious, easy-to-understand part of a user journey.

For example, if your user journey is “to allow users to log in and check their health records”, you might have an integration test to check they can log in, another to check that a logged-in user can access their health records, and a third to check that a person’s health record displays the correct information.

Integration tests shouldn’t really care about the internals of your code. In theory, if you re-wrote your codebase in a new language, you should still be able to run the existing integration tests with minimal change needed.

Integration testing also avoids some of the common problems attributed to end-to-end testing – extremely long, brittle tests which fail intermittently. By splitting these long journeys up, integration tests are more reliable.

To address the three problems described above (lack of test confidence, testing stalls, and high cognitive load), I recommend migrating the bulk of your unit tests to integration tests.

End-to-end tests stay very thin

The goal of end-to-end testing is to ensure your application works as expected in an environment that closely replicates the production environment. In other words, they’re infrastructure tests. Only a few of these tests are needed, and they should cover complete user journeys.

To keep your end-to-end testbench manageable, it needs to rely on the presence of your integration testbench. This means you can keep the number of expensive end-to-end tests to a minimum.

Unit testing is now also a very thin layer

There are two goals for unit testing now: exhaustive testing and complex-subsystem testing. Both of these rely on your integration testbench to assert that your codebase actually works in a general sense, and only test very specific functionality that would otherwise slip through the cracks.

Exhaustive testing is for when you want to test all possible values or combinations within a feature. You could integration test the “common” combinations to check that the code works overall, but you could then add a unit test that would loop through every possible single value or combination of values to ensure they all still work.

For example, imagine you’re building an online shop, and you have integration tests that verify that users can successfully purchase green paint. Exhaustive unit tests could build on this to ensure the paint is also available in the 100s of other colours your shop offers.

Complex-subsystem testing is for when you have an isolated nugget of complexity in your codebase that you want to test in isolation. Because it has many edge cases and is complex, highly focused unit testing is important to ensure it works correctly. In essence, this pattern uses the same philosophy as integration testing our services as opaque boxes – just zoomed in to treat a specific class, module, or function as an opaque box instead.

For example, I once wrote a set of complex-subsystem unit tests for a smart rate limiter I was working on. You could integration test that the rate limiter works for several examples in the wider context of the application it lived within, but then add unit tests on top of this for every edge case you can think of for just the rate limiting logic.

Linting/Static analysis is the new base layer of the model

The goal of this layer is simply to speed up our ability to write quality code and tests. By using automated tools, we can catch more careless errors without having to test for them specifically.

And that’s the Testing Trophy!

What does this look like in practice though?

But what about the real world? It’s all well and good to evangelise a theoretical testing model, but how would you go about applying this to a real project you’re working on?

Below are some examples of common queries, and how I’d approach addressing them.

“I’m on a project with an OO codebase and lots of unit tests for each class. How can I introduce integration testing?”

• You can probably use your existing test runner (jest, junit, pytest, etc.) and extend it with tools like Localstack, Wiremock, or Test Containers.
• You can then write integration tests which read like chunks of a user journey or individual acceptance criteria. Something like “I want to allow users with an existing account to log in” or “I want to reject users who log in with the wrong password”. This is often referred to as Behavior Driven Development (BDD).
• You can convince your team with working code examples to back up what you’re saying. Hopefully, it shouldn’t take them long to see that writing a handful of integration tests with very few mocks saves them considerable time and effort!

“I’m working on a frontend using a modern JS framework. What does the testing trophy even look like for this codebase?”

• Render the entire app (and spin up any backend services) and use tools like Cypress or Playwright to end-to-end test full user journeys (e.g., logging in, adding a product to the basket, checking out, and requesting a refund).
• Render each page and click through multiple components to integration test. These tests should naturally make sense as parts of a user journey (i.e, a login flow).
• Render each significant visual component and verify that it renders correctly on screen during unit testing (exhaustive unit testing). You can also use tools such as Storybook or Chromatic to help with this.
• Render each complex (think lots of gnarly state logic, etc.) component and run through edge cases (complex subsystem unit testing).

“Our team has an end-to-end testbench which has all of our user stories in but is flakey, expensive to run, and breaks all the time. How do we fix this?”

• Is your entire end-to-end test stack running in a production-like environment? If not, fix this first! Even if it means you’re no longer able to run these tests locally, that’s an acceptable tradeoff.
• Are your tests actually written as full user journeys? Or do they try to do much more, testing edge cases or individual chunks of a user journey? If the test isn’t a full user journey through your system (e.g, I want to buy new shoes → my new shoes are on my feet), it probably belongs as an integration test.

“What’s the problem with just having lots of integration and lots of unit tests?”

• It’s fine to have partially overlapping tests! This is often a good pattern: an exhaustive unit test (the login button renders), an integration test (I can log in), and a larger e2e test (I can log in, buy something, and pay for it).
• If your integration tests are easy to run, can be run locally and debugged, having equivalent unit tests that try to do exactly the same thing is unnecessary, increases cognitive load, and runs the risk of rotting over time.

“My manager/boss says that we should aim for X% code coverage”

• Code coverage has diminishing returns (beyond 70%)⁷. It’s often good at revealing which chunks of a codebase haven’t been tested, but it’s bad at revealing which lines of code you should/shouldn’t be hitting.
• If their focus is on overall system performance, you could consider trialling DORA metrics⁸ within your team or organisation instead.
• They might start to trust you more when your new testbench starts automatically catching issues that the existing unit tests miss. I added a simple end-to-end testbench to a service our team owned, which had previously been very heavily unit-tested. It caught 5 bugs in the first month that would’ve otherwise gone to production without being spotted by the existing testbench.

“Our team has dedicated testers/SDETs, I don’t want to upset them by changing how we test”

• Most organisations employ testers to be test experts, not human computers. Most organisations and testers welcome automation and the increased confidence it brings through better testing.
• Bring them into the conversation early if you can. They’re likely to be highly in favour of new testbenches and better automation! After all, these tools make their jobs easier, freeing them up to focus on more important work like paying down test technical debt or activities like user acceptance testing (putting new stuff in front of actual users).

Annex – The types of tests

I want to take the time to define exactly what I mean when referring to all the different types of tests. In my experience, everyone has a subtly different definition of them – so for the sake of my sanity and your understanding, here are the definitions I’m using⁹¹⁰:

End-To-End (E2E) testing

Sometimes referred to as Functional, Integrated, System, or Smoke testing.

End-to-end tests are typically scoped to Level 1 (Software System) of the C4 model. Of all the tests, end-to-end tests are as realistic as you’re able to get and often need to be run in a production-like environment. These tests typically read like fully complete user-journeys.

External software systems are mocked as needed and pragmatic infrastructure changes are made (for example, running with fewer replicas than the production instance to save on server costs).

End-to-end tests are meant to be wide-reaching and realistic, at the expense of speed and ease of being run.

Integration testing

Sometimes referred to  as Functional, Component or Service testing.

Integration tests are typically scoped to Level 2 (Containers) of the C4 model. Integration tests are the middle child between end-to-end and unit tests, carefully balancing scope, speed, ease of running, and realism. These tests typically read like chunks of a user-journey, or specific acceptance criteria.

Other major components of your software system are mocked out, and tightly-coupled parts aren’t. For example, integration tests for a login API might mock everything except the API, a database storing login credentials, and a queue which login requests are read from. Infrastructure is also often mocked, with tools such as docker, localstack, or lightweight kubernetes clusters being popular choices to only stand up a small handful of tightly-coupled services.

Integration tests are a balance between being closer to reality, treating your software as an opaque box unlike unit testing; and fast and simple to write/run, unlike slower and more brittle end-to-end tests.

Unit testing

Unit tests don’t really go by any other names, but there are a million competing definitions of what constitutes a “unit” of software!

Unit tests are typically scoped to either Level 3 (Components) or Level 4 (Code) of the C4 model. Due to the limited scope of these tests, other classes/modules/functions/objects within the same codebase are mocked as needed.

Unit tests are meant to be quick to write and run, at the expense of scope and realism.

Static analysis

Sometimes also known as linting. Static analysis covers a vast array of tools and automations and can often be found in places like pre-commit hooks, continuous integration pipelines, and even your code editor. This bundles together linters, formatters, type checkers,

Static analysis tools are typically scoped to Level 4 (Code) of the C4 model. They aren’t really “tests” in the traditional sense, but enforce things like code styling and good practices.

Ideally, they should be run as close to code being written as possible for the shortest feedback loop possible.

1. Mark Cohn – Succeeding with Agile: Software Development Using Scrum, 2009 ↩︎
2. https://martinfowler.com/bliki/TestDrivenDevelopment.html ↩︎
3. https://www.madetech.com/blog/messy-software-projects/ ↩︎
4. https://www.wiremock.io/post/rethinking-the-testing-pyramid ↩︎
5. https://kentcdodds.com/blog/the-testing-trophy-and-testing-classifications ↩︎
6. https://kentcdodds.com/blog/write-tests ↩︎
7. https://kentcdodds.com/blog/write-tests#not-too-many ↩︎
8. https://www.thoughtworks.com/en-gb/insights/articles/improving-your-bottom-line-with-four-key-metrics ↩︎
9. https://martinfowler.com/bliki/UnitTest.html#SolitaryOrSociable ↩︎
10. https://martinfowler.com/articles/practical-test-pyramid.html ↩︎

The post A pyramid scheme! Have we been unit testing wrong? appeared first on Made Tech.

However, it wasn’t until the draft guidance was published and we drilled down into the details of the proposed processes and obligations that we realised how significant a change this could be for our customers and how ill-equipped many existing solutions are for the type of deadline-oriented case management the guidance points towards.

Awaab’s Law – the fundamentals

To recap: Awaab’s Law requires social landlords to investigate and respond to hazards in set timeframes.

It defines different categories of hazards and the timeframes in which landlords must respond:

• Emergency Hazards – hazards that present an imminent and significant risk of harm to the health or safety of tenants. These must be investigated and, if required, made safe within 24 hours. As the guidance highlights, this aligns with how day-to-day repairs teams currently manage emergency repairs.
• Significant Hazards – hazards that present a serious risk of harm to tenant health or safety, where a reasonable landlord with the relevant knowledge (including the tenant’s individual circumstances) would take urgent steps to make safe. These must be investigated within 10 days.

The underlying admin burden

As my colleague Chris discussed with Dave Loudon in our recent webinar, there is considerable administrative complexity that landlords will need to manage to remain compliant:

• Reports coming in via multiple channels that need to be logged and acted on consistently.
  
• Investigations to schedule, with planning teams juggling deadlines and ensuring nothing slips through the cracks.
  
• Operative investigations that must be translated into tenant-friendly written summaries, produced within three days of completion.
  
• Scheduling and tracking follow-on works, often across multiple contractors and teams.
  

These obligations create a new layer of administrative pressure. Social landlords require more than just compliance processes; they need systems that simplify, automate, and keep pace with evolving legislation. That’s why we’re building Hazard Case Management for Awaab’s Law – a solution designed to help providers manage incoming reports, stay on top of deadlines, and generate tenant-friendly summaries automatically.

MHCLG’s data model, and how we’re using it. 

We’re delivering this new product at pace, so we were encouraged to read MHCLG’s recent blog post and learn of the work they’ve been doing to develop a data standard for hazards.

The model, built with HACT’s UK Housing Data Standards, brings together all the necessary information for teams to meet their obligations under Awaabs’ Law. By breaking the process into clear components, it maps directly to how landlords work day-to-day – which makes it much easier for suppliers like us to translate the standard into usable software.

Investigation component: captures the details of hazard investigations. We’re using the investigation_notes field to feed into our AI-enabled summary generation, helping turn technical findings into clear tenant-friendly reports without adding to caseworkers’ admin burden.

Property component: links hazard reports to the properties they relate to. We plan to use this data to provide landlords with insights into the types of properties and property attributes where hazards are most likely to occur, enabling a more efficient and proactive service for tenants. 

Work order component: records repair tasks that can be associated with a hazard case. Follow-on work is often where landlords drop the ball, as they struggle to piece together what work is required and when. Once an investigation is concluded and follow-on work is defined, we’ll enable tenants to book the work at a time that suits them through our tenant scheduling interface. This saves landlords time and admin, and increases the likelihood of tenants being home when operatives arrive.

Tenant component: captures tenant and household member details, including attributes such as vulnerabilities. This information is critical when making the initial categorisation of a hazard as significant or emergency. We’ll be using data from this component to flag vulnerabilities clearly to case handlers in our case details screens.

Appointments component: holds information about dates and times of scheduled hazard investigations. We’ll be using this data to help planners track which investigations are scheduled, which aren’t, and how long is left to meet the statutory timeframes.

Built for the future

With the scope of Awaab’s Law set to expand over the next two years, day-to-day repairs processes are going to start morphing more and more into the shape of the Awaab’s Law process –  deadline-driven, tightly tracked, and requiring clear tenant communication (all of which will benefit tenants). The fact that the model already incorporates attributes like SoR codes is vital, because it means hazard management can be integrated seamlessly alongside wider responsive repairs operations.

What excites us most is the forward-looking design of the model. It’s not just about damp and mould today. Its modular structure anticipates the expansion of Awaab’s Law to cover all HHSRS Category 1 hazards, meaning the work we do now won’t need to be rebuilt later. 

A foundation for sector-wide improvement

As MHCLG outlines in their article, poor data standards across the housing sector cost hundreds of millions each year. Awaab’s Law requires a repeatable, deadline-driven process that many landlords would struggle to design on their own. By providing a shared model, MHCLG is helping to set a baseline for how hazards are recorded and tracked.

Models like these create the conditions for greater data consistency in the sector, nudging both landlords and suppliers toward a common approach. In doing so, they reduce the risk of each organisation reinventing the wheel and make it far easier to build scalable solutions.

Conclusion

Awaab’s Law is a wake-up call for the sector. The deadlines are tight, the obligations are significant, and the risks of non-compliance are real. But with the right foundations, it’s also an opportunity to modernise housing services and improve tenant outcomes.

For Made Tech, MHCLG’s data model has accelerated delivery for Camden and Barking & Dagenham, giving us confidence that what we’re building today will scale seamlessly over the next two years. For the sector as a whole, it sets the stage for greater consistency, better data, and ultimately safer homes for tenants.

The post From Policy to Practice: How MHCLG’s data model is enabling us to deliver at pace appeared first on Made Tech.

In this blog, I’ll explore the hidden costs of avoiding SLAs and the dangers of over-engineering for unattainable uptime. I’ll look at how a shift in mindset can help teams become more comfortable with being measured and some practical steps that can improve both service reliability and user satisfaction. Read on to discover how a more mature approach to SLAs can transform the way we deliver services and better serve the British public.

SLA avoidance

Historically, SLAs have been used as a commercial stick to penalise teams that don’t meet their commitments. Financial penalties for failing to meet an SLA have conditioned teams to either avoid them or insist on SLAs that don’t truly reflect service availability. Instead, teams fall back on metrics like bug report response times or processing a set number of tasks – neither of which benefits the users or adds business value. 

Are we overspending for uptime?

When there’s no SLA, the idea  that a service should have 100% uptime fills the vacuum. But aiming for 100% availability often results in excessive redundancy, such as running 3 servers instead of 2. Cloud providers are more than happy to charge for extra infrastructure, even if there is no need. Does the value of the service really justify tripling the cost? And what’s worse, redundancy doesn’t always guarantee uptime. A recent outage for a cloud provider across 2 of its UK data centres, meant that the rush to its third data centre overloaded capacity, causing widespread failures.

Moreover, redundancy doesn’t just increase costs linearly. For example, running servers across multiple data centres incurs fees for data transfer between locations. I once worked in a team that ran a database across 3 data centres, but the constant data shuffling between them to ensure redundancy, added around £80k in unnecessary costs in just one month and when 2 of the data centres went down, there weren’t enough specialist servers in the remaining data centre to keep the system operational.

The cost of over-engineering

When teams are pressured to achieve perfect reliability, they often over-engineer their systems regardless of whether there is a business need. This complexity comes with high operational costs, requiring more staff to maintain. The additional complexity also introduces additional failure modes, ironically making outages more likely. .

Over-optimising reliability can also lead to opportunity cost. Teams may spend months optimising for rare outages when they could instead be building new features, improving user experience, or reducing costs. For example, a government team once spent 6 months developing a process to avoid more than 5 seconds of downtime during a database migration. The money spent on this could have been used for more impactful work elsewhere, or at a more fundamental level could have been spent elsewhere such as hiring additional nurses for the NHS.

The security risks of avoiding updates

As services mature, they generally become more reliable. Bugs that cause early issues are fixed over time. However, as services mature the biggest risk to service reliability becomes changes to the system. Teams aiming for an unobtainable 100% uptime may consciously avoid making necessary updates or implement overly elaborate change management processes. This can be dangerous.

Many modern web services rely on dozens, even hundreds, of third-party libraries – each one a potential source of security vulnerabilities. These need regular updates, but teams often fear making changes that could cause downtime. The result? Outdated services with a plethora of small vulnerabilities that build up over time. If these vulnerabilities align known as swiss cheese vulnerabilities, the risk of a security breach becomes more severe. Furthermore, services that avoid updates can become less relevant to users as they fail to meet their evolving needs.

Frequent releases are essential for maintaining secure and relevant services. Teams familiar with continuous integration (CI) and continuous deployment (CD) often release updates tens of times daily. But when changes become rare, the skills and knowledge of how to do this safely fades, increasing the risk of failure and making teams even more hesitant to make updates.

Planning for the inevitable downtime

The perception that a service needs to achieve 100% availability prevents teams from preparing for planned downtime. Many services don’t have a ‘shutter’ mechanism to notify users when a service is intentionally offline for maintenance. For example  during  a database migration. Providing users with a simple, branded message would offer a much better experience than a generic 4xx or 5xx error page if they try to access a service during downtime.

Government digital services are expensive, but the convenience they offer the citizen generally justifies the cost. However, teams often lose sight of just how much they’re spending. A useful approach is to frame costs in relatable terms, like how many nurses could be employed with that money. When you look at it this way, striving for “.999%” availability is almost  never worth the price.

How can the government move the needle?

UK government services must pass through a series of service assessments during their development stages – discovery, alpha, beta and live. However, many services remain in beta indefinitely. This isn’t because they’re unfit for live deployment, but because teams fear that funding might be cut once they move to the live stage. If these services were built to meet realistic SLAs, they could be operated at a fraction of the current cost.

The Government Digital Service (GDS) standard includes the principle ‘operate a reliable service’. This states that ‘Users expect to be able to use online services 24 hours a day, 365 days a year.’ However, this phrasing unintentionally sets the expectation of 100% uptime, which is unrealistic. Teams are set up to fail if they aim for this, as most government services simply don’t have the budget to support such reliability.

Instead, the service standard should say: ‘operate a service as reliable as necessary to meet user needs.’ It could include benchmarks like:

Matching service expectations to needs

However, it’s crucial to stress that the juice has to be worth the squeeze. Aiming for additional ‘9s’ in availability should only be pursued when the societal cost of not achieving that reliability outweighs the investment required. For example, if the cost of 0.001% of tax returns being filed late is less than guaranteeing 99.999% uptime, then we should avoid spending more money for such small improvements.

Big players like Amazon or Google have modelled what a 15 minute outage will cost them in lost revenue. The web is filled with advice for attaining near perfect availability based on the models of these tech giants. However, the cost of a short outage to a government service is usually inconvenience or at worst reputational damage.. 

In my opinion, most government services could tolerate up to 15 minutes of downtime per day without significant consequences. Of course some services are critical – lives may depend on them. But these are the exception, not the rule. The truth is that most government services still have paper, or phone based alternatives, so our yard stick for online service reliability should be grounded in reality, not in comparison to private sector giants like YouTube or Facebook.

Graceful degradation

Richard Pope’s Platformland shares a vision of 100s of interconnected services lowering barriers to the UK public and enabling a model where the public is served proactively. However, I fear that this interconnectivity will demand even more unattainable  reliability. Instead of  pragmatic thinking about how services should fail. The current model for failure is that an error is raised and a Site Reliability Engineer (SRE) is alerted. However, this rarely results in the original user need being fulfilled. Instead the offending code will be fixed and the user will be forced to use an alternative means of realising their intent.

Embracing SLAs

By following some of the tips in this blog, I believe reliability and user satisfaction can be significantly improved. Healthy discussions about the appropriate level of reliability for services will lead to reductions in costs and waste. Ultimately, a positive approach to SLAs will enhance services and better meet the needs of the British public.

The post Why public sector digital can’t afford to shy away from SLAs appeared first on Made Tech.

Q: How did you decide on a software engineering career?

I ended up working in software engineering because my parents used to say ‘ you’ll never get a job if you’re just sitting and looking at a computer screen all day’. Joking of course, but who didn’t hear that growing up?

My working life began at 16 with a temporary office job in my hometown as part of a government initiative tracking cows after the foot and mouth disease outbreak. After being made redundant from that role, I took a job at McDonald’s to save money for university.

During my studies, I continued to work in hospitality, which if nothing else, showed me that I wanted a different career path. I realised I preferred the quiet focus of an office environment, enjoying tasks that felt like mental puzzles – where I could use my creativity to find solutions. This realisation made studying computer science and pursuing a career in software engineering a natural fit. 

After a couple of years as an IT assistant I moved to Manchester and joined a coding apprenticeship scheme. While I found the IT work enjoyable enough, it involved a lot of physical labour.

It might sound like an odd life goal, but after working many stressful, physically demanding jobs – a quieter, more mentally engaging career became a priority. I’ve now been at Made Tech for nearly 4 years and the rest, as they say, is history. 

Q: You mentioned enjoying mental puzzles, is there another area in tech that fits that creativity?

I’ve always had an interest in cybersecurity. For years I’ve enjoyed listening to cybersecurity podcasts purely for fun. I also volunteer with a local charity, where I’ve recently been advising on potential cybersecurity mitigations – that’s something I also get a lot of joy out of, using my skills to benefit the public good. 

I’m excited about the idea of growing my skills in cyber security and teaching others on how we can all protect ourselves. You may have heard that as humans, we’re the weakest link in any security chain. 

For example, did you know that during the early days of phone hacking or “phreaking,” as it’s been called, people would pull off crazy stunts? Back in the 60s and 70s, people used creativity to mess with the structure of the new nationwide telephone network. Namely in the form of free toy whistles found in Cap’n Crunch cereal.

When blown they would hit 2,600 hertz frequency, which was the same frequency that the phones used to disconnect the line. So people would walk past a bank of phones, blow into a whistle and then watch everyone get annoyed when they got cut off.

Q: What is it about cyber security you enjoy so much?

What I find really interesting about cyber security is the creativity behind it. The idea that people make a system to do a thing and then someone else thinks about how to use that system for completely unintended purposes. While these hackers didn’t have the best intent, the innovation is what’s interesting. 

We build systems with specific intentions, and then others find creative ways to use those systems for unintended, sometimes malicious reasons. It’s that ingenuity and the constant interplay between creation and exploitation, that I find really interesting. 

Q: Let’s talk about workplace culture, alongside problem solving and creativity – what’s most important to you?

When it comes to work culture, I think collaboration in a team is important. We’re big on collaboration at Made Tech. That may sound like a bit of a non-answer from me, but having worked in teams where sometimes I was the only person maintaining a product and there’s no one else to rely on when things start to go wrong. That can be incredibly stressful.

One of the things I really like about Made Tech is that we do try to be as collaborative as possible by nature. We’re open and happy to share our experiences, knowledge and learnings with each other.

We’re really great at lifting each other up here too. In some of my previous roles it’s been a bit dog-eat-dog at times, with promotion windows causing competition instead of collaboration. What I do find working here is that every project I’ve worked on there’s been other members of the team to confide in. I’ve been able to rely on their experience and knowledge – everyone’s happy to give each other a hand. That shines through with our commitment to mentoring and upskilling more junior staff members.

Q: Speaking of mentoring, do you have any guidance for those breaking into the industry?

Don’t suffer in silence. While I was growing up and working in customer service, the mentality was always that if you’re not pulling your weight and adding value, then you’re not worth your place in the team. Everyone had their own work and you had to get on with it. The environment was competitive, everyone wanted to move up and getting a promotion was a zero-sum game. 

It took me a while in more healthy teams to acclimatise to being able to ask someone for help. Whether they have expertise or domain knowledge that I don’t, or just to have another pair of eyes on what I’m working on. In software engineering, we all need to be pulling in the same direction. We need to foster a supportive working environment, otherwise progress will slow.

Q: Something we hear about a lot is imposter syndrome, do you have any advice for that?

Considering my early experiences, my impostor syndrome was through the roof early in my career. I thought I’d ‘lucked in’ to my role, and would actively avoid more senior members of the team – because once they saw how useless I was, I’d be ‘found out’ and lose my job and career.

It wasn’t until I started mentoring that I realised just how ubiquitous this experience is – especially for women in tech. When I was first asked to line manage 2 of our associate engineers from the Made Tech Academy, I was terrified. What could I possibly know to help out these talented people? Would I end up accidentally tanking their career? 

But once I started talking to them, they both had the same problem – they felt their development was slow and they weren’t progressing as well as other team members. This was affecting their self perception more than anything else. I remember promising to help one of them through a problem. She realised she already knew what to do after I’d asked a few questions. I pointed this out, shared my experiences and asked her to not let the impostor syndrome overcome her like it used to for me. 

She asked how long it took in my career for the impostor syndrome to go away completely. I laughed, and told her I’ll let her know when it does.

Are you looking to join a collaborative team with a purpose? Take a look at our open roles. 

The post Embracing the creativity in tech appeared first on Made Tech.

Tess Barnes shares her take on leadership in software engineering, the importance of creating safe learning spaces and the value work/life balance brings to career growth.

Q: What do you like most about being a lead software engineer?

I did an interview similar to this 4 years ago and I’ve learnt a lot in that time. I’ve been in a lead role on and off most of my career and it’s nice to feel that I’m in that space of being a multiplier. I enjoy unblocking issues, translating things for people and I’m heavily investing in the people around me – the people coming through Made Tech, career changers and our apprentices too. I believe really strongly that my experience is only helpful when it helps more than just me.

I consider part of my leadership remit very much to enable. Sometimes that can mean getting through prototypes quickly on a project or enabling the really talented people that work at Made Tech. My take on leadership is about making it easy for those people to share their talents and deliver awesome stuff for society. 

Q: How do you go about inspiring those people?

Listening is key. Everyone brings their own set of motivations, sometimes they’re really open about sharing them and sometimes they take a little while. Often when it comes to inspiring others it’s about encouraging them to realise they can go further with an idea or think about things differently.

It’s about saying, ‘okay you found this wonderful thing and that leads onto 2 topics that are beyond where you are now. But this is where we could be and this is where your journey can go. Enjoy this bit because it leads to greater things.’ It’s about having that discussion on how we start hitting a growth mindset. Encouraging people to recognise what they know today won’t take them far enough for tomorrow.

As I said, it’s also necessary sometimes to encourage people to think in another way. Asking those questions on when we should make a decision to change the way we’re thinking about something. It’s important to work with people and say ‘I’m glad you’ve asked that question, let’s explore that together’ or ‘let’s see how this plays out and how you can do it differently.’ 

Being able to have these conversations with people in a safe and non-judgmental space is important. Let’s grow in an exploratory environment where it isn’t about judging, it’s about learning.

Q: How do you stretch that thinking to the wider engineering community at Made Tech?

I have a 2025 commitment around being more connected myself but also helping other people be more connected. Being in a consultancy can be a really tricky balance between our valuable face-to-face time with our clients and time with our engineering community. 

Helping my colleagues feel in touch and inspired is important to me. There’s lots of people around Made Tech that are doing that and it’s something that I feel we’ll all benefit from doubling down on in engineering.

We’re mostly at the coalface in the delivery and don’t necessarily connect with each other more than once or twice a week. That can be tricky, so making sure that connection’s still there, and still valuable, is important. We’re connecting to feel human in a space so our creative juices are still flowing. That’s my mission this year.

Q: You spoke about growth, do you have any advice for anyone looking to grow and learn? 

For those that really enjoy the code, tinkering and have that creative mindset – still enjoying it is really important to growth. I say to whoever I’m on a course with, a rested mind is a learning mind. So if you want to be in tech, of course you should be interested in it. But I would also say, have other things you’re interested in that can help give your brain a rest. 

If you play music or you’re interested in sports for example, it gives you an offset which brings in creative thought. For anyone who wants to be sustainable in the tech industry and software, allow yourself that time. It’s not about constant hands on the keyboard. There’s a world within software but outside that too – finding the balance is important. 

Q: Any books or resources you’d recommend for further learning?

Interestingly, of the 3 that I suggested 4 years ago, at least 2 of them I’d still mention today. That’s the Phoenix Project by Gene Kim, Kevin Behr, and George Spafford on devops. The second is Rebel Talent by Francesca Gino and  when following the rules is a good idea and when not following the rules is a good idea. 

A new addition I’d recommend is Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. It’s not just for apprentices, but anyone who wants to view or review software craftsmanship with a learning and curious mindset. 

Q: Building on that, what areas are you looking at for your own development?

I have learned every day. I’ve made it my mission to not stay still. I am really intrigued with systems thinking. I have always thought that way and I found it quite difficult in the earlier years of my life to translate that lateral thought process on deliveries. 

Lots of people think in lots of different ways. I’ve always been a person that can zoom out to see the bigger picture and think ‘what’s actually causing this thing?’ On a project we’re often looking at a small part. We can see what happens in that space, but actually if we zoom out we can see that all of this is happening because something somewhere else is happening and having an impact. 

For me, it’s about learning the lexicon that everybody is using in this system’s thinking space and then figuring out where I can apply it. I’ve been writing code professionally for about 20 years and the most interesting thing to me now is recognising how systems work. Yes, of course the code is important, operating in a lean DevOps style is important – but also thinking ‘how is it going to work in this wider framework?’ 

Q: Is there anything else you’re focusing on this year? 

I want to extend the range of training courses that I’ve written and offer. I’m talking to Dom, our L&D Specialist Technical – Engineering Coach about the curriculum for our apprentices. They have a set behaviours, skills and knowledge framework they need to hit, but it’s how we express that in a way that works for consultancy life and tech. That’s a focus I’d love to bring.

For the last cohort, I ran training on getting secure pipelines running and making sure that they’re secure as well as sessions on Docker and containerisation – which are kind of the nuts and bolts around how things get built and hosted. Those deserve a bit of an update because our tech constantly moves on and I’d like to add a few things around containerisation to that as well. 

It’s important for me to make sure that our core values and consultancy skills that we add to the apprentice standard are covered – Dom does an awesome job at that. We cover the software skills and practices but then we also have this DevOps coverage. I really hope to be part of a collective in Made Tech doing this training. 

If you’re interested in joining the team here at Made Tech, take a look at our open roles or sign up for our newsletter to receive monthly notifications about new roles.

The post Learning every day – leadership in engineering  appeared first on Made Tech.

We believe recruiting team members with unique career backgrounds, different experiences and personalities is the best way to reflect and serve society. So if you don’t have a ‘traditional’ background in software, don’t let that stop you from applying. And if you’ve never done a technical interview before don’t worry. In this blog post we’ll take you through everything you need to know. 

The technical interview  

There are many reasons we hold a technical interview for our software engineering roles. This includes gaining an understanding of how you work and how you respond to feedback. A technical interview helps us evaluate how you collaborate with other team members, communicate your ideas and your ability to explain technical concepts in a nontechnical way (e.g to non-technical people).

The technical interview is also a chance for you to share more about your experiences with our preferred ways of working – that’s things like pair programming and test driven-development (TDD). During the interview you can also give us insight on your experiences with different technologies, for example your chosen language, framework and cloud provider etc. 

Try not to feel nervous, remember this interview is also about finding out if we’re right for you and if Made Tech is somewhere you feel you could thrive and see yourself working at. 

What can I expect?

We’re all about striking the right balance in our approach to hybrid working. That means all of our interviews are remote, so you can attend from wherever you are and at your convenience. It’s always a good idea to choose somewhere that’s distraction-free for your interview – although we understand interruptions can, and do, happen. Hosted on Google Meet, your technical interview will be a video call with our friendly team. We’ll always aim to have 2 engineers interviewing you. 

Your interview will consist of 2 tasks. The first task is a system design exercise where we’ll present you with a scenario and ask you to sketch out a high level diagram of the pieces that could deliver this service. Next up is pair programming. Following the same scenario, you’ll pair with an interviewer in a short coding kata, implementing some of the logic for the new service you helped design in the first task using TDD.

We split the interview into these 2 skill-based tasks for a couple of reasons. The system design task helps to make sure all of our engineers can think about the “big picture” context for their work and are able to provide reasoning for high-level decisions. The pair programming exercise helps illustrate how we like to work, as we believe pair programming on our teams ensures constant knowledge sharing, improves code quality and helps to reduce bugs.

Throughout the technical interview, each candidate is asked the same initial question on each section. This helps us make sure we’re following a fair and equal process. 

Now let’s go through each task in a little more detail. 

The system design exercise

We use Miro, a virtual whiteboard, for the first section of the technical interview. But if you’re not familiar with it, don’t worry. We’ll always guide you through the basics needed to complete the exercise. 

We have a few tips for you when it comes to this part of the technical interview. Firstly pick somewhere to begin and start small and simple. This is so you can make sure you’re identifying the requirements and implementing enough to meet that requirement – this is our ‘minimum viable product’. 

During this exercise we’re looking for ‘evolutionary architecture’ – this means the design of the system evolves as new requirements are introduced, rather than a ‘big up-front design’ that tries to do too much, too early. Start with a simple solution and then look for reasons the simple solution may need to change. As our conversation progresses, evolve your architecture to meet new requirements and the changing needs of the user. 

Speaking of the user – make sure you’re thinking about user journeys throughout and talk us through your design decisions. One way you might do this is to think about what makes your system scalable, reliable and secure – use that to justify the decisions you’re making. 

A big part of this task is communication, remember to talk through your design as we go through the exercise. This is so we can understand why you’re making certain changes. As a top tip, remember to ask your interviewers questions to help you make those changes, for example:

• How many users do we expect?
• Does this change over time? (are there more users during the day vs night?) 
• What mobile devices do our users have access to?

Remember that it doesn’t matter (too much) if your diagram isn’t the neatest.

The pair programming exercise

During your interview, pair programming is done via screen sharing. To save time, we need you to share your whole screen as opposed to simply your browser window. This is why we’ll ask you to set up your environment in advance – ready to test! So make sure a placeholder test runs ahead of time.

Pair programming is all about collaboration. Here’s where we can see how you work with other members of the team. It’s important to note that we don’t expect you to necessarily ‘complete’ the test exercise. Collaboration and conversation is more important here. Don’t be afraid to ask questions to who you’re pairing with and talk through what you’re thinking. Your communication skills in this stage are just as important as the code. 

As before, make sure you’re taking small steps like writing tests before code and collaborating with your interviewers. Another tip is to think small at the domain level rather than trying to create a full web app with database storage.

Always use a language you’re comfortable with – don’t fall into the trap of trying the latest thing or something you’ve learned in the past month. This doesn’t usually end well, so stick with what you know and it will enrich the rest of the exercise.

If TDD is new to you – tell us! Be honest about your experience. It’s not a problem if this is something you’re unfamiliar with but please do factor this into your interview preparation – so you can evidence it. We want to see a willingness to learn. During your interview we’ll see if you can do TDD with our support.

Are you our next software engineer?

Here’s some final guiding words on whether we could be a good match. If you’re collaborative by nature and opinionated but open to learning new things – we want to hear from you. If you have a broad knowledge of lots of areas or expertise in one, let us know. As long as you’re adaptable with an eagerness to embrace technologies you may not be familiar with then get in touch. 

For a few final resources to help you prepare for your Made Tech software engineering interview, take a look at:

• Code Katas 
• the C4 model for visualising software architecture
• our latest blog posts and case studies

We hope this has given you a small insight into what a technical software engineering interview looks like at Made Tech. If you haven’t already, take a look at our open roles.

We recently hosted a 30 minute session on what it’s like as a senior software engineer at Made Tech. Watch our recording to find out more.

The post Preparing for your software engineering technical interview appeared first on Made Tech.

One of the recurring challenges is how to make sure they’re reliable and flexible, this got us talking about some of the tools behind microservice architectures. If you’re not familiar, microservice architectures are multiple smaller programmes that together deliver those big complex systems. 

I’ve recently been working with a few of these tools, so in this post I’ll explain how they can work together to make sure what you’re creating is seamless and scalable – with a nice camping analogy thrown in.  

What does engineering and camping have in common?

I’ll start with some definitions. 

Docker: Where it starts. Docker is a programme that allows you to organise your code into microservices – from here we’ll call them containers.

Kubernetes: This is an open-source tool that allows you to manage your containers.

Helm: This is where it all comes together. With Helm you can automate the deployment and management of your Kubernetes applications.

Going into slightly more detail, a container is an isolated environment for your code. It’s important to note this means that a container also has no previous knowledge of your operating system. An image is a snapshot of this environment and contains instructions for creating the container. The container then runs your code. 

Docker images are built from Dockerfiles, these are the text files that contain the commands required to set it up. There are many commands you can use in a Dockerfile including FROM (the base image you want to build from), COPY (files you want to copy from your local environment into the container) and CMD (the first command run on container startup).

Now let’s imagine we’re going camping. In this analogy, our containers are similar to tents and Dockerfiles are the equipment lists needed to set up our tents. 

FROM = tent style/design, number of zipped doors and number it sleeps

COPY = the equipment you need in the tent

CMD = first thing you do (boil kettle, nap, grab a beer and turn on the lights)

Summer

Let’s carry on with our camping analogy. You want to start a glamping campsite. You’ll provide the tents, you set your first tent up and like how it turns out. It’s blue, sleeps 4 and comes with solar-powered fairy lights and airbeds with linen. Not one to keep this to yourself, you get some friends to try it out and stay there before you open business to the public. They love it, and you decide that your setup is perfect. You duplicate your setup for five more blue tents and start getting paying customers to stay.

In technical terms: This is at the moment a group of Docker containers, which you manage yourself.

Autumn

Your business is a hit. You’re fully booked for the next 3 months and decide to expand. So far the business seems to be doing well with the tents setup as they are, so you want another group of tents, perhaps in a different colour to make the site look more aesthetic. 

You decide to hire someone to manage the original group of blue tents and someone else to manage a new group of 6 orange tents. The managers are responsible for maintenance of the tents, making sure all of the equipment is available and working, and they flag to you if it isn’t. They’re also trained to rebuild tents if they fall down in adverse weather. 

It’s quite a nice arrangement. The tent managers are responsible for the details of each setup. It will only deviate from this if you want something changed. This means the tent configurations can be left to them while you focus on the bigger picture – like how to keep cows from the neighbouring field out of your glamping area.

In technical terms: The managed groups of tents are now Kubernetes deployments, each one being managed and maintained without your input via a Kubernetes manifest (a YAML file where you define features of the Deployment). The example YAML manifests below define deployments for blue and orange tents, 6 of each and both sleeping 4 people.

Winter

Now we’re in winter and adverse weather seems to be happening more often. The tent managers have been doing a great job keeping all 6 tents in their respective group well-maintained. But the bookings are thinning and you realise you don’t need to pay people to maintain all 12 tents when a portion of them are sitting empty. You instruct your tent managers to reduce their group sizes to 4 apiece (8 in total). 

You also get several complaints about the warmth of the tents. You had perhaps forgotten that this is glamping not camping, and customers don’t expect a temperature difference between a canvas sheet and their own home. You realise that your initial setup may have been perfect for summer but is less so for winter. You tell the tent managers to add blankets and duvets to the tents. These changes seem to do the trick and bookings drift back to pretty much full.

In technical terms: The changes here are things which you would change in the Kubernetes deployment manifest and re-deploy. In the YAML snippet below blankets have been added to the blue tents deployment.

Spring

It’s spring and things are starting to pick up. You instruct the tent managers to increase the tent numbers back up to 6 apiece in anticipation of a flood of booking requests as the winter frosts thaw. 

However, the site’s demand doesn’t pick up with the warmer weather as you expected. You wonder what you could do to encourage visitors. You decide to start offering electric hookups and WiFi for the tents. You don’t have the expertise to install and maintain those features, so you employ 2 more people to manage them for you. You initially set the price for each feature at £5 per tent, so people wanting both electricity and WiFi would pay £10.

It works – it turns out that people love coming to fields to surf the internet rather than sitting at home. You are once again flooded with booking requests and figure you can probably raise the electric and WiFi prices. You ask the service managers to start charging £7.50 per feature, £15 for both.

In technical terms: The services you’ve added are Kubernetes objects, such as Services, Ingress and ConfigMaps. There are loads of types of Kubernetes objects which you can add to your deployment to make your application externally available, apply configuration etc. These are also deployed manually via YAML manifests, like the electric hookup example below.

Summer (again)

You’re starting to get the hang of this glamping thing. You realise that there are yearly fluctuations in popularity and predictable variations in the market. Each change is communicated to the managers.

However, you end up communicating the same information to separate people. The tent managers are often busy doing different things to the service managers, so you spend time chasing them down to let them know how many tents are going to be in rotation in the next few weeks. “I sound like a parrot”, you say to yourself, “if only I could just tell one person all this stuff”.

It dawns on you that the factors which change don’t include every aspect of a tent setup or site features. In fact, the variables can be distilled down to a select handful. For a group of tents, the fact that we’re talking about tents rather than brick buildings is a constant. The fact that customers have an 11pm curfew never changes and the fact that the tents don’t include toilets never changes. 

The number of beds can change, the style of tents may change and the thickness of bedding provided depends on the season. And so you could actually instruct almost anyone to pass on this information to the tent and feature managers. If you want anything changed you’ll leave a sheet of paper on their desk informing them of the few tweaks you want to make to the site. 

It is so much easier now that you just have to worry about a single file, rather than maintaining and considering every detail of every tent and feature on the site you painstakingly set up. You have so much more capacity to concentrate on the bigger picture – like whether a scone has jam then cream or cream then jam.

In technical terms: This extra layer of management is what Helm provides. Instead of individual manifests for each Kubernetes object which you have to deploy yourself, and factors are modifiable via a single YAML file (always called ‘values.yaml’), you can deploy an entire application with a single command, rollback with a single command, update or delete with a single command. 

All of the Kubernetes objects (which with some applications can be tens or hundreds) are controlled easily and as a group rather than individually. You’re still able to interact with them at a more granular level, but you don’t have to. The example YAML below shows a values file for the orange and blue tent Deployments. The key variable factors are defined in this file and templated into the Helm chart.

Values.yaml                                      deployment.yaml

Reflecting on your success

Some time in the future you sit back in your deckchair and reflect on how far you’ve come. You now own the neighbouring cow field and the one beyond it, keep the cows in your own garden and can rotate your tents around the fields depending on their muddiness. You asked your site manager to increase capacity, hiring 4 more tent group managers. A new service manager is in charge of the weekly food rota – meat-free Mondays, pizza Wednesdays and fish and chips on a Friday. 

The entire site is well-established, but configurable by a single point of communication. All managers are open to changes and flexible enough to carry them out. If the site manager said “site closed” they would all bring their tents in. If the site manager said “the most recent changes have done diddly-squat for our profit margins, we’re rolling back” the tent and feature managers would revert whatever modifications had just been made. You feel like you can easily control this business and everyone is better off for it – a huge success!

In fact, you think you could probably handle another one or two of these…

So there you have it. Using Docker, Kubernetes and Helm in harmony can be as seamless as that. And bonus, your software is now reliable and scalable! You’re able to make smaller changes that contribute to your big picture and there’s limited downtime. Next time you’re considering microservice architecture, think about how the tools behind them can come together to work for you. 

If you’d like to stay up to date with all of our latest blog posts, case studies and upcoming events, subscribe to our monthly Made Tech Insights newsletter.

The post Make your software flexible and scalable by…camping? appeared first on Made Tech.

If you’re looking to sharpen your programming skills and learn to ship high-quality code on projects that make a difference, we’re opening applications for our new Level 4 DevOps programme on 13 November 2023. 

Why choose an apprenticeship?

Modern apprenticeships have come a long way since they were first introduced in the 90s. There’s now over 800 apprenticeship standards and they cover all types of careers across many different sectors. One of the great benefits of apprenticeships is that they’re designed by employers to meet the needs they’re seeing in the workplace. This means you’ll be learning in-demand skills from experts in your field – while earning!

Apprenticeships are a popular option over traditional university courses and can work for any education level. They span from level 2 GCSE, right through to level 7 Masters degree, so there’s something for everyone. Our DevOps apprenticeship is level 4, which means we require you to have a level 2 Functional skills (or equivalent) in Maths and English and not hold a degree in a related subject. 

There’s also no age limits on apprenticeship programmes, so they’re a great option for school leavers and careers changers alike. As long as you meet the criteria, you can take your first steps and earn while you learn.

“Creating rewarding careers in digital for people from all backgrounds regardless of their access to formal education is something we feel truly passionate about.“

Chris Blackburn, Chief Operating Officer at Made Tech

Start your career in tech

For years we’ve been helping train and support people on their journey to a career in tech. Making sure we’re bringing new talent into our sector with people from different careers and lived experiences is how we see new ideas and perspectives. Launching our own apprenticeship programme felt like the natural next step. 

We’re excited to open this programme to people from all backgrounds, whether this is your first job, a change of direction or a return to work. As long as you’re excited by the idea of shipping high-quality code that can make a real difference to the public sector  – we want to hear from you.

You’ll learn from team members who have spent years perfecting their software engineering knowledge and skills. Our apprenticeship also comes with the added benefit of giving you experience of working with a variety of client organisations solving a range of societal challenges – from housing to healthcare. Our expert mentors will teach you everything you need to know to grow in your role as a great consultant. 

“Having taken over 100 people through our Academy since 2017, we’re really excited to launch the next chapter as an accredited apprenticeship. With digital and technology skills in short supply in the UK, as a society we need to do more to grow our own.“

Chris Blackburn, Chief Operating Officer at Made Tech

What to expect 

We’re taking a blended approach to this programme, which means you’ll experience a mix of face-to-face learning and virtual sessions and tutorials over 18 months. The first 10 weeks will act as a bootcamp, helping set you up with a strong foundation. During this time we’ll teach you the software engineering basics you’ll need before you go on to live projects, including responsible coding, test-driven development and consultancy skills. 

To make sure you’re getting the most out of the programme, you’ll have a review with your technical coach and line manager every 6 weeks. They’ll also be ongoing assessments during and after each module so we can make sure you’re on track, provide any extra support if it’s needed and prepare you for your final assessment. 

From week 11 you’ll start working as part of a team on real client projects. This is where you’ll apply everything you’ve learnt so far. From this point in the programme you’ll also attend structured learning days where we’ll teach you theoretical knowledge on 7 modules that you can apply to your new day-to-day role. Learning days will take place every month and be a mixture of in-person and virtual learning. 

Once you’ve successfully completed your final assessment and the apprenticeship programme, you’ll have earned a level 4 DevOps qualification and have developed a clear pathway for your career at Made Tech. 

If you have any questions about the apprenticeship you can reach out to Bil Badul from our talent team at bilal.badul@madetech.com. Or if you’d like to know a bit more about what life is like at Made Tech, you can take a look at recent blog posts by the team. 

The post Launching our new DevOps apprenticeship programme appeared first on Made Tech.

It’s possible for one architectural design to allow flexibility in ways that help deliver the backlog, but for another design to double or even quadruple the effort required to deliver the same backlog.

There are many dimensions to the cost-of-change nature of a software project, and good software engineers consider this continuously. Simplified, it can be thought of in 2 ways: the baseline cost of change and the cost of change in a particular direction. The baseline cost of change can be considered the engineering effort required to implement any feature (of any shape or size). In contrast, the cost of change in a particular direction can be considered such that the design is optimised to allow the team to quickly implement changes of a particular nature.

Good teams keep their baseline cost-of-change low and learn from their historic backlog to make it easier to deliver more likely changes. This continuous effort helps keep the average pace (measured over a number of iterations) of delivery predictable.

Most teams aren’t aware of how to reduce their baseline cost-of-change and much less how to optimise their design for their circumstances. The most common warning sign is when your software engineers fear changing the code.

If you don’t have automated tests, start now

If your engineers fear making changes, you know 2 things: they aren’t optimising the architectural design, and the baseline cost of change is high. This fear of change comes from not being confident that the valuable “behaviour” (the software’s functionality) hasn’t changed or had defects introduced. Teams lose confidence in their ability to change when there isn’t a quick and easy way to verify the behaviour of the software.

The first way teams can drastically improve their baseline cost of change is to practise double-loop test-driven development. A common objection is that TDD isn’t possible on a project, but this is almost always never the case. TDD is possible in legacy code environments but requires slightly more care. In any case, to move beyond mediocrity, teams must adopt a disciplined approach to software engineering – TDD.

Useful books on this topic:

• Working Effectively with Legacy Code
  by Michael C Feathers
• Refactoring: Improving the Design of Existing Code
  by Martin Fowler
• Growing Object-oriented Software, Guided by Tests
  by Nat Pryce and Steve Freeman
• Test-driven Development: by Example
  by Kent Beck

In software projects without tests, the most valuable thing that teams can begin to do is write tests for all new code and around all code that is changed. Feathers explains a number of techniques to achieve this. In addition, it’s worthwhile exploring mutation testing and approval testing to “characterise” the behaviour of existing code (these systematic approaches to test-last are often called “characterisation testing”).

Once a team starts progressing in getting their software under test, they will notice their confidence will begin to grow, and their change failure rate (failure demand) should decrease. You can expect this effort to take at least 2 to 3 quarters to begin to have a significant impact, but you should expect to see a few things within the first quarter. In particular, you should expect the team to begin finding pre-existing defects, eliminating unused code, and experiencing fewer surprises in production.

Thinking beyond homogeneity

One reason that teams struggle to optimise for specific backlogs is that their software design is too homogenous. It looks too much like other software projects that do other things! In web applications, this is often caused by teams following a cookie-cutter pattern which closely aligns with the tools they are using. These teams will often have 3 or 4 layers of code, which their code must fit into. A third-party framework often defines these layers and may use names like “Component”, “Reducer”, “Model”, “Entity”, “Controller”, “View”, “Route”, and “Form.” If your software design looks like every other software design, then you haven’t optimised your code for your backlog.

For lots of large projects, the pattern that causes many negative side-effects is the third-party framework-provided Active Record pattern. It’s seen in many MVC frameworks, from .NET’s Entity Framework to the classic Ruby on Rails ActiveRecord. As used in most software projects, it leads to a side-effect code smell known as fragility. Fragility is where a change to a feature causes an unexpected defect in a seemingly unrelated feature. The Active Record pattern encourages coupling across many different use cases of a system and often assumes that the validation rules exist at the database layer. These assumptions are sometimes true, in particular in smaller systems, but very quickly (certainly in less than a few quarters) become not true as systems grow in size. In addition, the coupling of business rules to database operations means that this bottleneck heavily constrains the execution time of automated test suites.

Ideally, software should be designed around the specifics of your application’s domain and the required layers should be chosen per application. This will allow the software design to be optimised to enable easier backlog delivery. The application will still have the layers defined by the third-party framework, but they are only used as a mechanism to deliver the business logic of the application. For example, in a server-side web application written in Python, the third-party framework layers would be responsible for HTTP, HTML and handling things like form submission. It would not be responsible for validating input, applying business rules, making external calls to APIs or interacting with persistence such as a database.

Domain-driven design and hexagonal architectures achieve heterogeneity between applications intended to solve different problems. You should expect teams using these approaches to find themselves mostly adding code rather than modifying code to add new features. In addition, the software design becomes evident as to what it is doing and how it relates to the users’ domain. This contrast is stark compared to logically mapping the user’s domain to the relevant third-party framework concepts.

The code design of systems designed using techniques such as these often cleanly separates business logic from other aspects such as the method of delivery (the web), other external systems (APIs) and persistence (database). This means that business logic can be tested in isolation from these slow bottlenecks, which provides extremely fast tests. These fast tests aid in changing the code structure quickly so that it can be optimised to deliver the backlog. Teams with fast tests (e.g. that run in under 10 seconds) can make more code structure changes with confidence in an hour than teams with slow tests (multiple minutes). Teams with glacially slow tests (fifteen minutes or even more than an hour) will tend not to change the structure of their code as they can’t justify the per-change return on investment to themselves.

Assuming equal capability in the chosen approach, teams which practise double-loop TDD but essentially outsource a lot of their software design to third-party frameworks will more often than not lose the race compared to teams that design their software to meet the specifics of the domain.

In the public sector, organisations often define rigid technology strategies which heavily constrain how software should be designed. It’s not uncommon for all teams to be told that they must use “Ruby on Rails”-way, “Django”-way or “.NET Core MVC”-way. These organisations will then hire individuals into technical architect roles who assure that teams follow the third-party framework’s lowest common denominator approach. These organisations are enforcing homogeneity of their software design, and while this is undoubtedly helpful to teams without the capability to optimise their software designs and adopt a heterogeneous approach. Many teams are capable but suffer the consequences of this strategy. Adopting this lowest-common-denominator approach ensures all your teams will only ever achieve a maximum of consistently average performance.

Work towards cohesive systems

Lastly, to explore, we are left with the problem of cohesion. I have seen many teams battle with a systemic lack of cohesion, and those teams are often oblivious to the cause or believe that it “has to be that way”. A lot of this has to do with the trend of the last 7 years towards single-page applications backed by “RESTful” JSON APIs. Teams have 2 code bases that they must change in lockstep to deliver features. To work around this problem, we’ve seen the rise of technologies such as GraphQL, which paper over the deficiencies of this approach.

What is the problem? There is an industry-endemic misunderstanding of what RESTful means. A defining feature of a RESTful API is Hypermedia as the Engine of Application State (HATEOS). However, most, if not all, “RESTful APIs” are, in fact, simply Remote Procedure Calls over HTTP dressed up in a sort of REST-like fashion. A common objection to pointing this out is, “So what? This is what modern REST APIs look like, HATEOS was a pipedream anyway.” Quite frankly, this objection misses the point.

Many software engineers would rarely think of the interface between a web browser such as Firefox and a backend web application that responds with HTML as an API, but that is exactly what it is! The web browser is a technology that supports a range of API features that allow software engineers to deliver rich user interfaces. This API is a Hypermedia, and so many server-side rendered applications expose a RESTful API in the form of HTML for the purpose of displaying rich UIs to the user. HTML doesn’t have to be the only hypermedia, and web browsers don’t have to be the only hypermedia clients.

So, why are single-page applications undesirable? It comes down to cohesion, a software property that attempts to define how well a system is organised and optimised for a backlog. Cohesive systems have one location to express a domain idea. For example, if we must validate a user’s input, there is one location to express the idea of that validation. Many teams these days find that delivering a feature, such as a validation rule, requires code changes and deployments (in lockstep) across 2 or more code repositories. Often it starts with the React frontend codebase dealing with presentation and the backend dealing with the business logic. This already requires 2 changes across 2 different codebases to deliver the feature, which is not ideal. Over time, we want more reactive validation, so some of the business logic begins to be duplicated in the frontend. This state of affairs is hardly cohesive and is not conducive to delivering at pace.

What’s wrong with a hypermedia-only approach? The HTML standard has too many limitations. Over the last decade, the industry has evolved an approach to prevent page flashing (the screen going blank after a link has been clicked, before the subsequent page loads). Page flashing feels like a cheap experience to modern-day users of the web. This approach was to build single-page applications (SPAs). In addition, there are challenges in delivering reactive experiences, such as typing in a form input that immediately updates the UI without a page reload. These limitations have led to more advanced frontend tooling – culminating in our current potted ecosystem of more than a dozen SPA frameworks.

Ideally, the HTML standard should be extended and improved. There are features it could have that would vastly reduce the need for JavaScript and, subsequently, the SPA ecosystem. A few tools demonstrate the feasibility of this: HTMX, Hotwire and a few others. These HTML-centric approaches can deliver reactive experiences that are almost entirely server-side, with hypermedia as the engine of the application state, by extending the functionality of the HTML standard. In the public sector, service assessments often ask for progressively enhanced citizen-facing applications that work seamlessly without JavaScript. These HTML-centric technologies make this possible without enormous amounts of engineering effort. Moreover, they are standalone libraries with no dependencies, meaning a team could have one JavaScript dependency and entirely side-step npm vulnerability hell.

Be deliberate with designing teams

Cohesion and team design are very closely related through what is known as Conway’s law. “Any organisation that designs a system (defined broadly) will produce a design whose structure is a copy of the organisation’s communication structure.” This fact has led to techniques such as the “Inverse Conway Manoeuvre,” which aims to solve software architecture design problems by (often radically) changing the organisation structure.

There are similar smells at the programme scale to those on the team scale. For example, how many teams do you need to involve to deliver an outcome? How often are those teams blocking each other from making progress? In an ideal world, a single team can always deliver outcomes within its remit without depending on any other team. In software terms, all the code that needs to be changed for them to be able to deliver is within their control.

Dependencies between teams add management overhead to an overall programme, requiring more roles between teams to keep them aligned and on track. What is often not recognised is that dependencies between teams add extra complexity to codebases because teams are forced to coordinate along the boundary between the code in their control – often through APIs.

A common pattern is to have a frontend team that delivers functionality in a “frontend” codebase, depending on an API built by a backend team. Both teams depend on each other to deliver outcomes, requiring coordination to deliver anything of meaningful value. A slightly improved organisation design might have frontend and backend specialists within feature-aligned teams. These teams share a codebase, so it isn’t perfect, but it will bring together individuals to focus on goals.

Sharing code between feature-aligned teams is not ideal because it still requires careful coordination between them and often leads to scenarios where teams need to agree on the strategic direction of the code design. This gives you the added overhead of needing additional roles to sit between teams and the overhead of making decisions and resolving conflicts that impact both teams.

Keep things simple

The industry has conditioned engineers to believe that everything must be some sort of JavaScript single-page application backed onto a GraphQL API deployed into a serverless function environment with multiple tiers of indirection, including cloud infrastructure glue. This does not have to be the case. I believe that public money is often “accidentally misused” by engineers believing they are doing the right thing by creating vastly overcomplicated solutions, following guidance they found online, for simple problem spaces.

Most digital services in the public sector can be delivered through building humble monoliths using “boring” server-side technologies (e.g. Flask, Sinatra, Rails, Django), ideally by outcome-aligned digital service (product) teams focussed on user needs. These teams can use tried and tested cloud infrastructure features such as containerisation (docker) and relational databases for persistence (PostgreSQL) to side-step every team needing to know the complete A-Z of your cloud provider’s catalogue. It is true that when more complicated approaches appear to be the industry norm, we can collectively forget that there are more straightforward ways to deliver. To escape the default of mediocrity, we must be disciplined and strive for simplicity.

The post Why lots of software projects get messy appeared first on Made Tech.

Behind those services is a wealth of infrastructure and architecture built to support the changing needs of ever-adapting civic services. But how do we make sure what we’re building is fit for the future? This is where AWS Well-Architected can help.

All things AWS Well-Architected

AWS Well-Architected is essentially a best-practice guide for cloud architects. It’s a great way of going through what you’ve built and how your AWS management is set up to make sure you’re doing it in a responsible way that’s also high quality. By following a simple framework, you can make sure you’re effectively reviewing your architecture design. 

The AWS Well-Architected framework documents an approach that allows you to understand if a specific architecture aligns well with current cloud best practices. To support Solution Architects and Chief Technology Officers, the framework gives a consistent approach to evaluating systems against the qualities you expect from modern cloud-based systems. Though this may sound complicated, it’s actually pretty simple. 

The review is built around 6 pillars: 

• operational excellence
• security
• reliability
• performance efficiency
• cost optimisation
• sustainability

These pillars will be familiar to seasoned DevOps engineers and not come as a surprise, but the AWS Well-architected review moves it into the 21st century.

Let’s talk functional and nonfunctional

The review raises the importance of different aspects of your build. It focuses on both the functional features you need to build to make the service work, and also the nonfunctional architecture, where we think about things that will help us if the service goes down suddenly. 

The type of questions it asks the development team to get them thinking more about nonfunctional parts could be:

• do we know if the service is working well? 
• can we recover from disaster? 

This is particularly important, but easily overlooked. When we think of cloud architecture, it’s easy to think only of what we’re building, but we need to make sure we’re giving equal focus to the other supportive stuff too. Leveraging those nonfunctional requirements is crucial and the review is a good way of making sure we’re doing it effectively. 

To give an example, a client we recently worked with provides emergency services to people in the UK. They use digital tools in emergency situations and often have to work quickly. So if the performance of the digital tool is poor or it’s just flat-out broken the business impact is significant.

Through the review, we were able to make sure there were these crucial nonfunctional considerations and solutions in place. It’s very easy to focus on what features your service should have, but the context of the user’s working environment is not always a focus of the architecture leading to performance and reliability becoming a second-class system. The well-architected review helps us shift the focus a bit. 

Benefits of a well-architected review

There are 3 main areas of benefit that I see in reviewing projects using the framework.

Reframing our retros

It’s really useful to have this ongoing technical review. In lots of ways, it’s similar to a retrospective. Often we’re focused on delivering: doing the stuff and getting the features out there in the world and improving ways of working. But this review adds a regular cadence of looking at what we build from a technical, performance, operational or security or perspective and asking penetrating questions.

This retrospective is a practice you actually do over several sessions. And then you record it in the AWS app. You keep track of your notes and the days you made them. You can revisit at any point and say “we were going to do this” or “this was a risk – have we solved it?”.

We don’t always do this type of architecture retrospective, and that’s where AWS Well Architected Review nudges us in the right direction. Asking have we forgotten to do some things or do we need to do more? 

Knowledge sharing

There’s a bit of knowledge sharing in there as well. By doing these retrospectives and talking about what we’ve done and what we haven’t, people in the room can say “oh, I didn’t realise we did that”. Because people move around on projects a lot it’s good to do these check-ins. 

It helps us all think a little bit more through the lens of support, and particularly what operational aspects we may need in place to help the team. It helps us think beyond just building the thing and getting it working. It’s a good thing for our team to do regularly and helps our software engineers to learn best practices for any future projects. 

ROI is crucial

We’d be wrong if we didn’t mention return on investment. Taking on the well-architected review is great for organisations to help their design teams truly deliver a higher quality technical service. And bonus – it’s less likely to fail. Not only that, it also means having a service that’s easier to work on and much better understood by everyone involved. 

Best practice for all 

Ending on a high, what I really like about AWS Well-Architected is that more widely it can be described as best practice for all cloud operations. It takes the best parts of those good old-fashioned cloud ops practices that have been around for a very long time and gets rid of what’s not relevant anymore. 

It’s clear, easy to work through and provides a really great framework for helping us evaluate architectures and implement scalable designs in the public sector. 

If you want to learn more about how we can support you with AWS well-architected, please get in touch. Or if you’d like to learn more about the work we do here at Made Tech you can subscribe to our Made Tech Insights newsletter to get new blog posts straight to your inbox.

The post AWS Well-Architected: building digital services fit for the future appeared first on Made Tech.