In modern Android development, Clean Architecture offers a structured, flexible approach to building applications that are scalable, maintainable and testable. The Data Layer plays an important role in abstracting the complexities of networking, databases, and caching, ensuring that the Domain & Presentation Layer remain agnostic to the underlying data sources.

🔗 Our previous discussion on the Domain Layer outlines the principles this article will build upon. Here, we’ll examine the structure of the Data Layer, exploring its key components, outline best practices for implementation, and discuss how to effectively integrate it into your Android projects.

What is the Data Layer?

The Data Layer is in charge of all the behind the scenes work when it comes to handling data in the application. Whether it’s fetching from a remote API, reading from a local database, or managing an in-memory cache, this layer does the heavy lifting. Its job is to provide data in a consistent way so the rest of the app doesn’t have to worry about where it came from or how it was stored.

In Clean Architecture, a key rule is that the Data Layer shouldn’t be accessed directly by the Presentation Layer (like ViewModels or UI components). Instead, it talks only to the Domain Layer, which defines the business rules that the application relies on. This separation keeps things modular and flexible, so if you ever need to switch remote APIs or change the storage setup, you can do it without affecting the rest of the application.

Anatomy of the Data Layer

Data Sources

Define how data is retrieved, whether from remote APIs, databases, or in-memory caches. They are often categorised into RemoteDataSources and LocalDataSources.

Repositories

Serve as the entry point for data access, acting as the interface between the Data Layer and the Domain Layer. Repositories orchestrate data from remote or local Data Sources.

Remote API Interfaces

Define the contract for network communication. They specify HTTP methods (like @GET, @POST), endpoint paths, query/path parameters, headers, and the expected response models. This ensures consistent and type safe interaction with remote APIs.

Database Access Objects (DAOs)

Provide an abstraction layer over the database. They define the SQL queries and data operations used to perform CRUD actions (Create, Read, Update, and Delete).

Data Transfer Objects (DTOs)

Are structured representations of external data like REST API responses.

Entities

Are database representations that directly map to tables. They define the schema of the database.

Mappers

Transform data between DTOs, Entities, and Domain Models. Mappers are necessary to avoid direct dependencies between the Data and Domain Layers.

Key Responsibilities of the Data Layer

✅ Fetching, Persisting and Caching Data
The Data Layer handles CRUD operations from remote data sources such as REST APIs, and can persist data locally using tools like Room (for databases), DataStore (for key-value pairs), or in-memory caching (for temporary data) when needed.

✅ Handling Network Responses
The Data Layer processes and validates network responses. It ensures data from external sources like REST APIs is valid, complete, and in the correct format before it is passed on to the Domain Layer.

✅ Retry Logic & Failure Handling
The Data Layer handles unreliable network conditions by implementing retry strategies like exponential back-off and gracefully managing failures to avoid disrupting the user experience.

✅ Logging & Error Reporting
When operations fail, capturing those failures at the source is important. The Data Layer should log exceptions and optionally report them using crash reporting tools for easier debugging and analysis.

✅ Threading
Libraries like Retrofit, Room, and DataStore automatically handle threading when using Coroutines, ensuring data operations do not block the main thread. If using a different library the responsibility of switching threads for I/O work belongs to the Data Layer.

✅ Mapping DTOs & Entities to Domain Models
Transforming raw data (like REST API responses or database entities) into usable domain models is a key responsibility of this layer. This separation helps maintain a clear boundary between external data formats and the applications business logic.

✅ Ensuring Data Consistency
Data Sources should return immutable data to ensure consistency and prevent race conditions or data corruption. Immutable data guarantees that the data passed to the higher layers of the application is reliable.

✅ Data Security & Privacy
While security is a shared responsibility across layers, the Data Layer plays an important role. Whether encrypting local storage or ensuring secure data transmission over the network, this layer helps protect user data and privacy.

❌ Should Not Contain Business Logic
The Data Layer focuses on data management, not decision making. Business logic should reside within the Domain Layer to maintain separation of concerns and maintainability.

❌ Should Not Be Accessed Directly by the Presentation Layer
Access to the Data Layer is restricted via the Domain Layer to ensure business logic is consistently applied and to prevent inconsistent Data Layer access throughout the application.

💡 In smaller projects where a Domain Layer is omitted, this boundary might be more relaxed. But in scalable apps, adhering to this separation leads to a more maintainable code base.

Repository Pattern in Clean Architecture

Repositories act as the middle layer between the Domain Layer and Data Sources (like REST APIs or local databases). Their job is to expose a stable, domain focused interface that hides the underlying complexity of how and where data is fetched or stored.

Typically they do not handle mapping, threading, or low level error handling. Those concerns live in the remote and local Data Source classes. However, if your application doesn’t use Data Source classes (smaller projects) it’s acceptable for the Repository to take on these responsibilities. Repositories focus on orchestrating data between sources (remote & local), and deciding how to combine or prioritise data before returning the result to the Domain Layer.

1. Naming Repositories

Repositories should follow the format:

[Type of Data] + Repository

For example:
✅ BagRepository
✅ CheckoutRepository

2. Key Responsibilities of Repositories

✅ Data Orchestration
Repositories coordinate between multiple data sources. For example, fetching from local cache first and falling back to remote if needed (or vice-versa). They decide where to get the data from, not how to get it.

✅ Return Domain Models
Repositories always expose Domain Models to the Domain Layer. Any mapping from DTOs or database Entities happens in the remote or local Data Source classes. If your application omits Data Source classes the Repository can take on the responsibility of mapping.

✅ Main Thread Safety
Repositories shouldn’t perform long running operations on the main thread. But they also shouldn’t be responsible for threading. If thread shifting is required that responsibility belongs to the Data Source performing the operation. If your application omits Data Source classes, it’s acceptable for the Repository to handle threading.

❌ Contain Business Logic
Business logic belongs in the Domain Layer (Use Cases). Repositories are responsible for data orchestration, not decision making about how data should be used.

❌ Depend on Use Cases
This creates a circular dependency between the Data and Domain layers. Instead, let the Use Case gather all the required inputs before calling the Repository.

❌ Depend on Other Repositories
Repositories should not depend on other Repositories. Each Repository is responsible for handling a specific Data Source or data type. Introducing cross-repository dependencies leads to tight coupling. If you need data from multiple sources, aggregate it in a Use Case in the Domain Layer.

3. Caching in Repositories

Repositories are a good place to trigger caching, as long as no business logic needs to be applied before the data is stored. If a REST API response is directly cache-able, the Repository should store it immediately after retrieval.

internal class NavigationRepositoryImpl @Inject constructor(
    private val navigationRemoteDataSource: NavigationRemoteDataSource, // interface
    private val navigationLocalDataSource: NavigationLocalDataSource, // interface
) : NavigationRepository {

    override suspend fun getNavigationApi(): Result<Unit> {
        return when (val result = navigationRemoteDataSource.getNavigationApi()) {
            is Result.Success -> insertNavigationToCache(result.data)
            is Result.Error -> Result.Error(result.error)
        }
    }

    private suspend fun insertNavigationToCache(navigationModel: NavigationModel): Result<Unit> {
        return when (val result = navigationLocalDataSource.insert(navigationModel) {
            is Result.Success -> Result.Success(Unit)
            is Result.Error -> Result.Error(result.error)
        }
    }
    
}

In this example, the Repository delegates both the remote fetch and the cache insert to their respective Data Sources. It doesn’t handle how those operations are done, only when and in what order they occur.

Processing Data Before Caching

If the data needs to be transformed, validated, or amended before being cached. For example, if business logic determines which parts of the data to store or if it must be combined with another source, then that work should happen in the Domain Layer, inside a Use Case.

Let the Use Case perform the necessary transformations, then pass the final, domain result back to the Repository to be persisted. This keeps business logic out of the Data Layer and ensures a separation of concerns.

Caching Strategies

Caching is a key part of the Data Layer, but there’s no one-size-fits-all approach. Your strategy should depend on how fresh the data needs to be. For example, static content like app settings benefits from caching, while real time data (e.g. shopping carts, stock levels) should not be cached to avoid serving outdated information. 🔗 See the official Android Developers documentation for a comprehensive look at caching strategies in Android.

4. Multiple Repositories & Dependency Aggregation

Repositories should not contain business logic or inter-repository communication. Allowing Repositories to directly communicate with each other can lead to a tight coupling. If you need to aggregate data from multiple Repositories utilise a Use Case.

Why Use Cases Aggregate Data
When a screen or feature needs data from more than one source, the Use Case knows how to coordinate those calls, apply any business logic, and return the result in a way that makes sense to the Presentation Layer. This keeps the architecture modular and easier to maintain as the application grows.

❌ Incorrect Example: Aggregating Data in a Repository

internal class StockRepositoryImpl @Inject constructor(
    private val pricingRepository: PricingRepository, // ❌ Cross-repository dependency
    private val stockRemoteDataSource: StockRemoteDataSource
) : StockRepository {

    override suspend fun getStockSummary(productId: String): StockSummary {
        val price = pricingRepository.getPriceForProduct(productId) // ❌ Unrelated to stock
        val stockLevel = stockRemoteDataSource.getStockLevel(productId)
        return StockSummary(productId, stockLevel, price)
    }
}

Why is this incorrect?

❌ Violates the Single Responsibility Principle (SRP)
The Repository is now responsible for fetching stock and price data, which introduces unnecessary coupling.

❌ Tightly Couples Repositories
If PricingRepository changes, StockRepository might need modifications, even though it’s unrelated to pricing data.

❌ Increases Test Complexity
Unit tests for StockRepository now need to mock or fake the PricingRepository, making testing more cumbersome.

✅ Correct Example : Aggregate Data in the Use Case
The correct approach is to let Repositories focus on their own data concerns and move any coordination or transformation logic into a Use Case.

internal class GetStockSummaryUseCase @Inject constructor(
    private val pricingRepository: PricingRepository, // interface
    private val stockRepository: StockRepository // interface
) {
    suspend operator fun invoke(productId: String): StockSummary {
        val price = pricingRepository.getPriceForProduct(productId)
        val stockLevel = stockRepository.getStockLevel(productId)
        return StockSummary(productId, stockLevel, price)
        // ✅ Keeps responsibilities clearly separated
    }
}

Why is this correct?

✅ Repositories stay independent
Each repository does one thing (stock or pricing), and doesn’t depend on the other.

✅ The Use Case Handles Coordination
The GetStockSummaryUseCase orchestrates the data from both Repositories, applies any business rules (if needed), and returns the final result to the Presentation Layer.

✅ Easier to Test and Maintain
Repositories are easier to test in isolation, and changes in pricing logic won’t impact the StockRepository.

🔗 Checkout the previous article in the series for a deep dive on the Domain Layer and Use Cases.

Understanding Data Sources

1. What is a Data Source?

A Data Source is responsible for accessing and managing data from a specific location, whether that’s over the network, on local storage, or from an in-memory cache. It abstracts the details of how that data is retrieved or persisted, offering a focused interface for performing CRUD operations.

Data Sources also handle data transformation, mapping raw responses (such as DTOs or database entities) into domain friendly models before passing them downstream.

💡 If your architecture doesn’t use explicit Data Source classes, then mapping and transformation work will usually shift into the Repository. While that can work for smaller apps, having separate Data Source classes offers clearer boundaries and better scalability.

2. Types of Data Sources

There are typically two main types of Data Sources

Remote Data Sources
Handle communication with remote APIs. They’re responsible for sending requests, parsing responses, and mapping API results into domain models.

Local Data Sources
Manage access to on-device storage, such as databases, file systems, or preference stores. These sources handle local persistence, and typically use tools like Room or DataStore.

3. How to Structure Data Sources

Each Data Source should focus on a single data entity. For example, a UserRemoteDataSourceImpl would work with a UserDto, while a UserLocalDataSourceImpl would handle a UserEntity from Room.

While it’s ideal to separate by storage type (e.g. Room vs. DataStore), it’s also perfectly valid to combine them behind a single local data source interface, as long as the responsibilities stay cohesive and the Repository isn’t exposed to the underlying storage details.

4. Naming Data Sources

Data Source naming should follow the format:

[Type of Data] + [type of source] + DataSource

Examples:
✅ BagRemoteDataSource
✅ CheckoutLocalDataSource

🚫 Avoid implementation specific interface names
(e.g. BagSharedPreferencesDataSource). Repositories should not be aware of the underlying storage mechanism, allowing for flexibility in future changes.

Best Practices for Implementing Data Sources

1. Separation of Concerns

A Data Source should never be accessed directly by other layers of your application, such as Use Cases or ViewModels. Instead, all data flows through a Repository, which serves as a bridge between the Data Sources and the Domain Layer.

Keeping Data Sources behind interfaces gives you the flexibility to swap out storage mechanisms or REST APIs without impacting the rest of the application. For example, switching from Firebase to a REST API or from Room to DataStore should require no changes outside of the Data Source Implementation class. It also facilitates easier testing by allowing us to swap out the real implementations for test fakes.

2. Mapping

Mapping between DTOs, Entities, and Domain Models is necessary for maintaining separation of concerns and avoiding tight coupling between layers.

Where Should Mapping Happen?
Mapping should ideally occur inside the Data Source classes. This ensures that by the time data reaches the Repository, it’s already in Domain Model form. This keeps Repositories focused purely on orchestration.

If your project doesn’t have explicit Data Source classes, it’s acceptable for the Repository to take on this responsibility. If your Repositories become bloated and complex, consider moving the mapping logic to the Data Source.

How Should You Map?
There are two standard approaches to mapping:

• Use a dedicated mapper class
• Use a Kotlin extension function

Which One Should You Choose?

• If the mapper has dependencies use a stand alone mapper class.
• If the mapper has no dependencies use an Kotlin extension function.

Mapping Extension Functions
When using extension functions for mapping, place them in a clearly named Kotlin file such as UserMappingExtensionFunctions.kt, located in the /data/mapper package. This file contains mapping functions between a UserDto, UserModel & UserEntity. These functions must be unit tested, just like standalone mappers. Create a corresponding test class alongside them.

// Example of a Kotlin extension mapping function
fun UserDto.toDomain() = User(
    id = this.id,
    name = this.name,
    email = this.email
)

// Example of a stand alone mapper class
class UserDtoToDomainMapper @Inject constructor() {
    fun map(dto: UserDto): User {
        return User(
            id = dto.id,
            name = dto.name,
            email = dto.email
        )
    }
}

💡 Avoid using default values to mask missing data (e.g. empty strings or zero values) unless you’re intentionally handling optional fields. Failing silently can lead to hard-to-trace bugs in the UI or Domain Layer.

3. Error Handling & Logging

Data Sources are the right place to catch and log exceptions. However, they should never expose raw exceptions to the Repository or Domain Layer. Instead, they should map those exceptions to domain friendly error types.

This allows the Repository to pass structured, meaningful error information to the Presentation Layer, which can then respond in ways that improve the user experience. For example, showing an error message, disabling a button, or triggering a retry.

The key principle here is that raw exceptions like HTTP error codes should never be exposed directly to the Domain or Presentation Layers. Instead, exceptions should be mapped to specific error types that make sense in the domain of the application.

Using a Custom Result Class
We use a custom sealed interface called BagResult to represent the outcome of an operation. This helps to unify the way we handle both success and failure.

// Example of a custom Result class
sealed interface BagResult {
    data class Success(val data: Bag) : BagResult
    data class Error(val error: BagError) : BagResult
}

• Success: Contains the data returned from the operation (from a REST API call or database query).
• Error: Contains a BagError, which is a domain friendly class containing predefined errors that could happen when interaction with the Bag API.

The BagResult class allows us to handle both the success and failure of an operation in a consistent manner, simplifying error propagation through different layers of the app.

Mapping to Domain Specific Error Types
To keep error handling at the data layer clear and domain focused, we use a enum class to define error types. Here’s an example of how we define a custom error class for handling different types of errors related to a shopping bag REST API.

enum class BagError {
    NetworkError,
    InvalidRequest,
    Unauthorized,
    Forbidden,
    NotFound,
    InternalServerError,
    UndefinedError
    // additional cases can be added...
}

The BagError enum captures specific error conditions that might occur in the context of fetching or managing bag data. The benefit of using such an approach is that we can clearly differentiate between various types of errors (e.g. network issues, invalid requests, or server errors). This makes it easier to respond to errors appropriately in the UI, like showing relevant error messages, redirecting the user to the login screen etc.

In this case, we use a BagErrorMapper.kt with a top level function to map raw exceptions to domain specific error type:

internal fun mapToBagError(exception: Throwable): BagError {
    return when (exception) {
        is IOException -> BagError.NetworkError
        is HttpException -> mapHttpErrorCode(exception)
        else -> BagError.UndefinedError
    }
    
    private fun mapHttpErrorCode(exception: HttpException): BagError {
        return when (exception.code()) {
            400 -> BagError.InvalidRequest
            401 -> BagError.Unauthorized
            403 -> BagError.Forbidden
            404 -> BagError.NotFound
            in 500..599 -> BagError.InternalServerError
            else -> BagError.UndefinedError
        }
    }
}

By handling errors at the Data Source level, we:
✅ Ensure consistency by logging errors at the point of failure.
✅ Provide meaningful errors to the Domain & Presentation layers.
✅ Predictable error types facilitates easier testing.
✅ Avoid redundant logging across multiple Repositories.
✅ Keep Repositories focused on orchestration.

CancellationException Handling

⚠️ Important: If using runCatching, ensure that you explicitly rethrow CancellationExceptions. If a Coroutine is cancelled due to a timeout or job cancellation, it should propagate downstream instead of being swallowed. Failing to do so can lead to unexpected behavior such as infinite loading states or unresponsive UIs.

We use a helper function to automatically re-throw the CancellationException.

suspend fun <R> runSuspendCatching(block: suspend () -> R): Result<R> {
    return try {
        Result.success(block())
    } catch(c: CancellationException) {
        throw c
    } catch (e: Throwable) {
        Result.failure(e)
    }
}

4. Dependency Injection

Use standard constructor injection for any Data Source that’s required immediately. If the Data Source is optional or rarely used (a cache that’s only hit in certain flows), you can use lazy injection. This defers instantiation until it’s actually needed, which helps reduce memory usage and improve app startup time.

5. Threading

In Coroutines, libraries like Retrofit, Ktor, Room & DataStore internally use Dispatchers.IO for network/disk operations so it’s not necessary to manually switch threads. However, if you’re reading/writing from local storage files or any other custom storage solution you will need to manually switch to a background thread using Dispatcher.IO in the DataSouce class before the operation occurs.

Implementing Remote Data Sources

Remote Data Sources handle communication with remote sources, most commonly REST APIs. Libraries like Retrofit or Ktor are commonly used to handle network requests. Each Remote Data Source should define an interface that specifies how it interacts with the REST API.

1. Naming REST API Interfaces

REST API interfaces should follow the format:

[Feature] + Api

Examples:
✅ BagApi
✅ CheckoutApi

interface BagApi {
    @GET("bags/{bagId}")
    suspend fun getBagByBagId(
        @Path("bagId") bagId: String,
    ): BagDto
}

2. ❌ Incorrect Example of a Remote Data Source

Here is a Remote Data Source implementation that violates Clean Architecture boundaries and introduces unnecessary complexity.

internal class BagRemoteDataSourceImpl @Inject constructor(
    private val bagApi: BagApi, // interface
    private val bagDtoToDomainMapper: BagDtoToDomainMapper,
    private val userRepository: UserRepository, // ❌ Not allowed
    @IODispatcher private val ioDispatcher: CoroutineDispatcher // ❌ Unnecessary
) : BagRemoteDataSource {

    override suspend fun getBag(): BagResult<Bag> {
      return withContext(ioDispatcher) { // ❌ Retrofit handles threading internally
          runCatching { // ❌ Use runSuspendCatching to auto rethrow CancellationExceptions
            bagApi.getBag(userRepository.getUserId()) // ❌ User id should be passed in getBag()
          }.fold(
              onSuccess = { result ->
                  BagResult.Success(bagDtoToDomainMapper.map(result)) // ❌ Any malfomed json errors may crash the app
              }
          },
              onFailure = { exception ->
                  val bagError = mapToBagError(exception) 
                  // ❌ No error logging to crash reporting tools
                  BagResult.Error(bagError) 
              }
           )
        }
    }
}

Why is this incorrect?

❌ Circular Dependency
The Data Source is depending on a Repository (UserRepository). This breaks the unidirectional data flow and creates a circular dependency. Values like the user id should be retrieved by the Domain Layer and passed as parameters.

❌ Unnecessary Thread Management
An explicit CoroutineDispatcher is injected and used via withContext. This is unnecessary when using Retrofit with Coroutines, as Retrofit already handles network calls off the main thread.

❌ No Error Logging
It’s important that we log errors using crash reporting tools so we can monitor REST API’s in production.

❌ Mapping Errors Not Caught
Any NullPointerExceptions thrown during mapping due to malformed JSON will crash the app as the mapping occurs outside of the runCatching. An example of this could be an issue with the contract not being honoured and returning different data than expected.

❌ Using runCatching
It’s preferable to use the runSuspendCatching helper function mentioned above as this will re-throw CancellationExceptions for you, negating the need for developers to remember to do this manually.

3. ✅ Correct Example of a Remote Data Source

The following version respects the principles of Clean Architecture and avoids anti-patterns.

internal class BagRemoteDataSourceImpl @Inject constructor(
    private val bagApi: BagApi, // interface
    private val crashLogger: CrashLogger, // interface
    private val eventLogger: EventLogger, // interface
    private val bagDtoToDomainMapper: BagDtoToDomainMapper
) : BagRemoteDataSource {

    override suspend fun getBag(userId: String): BagResult<Bag> { // ✅ User id passed as a param
      return runSuspendCatching { // ✅ runSuspendCatching re-throws CancellationExceptions
          val result = bagApi.getBag(userId) // ✅ No thread switching
          bagDtoToDomainMapper.map(result) // ✅ Map in the runSuspendCatching to catch malformed json
        }.fold(
            onSuccess = { mappedResult ->
                BagResult.Success(mappedResult)
            }
        },
            onFailure = { exception ->
                val bagError = mapToBagError(exception) // ✅ Use mapper function to convert raw throwable to domain error type
                logError(exception, bagError) // ✅ Log exceptions
                BagResult.Error(bagError) 
            }
        )
    }

    private fun logError(
        exception: Throwable, 
        bagError: BagError
    ) {
        Log.e(this.javaClass.simpleName, exception.message.toString())
        crashLogger.logException(exception)
        
        eventLogger.logEvent(
            eventAttributes = mapOf(
                NAME to bagError.name,
                DESCRIPTION to exception.message.orEmpty()
            )
        )
    }
}

Why is this correct?

✅ No Circular Dependencies
The user id is passed as a parameter rather than fetched from a Repository which violates Clean Architecture principles. This keeps the Data Source free of business logic and external dependencies.

✅ Threading Delegation
Threading is delegated to and managed internally by Retrofit, removing the need to inject a dispatcher or switch threads manually. This simplifies the setup and testing.

✅ Mapping
The DTO is converted to a domain model before the result is returned to the Repository.

✅ Error Logging
Errors are logged at the source and mapped to domain specific types allowing monitoring in production. Logging tools are abstracted through decoupled interfaces. This makes the implementation easy to test and replace if logging tools change in the future.

✅ Uses runSuspendCatching
Using runSuspendCatching re-throws CancellationExceptions for us automatically and preserves structured concurrency.

Implementing Local Data Sources

Local Data Sources are responsible for interacting with data stored on the device. They follow the same Clean Architectural structure as Remote Data Sources but instead interact with local storage mechanisms such as databases, files, or key-value stores.

1. Storage Options

The choice of local storage depends on the type of data and how it will be accessed:

• Room / SQLDelight
  Use a database when your data is structured, relational, and requires long-term persistence. Databases allow complex queries like joins, filters, and transactions.
• DataStore
  DataStore is the modern, Coroutine backed replacement for SharedPreferences. It is best suited for small sets of data like user settings, flags, or preferences that do not require complex querying.
• Files (JSON, CSV, XML, etc)
  Files are suitable for configuration settings, logs, or exportable data that don’t require querying.
• In-memory Cache
  This is temporary storage for frequently accessed data objects that do not expect to persist if the app is killed or restarted.

⚠️ Be cautious with in-memory caches. If the app is placed in the background and a process death occurs, the system may kill the process to reclaim resources. When the user returns to the app, it will attempt to restore the previous state, but the in-memory cache will have been cleared. This can result in unintended UI states & crashes.

2. Naming DAO Interfaces

When using a database like Room, a DAO is where you define how the app interacts with the local tables (inserts, queries, deletes, etc).

DAO interface naming should follow the format:

[Type of Data] + Dao

Examples:
✅ NavigationDao
✅ SearchHistoryDao

@Dao
interface NavigationDao {

    @Query("SELECT * FROM navigation WHERE id = :id")
    suspend fun getNavigation(id: String): NavigationEntity?

    @Insert(onConflict = OnConflictStrategy.REPLACE) // replaces duplicate entries
    suspend fun insertNavigation(navigation: NavigationEntity)

    @Delete
    suspend fun deleteNavigation(navigation: NavigationEntity)
}

💡 DAO methods using suspend functions automatically run on a background thread thanks to Room’s Coroutine support, so you don’t need to explicitly manage threading.

3. Local Data Source Example

Local and Remote Data Sources share a similar structure: dependency injection, error handling, result wrapping, and mapping to domain models. For these shared patterns, refer to the Remote Data Source section above. The key difference is that instead of injecting a REST API interface, you inject the DAO interface when using Room, or an appropriate interface when working with DataStore or other local storage mechanisms.

Understanding Data Layer Models

In the Data Layer, two primary types of models are used:

• DTOs represent REST API response models. They should remain immutable and map closely to the REST API response.
• Entities represent database tables and persist data within the local database. They are typically annotated with @Entity when using Room. 🔗 See the official Room documentation for more details on structuring Entities.

1. Naming Data Models

Data models should follow the format:

[Type of Data] + Dto/Entity

For example:
✅ NavigationDto
✅ NavigationEntity

2. Best Practices for DTOs

✅ Immutable Data Classes
Make DTOs immutable by using val properties only. This helps avoid accidental changes and keeps your data consistent.

✅ Nullability Handling
Match the nullability of DTO properties to the REST API specification. Handle any nulls during mapping to avoid crashes later in the app.

✅ Mappers for Transformation
Use a dedicated mapper to transform DTOs to Entities or Domain Models. This ensures that no unnecessary REST API details leak into the other layers.

✅ Serialization & Field Mapping
If your JSON field names differ from your Kotlin property names, use the @SerialName annotation from Kotlin Serialization. Kotlin Serialization is preferred over Gson due to its better performance and native Kotlin support.

⚠️ Keep in mind that @SerialName helps prevent property obfuscation when using tools like R8.

✅ Avoid API-Specific Fields
Exclude any API metadata fields such as status codes or timestamps that aren’t needed. Keep DTOs focused only on the data required.

✅ Separation of Concerns
DTOs should focus only on data representation. Avoid embedding business logic or including mapping functions within DTO classes.

import kotlinx.serialization.SerialName
import kotlinx.serialization.Serializable

@Serializable
data class NavigationDto(
    @SerialName("navigation_id") 
    val id: String?,
    @SerialName("navigation_title") 
    val title: String?,
    @SerialName("navigation_url") 
    val url: String?
)

Package Structure

Below is an example of how the Data Layer can be structured. This is a simple representation and could change in a modularised app.

📂 data
 ├── 📂 local
 │    ├── BagDao.kt
 │    ├── BagEntity.kt
 │    ├── BagEntityMapper.kt
 │    ├── BagLocalDataSourceImpl.kt
 │
 ├── 📂 remote
 │    ├── BagApi.kt
 │    ├── BagDto.kt
 │    ├── BagErrorMapper.kt
 │    ├── BagDtoMapper.kt
 │    ├── BagRemoteDataSourceImpl.kt
 │
 ├── 📂 repository
 │    ├── BagLocalDataSource.kt  // interface
 │    ├── BagRemoteDataSource.kt. // interface
 │    ├── BagRepositoryImpl.kt

📂 domain
 ├── 📂 repository
 │    ├── BagRepository.kt // interface

Conclusion

A well-structured Data Layer built with Clean Architecture does more than organise your code. It sets the stage for scalability, testability, and long-term maintainability. By separating data management from business and presentation logic through Data Sources and Repositories, you create an architecture that’s easier to evolve. With solid practices like dependency injection, proper mapping, threading, and error handling, your Data Layer becomes a strong foundation your app can confidently grow on.

I’m Sean Coyle and I joined the ASOS Android team in August 2022. I started my career in Android development in 2019. Before that, I was a social worker and spent a few years teaching English in Japan.

Android Clean Architecture: Understanding the Data Layer was originally published in ASOS Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the coding sphere, technology is sprinting at a breakneck pace, with new LLM-driven capabilities debuting nearly every day. When it comes to software development, the nirvana — “software developing software” — has shifted from fantasy to a realistic proposition. We are in the eye of a genuine paradigm shift in how we deliver products.

But revolutionary changes are rarely clean. And this one is not without its challenges and a sea of sceptical voices questioning its viability.

In this piece, I’ll share how we’ve experimented with adapting this incredible, if disruptive, technology into our software development lifecycle in a way that limits some of the common pitfalls accompanying agentic LLMs in real-world enterprise-level product builds. Along the way, I’ll recount a few humbling lessons and observations from our journey close to the edge of this exciting frontier.

Vibing Coding

In the beginning of 2025, AI researcher Andrej Karpathy coined the term vibe coding to describe the process where, “developers primarily use natural language prompts — speaking or typing in plain language — to instruct AI tools to generate, refine, and debug code.” In this approach, users focus on what they want (the “vibe”) while letting the AI handle the code implementation.[1]

Below is a diagram illustrating the vibe coding cycle:

There are challenges with vibe coding. These include managing the quality of code due to hallucinations, missing defects buried deep in the code which can become a costly fix later on, or the agentic tool developing insecure code.

LLM limitations

When I first tried using an AI agent to develop code, my experience matched these widely documented concerns. Plenty of vibe coding energy but not much rigour. But coming from a quality engineering background, I could see that this was fundamentally a quality problem, be it in process, prompting, or AI output.

Whenever I approach a new project, I start with the solution architecture to gain a better grasp of what I’m dealing with. And so here too, I turned to the LLM’s own architecture.

LLMs are built on the transformer model. While the responses of LLMs are often mind-bendingly impressive, at their core, these systems are fundamentally probabilistic pattern-recognition engines. At the basic level, they ingest words (tokens) and predict the next token by assigning probabilities to a sequence of words to generate the output.[2]

A major challenge with this architecture is attention management: how the model decides which words in the input deserve focus when working out what words to use in the generated output. The probability function used in this process (softmax)[3] is intrinsically unable to handle large complex sentences as the “attention” becomes too thinly spread.[4] This means that accuracy declines as the context increases and the attention diffuses.

Agents have strategies to mitigate this limitation, but the takeaway was clear. To help the AI agent maintain its accuracy, it would make sense to employ fewer, more atomic tasks for a single instruction prompt.

Given this insight, I felt a part of the solution wasn’t to shoehorn the AI agent into the existing software development lifecycle or remain bound by vibe coding, but to rethink the lifecycle in a way that factored the LLM’s inherent constraints.[5]

Test-Driven Vibe Development (TDVD)

The concerns with vibe coding can be addressed by fusing the mature test-first quality engineering practices, which we have already established here at ASOS, with vibe coding. The result is Test-Driven Vibe Development (TDVD): a restructuring of the classic Vibe Coding process that integrates the discipline of established test-first quality engineering practices with the useful aspects of the vibe coding AI paradigm:

· Architecture driven testing to form a highly relevant test strategy.[6]

· ATDD to establish quality-refined acceptance criteria/test scenarios.

· BDD for consistent domain language expression.

· TDD to front load the tests in the implementation phase.

In TDVD, natural language prompts drive the definition of the expected behaviour of the solution upfront through acceptance criteria or tests. This test-first, intent-driven approach ensures that:

· Clear testable requirements as code are generated before functional implementation.

· Code generation is aligned with testable requirements.

· AI-generated implementations are continuously validated against those requirements.

· Bugs and hallucinations are caught early, before they become costly.

· Security and quality risks are managed proactively.

In short, TDVD inverts the current (vibe coding) development lifecycle approach, which sees the functional code generated first before testing occurs. It creates a flow from intent → specification → test → code → validation → deployment.

The activities within the TDVD flow fall within three broad categories.

· Plan — defining the intent in a test-first manner

· Implement — developing the intent in a test first manner.

· Harden — final layer of deepening functional and non-functional test depth.

The Trial

From May through to June, I fleshed out details of a potential TDVD lifecycle and built out supporting prompts. With the framework in place, the next step was finding a a low-risk candidate for a real-world test.

The chosen candidate was an internal reporting solution that calculated stock discrepancies based on stock movement transactions. Although it could indicate a misalignment, it was unable to show what was missing or why, resulting in time-consuming manual investigations and delays in resolving physical versus system stock discrepancies.

What was needed was a solution that could precisely identify and report missing or mismatched stock transactions by comparing actual physical stock position in our warehouse management systems and stock reconciliation records in an automated manner. The solution would enable earlier discrepancy detection, proactive alerting, reduced reliance on manual investigations, faster resolution of stock mismatches, better accountability, and improved stock accuracy for downstream consumers.

The team had several constraints: an engineering lead already juggling multiple commitments, a single part-time senior developer, no frontend expertise, and no dedicated product manager.

Still, I kicked off the trial with the brilliantly forward-thinking Engineering Lead, Caroline Perryman, and the ever-adaptive Senior Developer Cian Moloney. Together we set out to push the limits of what was possible with this vibe-infused, quality first lifecycle model in an environment that was anything but conducive.[7]

Findings

The MVP we set out to build consisted of the following:

· A backend comprising an API, Azure Functions for data handling, timed triggers, and discrepancy calculation logic, and two data stores.

· A React-based frontend report with three views, each supporting search and dynamic filtering capabilities, plus a notes modal

· Standard essentials: authorisation, authentication, and logging.

Initial estimates for a team of developers to build an MVP was between 4–6 months — 3–4 months for the backend and 2–3 for the frontend.

With Caroline, Cian (at 50% availability), and myself, we delivered the MVP plus some nice-to-have capabilities (an additional File Detail View, which provided a detailed drill-down view showing comprehensive file-level metadata and SKU-level discrepancy data, and a report export feature) in 4 weeks.

During this period, we rebuilt approximately 80% of the MVP twice to refine our prompts so that they achieved higher-quality outputs.

If we exclude the two tear downs and combine the Planning and the actual Implement phases, the total time active development time was 42 hours or 11 workdays.[8]

The results are positive. We were 7–10 times faster than the original MVP estimate and we also delivered extra capabilities, all with a team effectively consisting of two and a half people.

Of course, it must be stressed that the original estimate was based on the team’s lack of experience in the technology stack. Another team might have quoted something leaner. Even so, within our context and constraints, the acceleration was undeniable.

Lessons

TDVD combines some of the fluidity, speed, and creativity of Vibe Coding with the discipline of a test-first blueprint, and guardrails attuned to the LLM’s architecture. Our experiment proved the concept has legs, but the journey wasn’t exactly smooth sailing.

We tore down the solution and rebuilt it twice even though we got it working each time. Why? Our features were not small enough and, consequently, not iterative enough. We failed to maintain the LLM’s context between lengthy prompt phases. We adapted by revising our PRD by breaking the capability features down into much smaller user stories, and rebuilding our implementation step guides so that each cycle focused on no more than two features. We also introduced implementation summaries using our own custom prompt to provide continuity for subsequent implementation phases.

Other niggles included the agent building out tests and the associated code, but not executing the tests, which resulted in mounting technical debt. At other times, the agent confidently claimed it had completed a revision or fix but left failing tests unresolved. The solution was what any good TDDer would do in this situation. We prompted the AI to never proceed to the next task step until all tests passed.

On the specificity of instructions, we discovered a curious trade-off. Slightly more vague instructions gave the AI room for creative assumptions. For example, when asked to “add a page,” it not only built the page but updated the navigation bar too. Overly precise instructions, on the other hand, killed that initiative. When we sharpened the prompt and told the agent exactly how to add the page, it did so, but didn’t update the navigation bar.

Finally, it pays (premium request!) dividends to really think about the dependencies. Before starting the Implement phase of TDVD, it’s worth ensuring the skeleton solution includes all the prerequisites and installations already. Failing to consider this or failing to guide the agent on handling missing dependencies will result in token-draining technical debt and rework.

Final thoughts and next steps

Perhaps the most radical of all observations weren’t about the AI. They concerned us humans in the experiment.

First, the obstacles to delivery. The biggest time sink wasn’t necessarily the code generation. It was the infrastructure plumbing. Chasing down people for access and configuration cost us several days of development time. This is an area which could do with increased automation and perhaps some “agentic” attention to accelerate delivery further.

Second, rapid skill acquisition and augmentation. We started as backend specialists and walked out having built a full stack solution with technologies we had never touched before the trial.

Third, roles in the TDVD lifecycle. I wanted to push the boundaries of the experiment and from the outset stipulated that we were not assuming fixed roles. The results were both surreal and empowering at the same time:

· Caroline shifted between product manager, systems specialist, solutions architect, and a tech lead.

· Cian assumed the roles of a solution architect and platform engineer, while vibe coding and testing chunks of both the backend and frontend solution.

· I designed, orchestrated, and continually revised the TDVD development process, helped Caroline define the product, designed the solution, and coded and tested portions of the full stack implementation.

We mobbed, we swapped roles, and we blurred boundaries beyond our specialisms. The dynamism in the teamwork was on a higher plane, an organic outcome of the TDVD flow.

So, what does this all mean? Well, it’s an exciting time to be involved in software engineering, for sure. But more significantly, early signs suggest TDVD might just be the recipe for stable, quality-infused, yet rapid product delivery.

Or, to put it less formally: the vibe is strong with this one.

Citations:

[1] Google. “Vibe Coding Explained: Tools and Guides.” Google Cloud, 2025, cloud.google.com/discover/what-is-vibe-coding.

[2] For a useful and easy to digest overview, see: Google. “Introduction to Large Language Models | Machine Learning.” Google for Developers, 8 Aug. 2023, developers.google.com/machine-learning/resources/intro-llms.

[3] https://en.wikipedia.org/wiki/Softmax_function

[4] Veličković, Petar, et al. “Softmax Is Not Enough (for Sharp Out-of-Distribution).” ArXiv (Cornell University), 1 Oct. 2024, https://doi.org/10.48550/arxiv.2410.01104.

[5] There is some academic support for pre-emptive measures through workflow optimisation to assist agentic responses. The researchers in one study examining why agents struggle to resolve real-world GitHub issues stated the following:

“Improving the workflow of software development agents is a promising direction. Enhancing an agent’s process with early, proactive measures that pre-empt common yet pervasive errors may reduce overhead and improve resolution rates.” — Chen, Z., Ma, W. & Jiang, L. (2025) ‘Unveiling Pitfalls: Understanding Why AI-driven Code Agents Fail at GitHub Issue Resolution’, arXiv preprint arXiv:2503.12374. Available at: https://arxiv.org/abs/2503.12374.

[6] ADT is a model I developed for forming test strategies directly from architecture diagrams.

[7] I’m grateful to Caroline and Cian for believing in the idea, backing the trial, and showing such patience and commitment in bringing it to life.

[8] We recorded 32 hours mob sessions and approximately 10 hours of individual work.

Irfan is a Principal Engineer specialising agentic delivery at ASOS. He is passionate about leveraging AI beyond AI-assisted coding to deliver quality products at pace. Currently proving a reimagined, real-word, quality-first, AI-driven product development lifecycle.

Introducing Test-Driven Vibe Development was originally published in ASOS Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

​​​​

Demand Forecasting at ASOS

With a catalogue of nearly 50,000 products at any given time, our AI-based demand forecasting system is critical for maintaining optimal inventory levels. We leverage machine learning to help our merchandising teams replenish the right number of products at the right time. Our aim is to accurately predict future demand for each product to avoid stock-outs while minimising excess inventory in our warehouses.

While our current demand forecast achieves good accuracy and operates at scale, we are always on the lookout for new technologies that could further improve our system’s performance. Last year, for example, we explored various deep learning frameworks, including Transformers. This year, we decided to dive into TimeGEN-1 and will be sharing in this post its capabilities, how to use it, and how it performed on our benchmark.

What are TimeGPT and TimeGEN-1?

TimeGPT represents the first attempt at developing a foundational model for time series forecasting. Research in this domain has been very active since then, with the publication of new models such as TimesFM, Chronos, Moirai, Time-MoE or Lag-Llama.

The model aims to leverage the success of transformer-based architectures in NLP and apply them to time series data. Both text and time series are sequential in nature. Just as transformers excel at processing sequences of words and identifying key words in a sentence, they could similarly focus on time points that influence future values using the self-attention mechanism. TimeGPT’s architecture was specifically designed for handling time series data though, providing the flexibility to process time series with varying frequencies and characteristics, as well as different input sizes and forecasting horizons.

TimeGPT was trained on over 100 billion data points, sourced from a diverse collection of publicly available time series across various domains such as finance, healthcare, and sales. The assumption is that, having been exposed to such a rich dataset, the model should be able to generalise and accurately forecast new scenarios, with fine-tuning or even in a zero-shot context. This is analogous to ChatGPT, which has been trained on extensive text data, enabling it to understand and generate human-like text across various topics and contexts.

TimeGPT was more recently added to Azure AI’s Model as a Service (MaaS) offering as a result of a partnership between Microsoft and Nixtla, under the name TimeGEN-1.

Forecasting with TimeGEN-1

We have decided to apply TimeGEN-1 to an operational demand forecasting problem at ASOS. Our goal is to forecast demand at a very granular level, specifically at a product level and by warehouse on a weekly basis, for thousands of products. Additionally, we need to forecast for the next 52 weeks to accommodate the longer lead times of certain products. Lead times refer to the period between placing an order and receiving the product in our warehouses, which can vary significantly depending on the supplier and product type.

Setting Up TimeGEN-1 in Azure AI

The first step to forecasting with TimeGEN-1 is to deploy a TimeGEN-1 model with Azure AI Foundry. Microsoft’s documentation on how to create a new deployment is straightforward. Once deployed, the only thing you will need is the Target URI and the Key value.

Forecasting with TimeGEN-1

Instantiating the Client

The only package you need to install is Nixtla’s SDK. You will then instantiate the client with the Target URI and the Key value mentioned just above.

from nixtla import NixtlaClient 
 
nixtla_client = NixtlaClient( 
 base_url="your_target_uri", 
 api_key="your_api_key", 
 timeout=None, 
)

The timeout argument corresponds to the request timeout in seconds. The default value is 60 but in our case we had to set it to None due to the size of our payload.

Processing the Data

The processing required to call the forecasting endpoint is the same as for the rest of the time series ecosystem developed by Nixtla (MLForecast , NeuralForecast , etc.). You will need a unique ID column, a timestamp column, and provide the future values of your exogenous variables (here future_exog_df).

Calling the Forecasting Endpoint

Once the data is processed, calling the forecasting endpoint becomes very straightforward. You just need to pass the dataframe containing historical data (both the target and the exogenous variables), the dataframe containing the future values of the exogenous variables, the number of horizons you want to forecast for, and the name of the ID, time, and target columns. Since we are using the Azure AI endpoint, the model has to be set to ‘azureai’.

The Nixtla endpoint provides users with two options in terms of models: timegpt-1 and timegpt-1-long-horizon. Nixtla recommends using the latter if you want to predict more than one seasonal period, which is our case here. Unfortunately it is not available as part of the Azure AI API at the time of writing.

Note that the API does not come with a cross-validation feature so you will have to implement your own.

nixtla_client.forecast( 
 df=df, 
 X_df=future_exog_df, 
 h=HORIZON, 
 freq='W-MON', 
 id_col='unique_id', 
 time_col='ds', 
 target_col='target', 
 model='azureai', 
)

Evaluation

The performance of TimeGEN-1 against our baseline model, a tree-based model, was assessed using a 4-fold rolling window cross-validation framework spanning over a year to account for variations in accuracy due to seasonality. In rolling window cross-validation, a fixed-size training window is moved across the data, and the model is trained on each window and evaluated on the subsequent window.

We also included a naïve forecast in our benchmark as an additional point of comparison. A naïve forecast predicts future values by simply using the most recent observed value as the forecast for all future periods.

TimeGEN-1 is less accurate than our baseline, but its performance remains impressive, especially considering it operates in a zero-shot setting. We also tested fine-tuning, but this feature is limited to one parameter with TimeGEN-1 (whereas TimeGPT allows fine-tuning up to five parameters), resulting in worse accuracy than zero-shot in our case.

To diagnose things further, we look at the bias metric and its breakdown by quantile. Bias is calculated as the difference between the prediction and the actual value. The overall bias of TimeGEN-1 is -2.3 units, suggesting that this model tends to underpredict for our use case.

Ideally, we would get a model where the bias is roughly the same across quantiles. In the graph below, we compared the average prediction to the average target by quantile. The target distribution was divided into 10 quantiles, but the first five appear as one because their average targets are very close.

In an ideal scenario, the red line, representing the average predictions from TimeGEN-1 by target quantile would be as close as possible to the dotted line, the identity line, which represents perfect calibration. However, both lines start diverging significantly from the 7th quantile, indicating that the model suffers from a lack of calibration.

In the context of demand forecasting, lack of calibration, and significant under-prediction of high sellers specifically is a big issue. High sellers, i.e., the top quantile, are products that show very high sales volumes compared to the average and represent a significant proportion of overall sales. Under-predicting would lead to stockouts and missed opportunities. This is why at ASOS we have focused on calibrating our models and wouldn’t be able to productionise TimeGEN-1 as it currently stands.

A note on cost

At the time of writing, the input cost was $0.00013 per 1,000 tokens, and the output cost was $0.00038 per 1,000 tokens. One token corresponds to one data point in the input or output dataset. The total input cost can therefore be summarised by the formula below:

Total input cost = $0.00013 x number of rows x (number of columns — 2*) / 1000

.

Overall, the input cost will increase with the amount of historical data being used, as well as the number of unique IDs you want to forecast for (e.g., products) and the number of exogenous variables being used. A similar equation can be derived for the total output cost.

*The unique ID and timestamp columns don’t count.

An Opinion on TimeGEN-1’s Capabilities

TimeGEN-1 is a very flexible framework. It supports the use of exogenous variables, unlike Time-MoE or Chronos. This capability is fundamental for providing additional context, which helps the model make more accurate predictions. It can also generate probabilistic forecasts and prediction intervals using the robust conformal prediction framework. This enables better risk management and more informed decision-making, particularly in the context of inventory decisions and managing safety stocks to limit stockouts.

The second version of the TimeGPT API has introduced SHAP values for model interpretability, although they are not yet implemented in Azure. Similarly, Nixtla has made two versions of their model available: a generic one and one for long-horizon forecasting. Unfortunately, no equivalent of the latter is available in Azure AI, which represents a real limitation for some use cases.

A significant downside is the persistence of fine-tuned models, which is currently not readily available. In a production environment with daily inference, this would necessitate fine-tuning TimeGEN-1 each day. This approach is unnecessary, as the model doesn’t need to be retrained or fine-tuned every single day, and it also has cost implications.

Conclusion

Nixtla’s collaboration with Microsoft to release TimeGEN-1 was a great initiative. It made Nixtla’s foundational model more widely accessible and streamlined integration with the rest of the ecosystem for Azure users.

The zero-shot accuracy of this model, although still a bit far from our baseline, remains quite impressive. It will be interesting to see how close we get once fine-tuning is fully made available, as well as the long-horizon model.

In terms of development, the team at Nixtla has been focusing on the right features, from explainability with SHAP to probabilistic forecasts and uncertainty quantification using conformal prediction, through to hierarchical forecasting. However, TimeGEN-1 is several versions behind TimeGPT-1, resulting in a more limited experience.

Additionally, until the persistence of fine-tuned models is enabled, it will not be a production-ready, enterprise-grade solution.

References

• Azul Garcia, Cristian Challu and Max Mergenthaler-Canseco. “TimeGPT-1”. May 2024. https://doi.org/10.48550/arXiv.2310.03589.
• How to deploy a TimeGEN-1 model with Azure AI Foundry, https://learn.microsoft.com/en-us/azure/ai-foundry/how-to/deploy-models-timegen-1

This article was written by Anita Clement, lead of the AI Forecasting team at ASOS.com. In her spare time, she enjoys playing the piano and cooking for others. Thank you to Tom Evans and Eduardo Nigri for reviewing this blog.

Benchmarking Nixtla x Microsoft’s TimeGEN-1: A Real-World Demand Forecasting Comparison was originally published in ASOS Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

They say if it ain’t broke, don’t fix it. But as QA Engineers (QAE) at heart, our job is to break things intentionally, all in the name of improving the end product, of course.

Faced with a role restructure and a company-wide roll out of the product operating model (POM), we took our critical eye to the QA engineering competency and sought to rethink the way we structured the key skills to better fit the new world.

So, armed with the existing competency, our decades worth of experience, and a stubborn drive to keep quality engineering at the cutting edge, we set out to rebuild the matrix from the ground up.

Here’s how we did it: refining the theory, debugging the old, refactoring the structure, and optimising the new so that our QA engineers have a clear reference point for the new era.

Legacy competency

The now legacy competency was a solid and proven foundation to work with, reflecting cutting-edge practices that our QAEs were already engaged in.

The legacy competency was underpinned by three fundamental quality principles.

1. Test first

2. Test automation first

3. Continuous quality

These principles informed our legacy competency matrix by emphasising rigorous analysis through test first methodologies. In this regard, we have pioneered Architecture-Driven Testing, which provides a methodical model to scrutinising product designs, and made extensive use of the analytical components of Acceptance Test Driven Development and Behaviour Driven Development. The competency skills also encouraged quality practices that facilitated small, high-frequency, high-speed releases.

As such, the legacy competency was already equipped to adapt to the “build” dimension of the POM, which stipulates small frequent releases as a principle.

With these foundations, we set about moulding the new competency to accommodate several considerations.

The Product Operating Model

POM centres the notions of “product” and outcomes. This means every problem we tackle should have a clear problem statement, and every solution should be judged by measurable success (i.e., not just a gut feeling).

We wanted these two facets to be more than just theory. That meant two things. First, that a product-first, outcome-driven mindset were woven into QAE practices. Second, structuring the themes of our competency framework to mirror how QAEs engage throughout the product development lifecycle.

With that in mind, we designed the following structure:

With this new structure we introduced the following to better reflect POM:

1. Language: We deliberately anchored our terminology in the notion of the “product”. For example, instead of using terms like “team test strategy” or “system test strategy”, we shifted to “product test strategy” for skills related to its formation. While this may seem trivial, we felt it was crucial in aiding the fostering of a product mindset, since language can impact how we see things.[1]

2. Identifying and measuring KPIs: KPI’s are essential for determining whether the problem we have set out to achieve has been solved. From a quality perspective, they act as meta-level acceptance criteria, going beyond the standard behavioural acceptance criteria QA engineers often scrutinise, build out, and refine. As such, we included skills to both ensure KPIs were considered in the “Understanding the Product” (analysis) and “Product Release” phases (instrumentation and measurement), while informing the “Product Development” phase.

3. Forming KPIs: Within the “Product Development” phase, we wanted QAEs to think about the technology enablers that drive product success. Thus, we introduced skills around the formation of quality engineering KPIs, which directly feed back into the Product Discovery phase.

Why does this matter? Consider the scenario where product problem statements have stacked implications. Suppose a product team wants to launch features experimentally but struggles with agility because they keep breaking production. That’s not just an engineering problem — it’s a quality problem. To direct a solutionising lens and effort, QAEs should drive KPI formation around the change failure rate. By tracking and improving this metric, they can identify quality gaps and push for more mature quality and deployment practices in their teams. In short, KPIs not only measure success, they help steer the quality strategy.

4. Product Risk: We subsumed the notion of product risk (particularly “feasibility”, which relates more to engineering) into the topic of “managing risk”. The topic of managing risk impacts the whole product development lifecycle.

Reflecting the QA Learning Programme

At ASOS, we have developed a bespoke and comprehensive QA learning programme (QALP), which reflects our ASOS engineering practices.

The programme has three levels, and each level contains multiple modules:

· Foundation — lays down the foundational principles and functional and non-functional quality engineering practices.

· Intermediate — expands the test-first principle by proposing a quality model that scrutinises architecture, ensuring contextualised, technically-informed product test strategies.

· Advanced — a new approach and model to product quality, which anchors quality and risk in reliability concerns.

Although the legacy competency factored the practices we were advancing in our QALP, we wanted to align the training to the competency even more coherently.

To achieve this, we updated both the skills and role definitions at each level to reflect the QALP’s maturity levels. This ensures that as QAEs progress, their growth is directly supported by the evolving best practices we champion, making the competency framework not just a reference, but a true compass for skills development.

Levels: continuous cycle of growth

The adaptation of the QALP to role expectations leads us nicely into the final set of changes: the introduction of new role levels.

A separate blog will help explain the rationale and changes made for the new structure.

Here, we will elaborate on how we tailored the new role levels into the QA engineering competency.

ASOS introduced the following changes to the career ladder:

· A new associate level role (level 2)

· A new mid-level role (level 4)

· A re-aligned senior role (level 6)

· A staff level role (level 7)

The roles distinctions were broadly based on the mastery of skills and the ability to apply them across diverse contexts. In other words, progression was not merely about knowing what to do, but demonstrating expertise in how, when, and where to apply these skills effectively.

The diagram below provides an illustration of how we distinguished the roles based on mastery:

Here is how we broke the QAE level down:

Level 1: QAEs focus on developing their understanding of quality principles and practices.

Level 2: they are building foundational quality engineering skills and actively applying these the quality lifecycle, gaining hands-on experience in real-world scenarios.

Level 3: Entering the mid-level engineering space, QAEs should have mastered foundational skills, applying them in a single product context. This marks the beginning of their journey into intermediate-level expertise.

Level 4: The key shift here is in scope: QAEs expand their experience beyond a single product or service. They also build their intermediate level skills and start exploring advanced quality practices. Senior behaviours also emerge at this stage, including mentoring juniors and supporting the adoption of good quality practices.

Level 5: QAEs achieve a mastery in advanced quality practices and actively drive mature quality lifecycle practices within their product team.

Level 6: QAEs evolve into technical leaders who quantifiably enhance quality through advanced functional and non-functional specialist skillsets within a single product team. They have the capability to apply their skills across different technology solutions within their product area.

Level 7: This role assumes mastery of prior skills but shifts focus to solving complex, strategic quality problems. The role is more strategic, requiring the Staff QAEs to demonstrate impact through metrics aligned to product goals. While they may align to a single team at any given moment, their scope of activities is defined by the problem, which often spans multiple teams.

In short, the framework is not just a checklist exercise. Its phases reflect a progressive cycle of learning, applying, and diversifying applicative experience.

Continuous quality

For us, revamping the QA engineering competency matrix was about redefining how we empower our QA engineers to grow.

By aligning it with the Product Operating Model (POM) we have built a framework that not only helps transition the company into the POM world but also remains adaptable for the future.

Moreover, in ensuring the competency framework is directly supported by our QA Learning Programme, QAEs have both the knowledge of the expectations they need to develop and the tools to get there.

Finally, we leveraged the new role level structure to smooth progression, avoiding skill gaps between jumps.

Of course, like any good quality engineer, we know this is not a one-and-done effort. Just as we continuously test and refine our products, we’ll keep iterating on the quality competency to ensure it remains valuable and meaningful. Because at ASOS, quality engineering is not afterthought. It’s always improving, always learning, and always striving to push the boundaries of what great quality engineering looks like.

Citation:

[1] https://www.scientificamerican.com/article/our-language-affects-what-we-see/

Irfan is a Principal Test Engineer at ASOS. He is passionate about making quality engineering the cornerstone of both delivering innovative, quality products and building organisations that enable them.

How we revamped the ASOS QA engineering competency was originally published in ASOS Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

As Android apps grow in complexity, an unstructured codebase can lead to tight coupling, duplicated logic, and fragile unit tests which ultimately slows down development. Clean Architecture principles address these challenges by enforcing a clear separation of concerns, making applications more scalable, maintainable, and testable.

At the heart of this architecture, the Domain Layer plays a crucial role in encapsulating business logic, ensuring a distinct boundary between the UI and data handling. This article deep dives into the Domain Layer, explaining its purpose, best practices, and how to implement it effectively in Android applications.

What is the Domain Layer?

The Domain Layer is responsible for handling the core business logic of an application. It acts as an independent layer, separate from both the Presentation Layer (which manages the UI and user interactions) and the Data Layer (which handles data storage and retrieval from sources like databases and REST APIs).

While the Presentation and Data Layers depend on the Domain Layer, it remains completely decoupled from them. This ensures that business logic remains unaffected by changes in UI frameworks or data sources.

The Domain Layer primarily contains:

• Use Cases (Interactors): Handle specific pieces of business logic, defining how data should be processed and used within the app.
• Domain Models: Represent entities within the business domain.
• Repository Interfaces: Define how data can be accessed without specifying the underlying source (such as a database or REST API), ensuring decoupling from the internals of the Data Layer.

Key Responsibilities of the Domain Layer

✅ Encapsulates Business Logic and Promotes Modularity
The Domain Layer centralizes and encapsulates business logic, ensuring it’s decoupled from both the Presentation Layer and the Data Layer. It defines Use Cases, which represent specific business workflows like placing an order or validating user input. Additionally, by isolating logic in this layer, it can be shared using Kotlin Multiplatform (KMP), reducing logic duplication with iOS and other platforms.

✅ Decouples Business Logic from Data Sources
The Domain Layer ensures business logic remains independent of data sources by relying on abstractions rather than concrete implementations. This allows flexibility in how data is fetched or persisted, so changes like switching from REST APIs to GraphQL or modifying database providers do not affect core business logic.

✅ Improves Testability
By keeping business logic in small, single-responsibility classes, the Domain Layer enhances testability. Use Cases depend on abstractions (e.g. Repository interfaces), making it easy to mock dependencies and write unit tests in isolation. This design supports test-driven development (TDD) and ensures high test coverage.

✅ Reduces Complexity in the Presentation Layer
By handling business logic and transformations, the Domain Layer ensures that ViewModels remain lean, focusing solely on managing UI state. Extracting logic from ViewModels into Use Cases allows us to reuse it across the application. This improves maintainability, making the Presentation Layer easier to test.

❌ Not Responsible for Data Storage or Retrieval
The Domain Layer does not handle data persistence or retrieval. These responsibilities belong to the Data Layer, which includes components like Repositories, Data Sources, REST APIs and Databases. The Domain Layer remains agnostic to how data is fetched or persisted.

❌ Not Responsible for UI State Management
The Domain Layer does not manage UI state, this is handled by the Presentation Layer (ViewModels). Instead, the Domain Layer executes business logic and returns immutable results.

The Anatomy of a Use Case

A Use Case is a class that encapsulates a single business operation, making it reusable and easy to test. A well-structured Use Case should have only one public function, as it should focus on a single responsibility.

If a Use Case has multiple public functions, it may be handling too many concerns, violating the Single Responsibility Principle (SRP). In such cases, consider splitting the logic into separate, more focused Use Cases.

1. Naming Use Cases

Use Case naming should follow the format:

[Verb] + [Noun] + UseCase

Examples:
✅ GetCustomerBagUseCase
✅ LogoutUserUseCase
✅ CacheOrderDetailsUseCase

2. Defining Business Logic

Business logic defines the rules and decisions that control how the app behaves in different situations. It determines:

• How data is processed — applying transformations before displaying it.
• When and how actions should be performed — validating user input before saving it.
• How different parts of the app interact — keeping responsibilities separate.

3. Use Case Dependencies

A Use Case should only depend on abstractions and pure Kotlin constructs, ensuring platform independence. Below is some guidance on what to include and avoid in Use Cases:

✅ Other Use Cases — For shared business logic (use sparingly to avoid excessive chaining).

✅ Pure Kotlin Utility Classes — For reusable logic like validation rules, number formatting etc.

✅ Repository Interfaces — To interact with the Data Layer without relying on concrete implementations.

❌ Android dependencies — Avoid using Context, LiveData, Application etc. Instead of using LiveData prefer Kotlin Flow or suspend functions to ensure the Domain Layer remains decoupled from the Android framework.

4. How Use Cases Expose Data

Use Cases provide data to the Presentation Layer through different mechanisms, depending on how the operation executes:

• Regular function calls — For synchronous operations (e.g. in-memory checks, simple calculations).
• Suspend functions — For asynchronous one-time operations (e.g. network requests, database queries).
• Flow — For reactive streams that emit updates over time (e.g. observing database changes).
• Observables/Callbacks — For RxJava-based architectures.

The choice depends on whether the operation is immediate and lightweight or asynchronous and long-running.

Best Practices in Use Cases

1. The Invoke Operator

Since Use Cases have a single responsibility, we can use the Kotlin invoke operator to make them callable like functions, eliminating redundant method calls.

class GetCustomerBagUseCase @Inject constructor(
    private val userRepository: UserRepository, // interface
    private val bagRepository: BagRepository // interface
) {
    suspend operator fun invoke(): Bag {
        val userId = userRepository.getUserId()
        return bagRepository.getCustomerBag(userId)
    }
}

This allows the call in the ViewModel to be more concise and intuitive:

val customerBag = getCustomerBagUseCase()

2. Thread Safety

Use Cases should be main-thread safe, meaning they can be called from the main thread without blocking the UI. Long-running operations like REST API calls or database queries, should be delegated to the Data Layer.

The Domain Layer should not switch to I/O-bound threads (like Dispatchers.IO). The Data Layer is responsible for managing the threading and will switch to a background thread as close to the source of the call as possible. However, for CPU-intensive tasks like sorting and transformations, we can use Dispatchers.Default within the Domain Layer.

Imagine we need to process a batch of fetched products and apply sorting, formatting their creation dates, and calculating discounts.

• Fetching products → Handled in the Data Layer (e.g. Repository fetching from REST API or database).
• Sorting & Formatting → Business logic that belongs in the Domain Layer.

Since processing these products is CPU-intensive, it should be executed on a background thread to prevent UI freezes and ANR (Application Not Responding) errors.

✅ Best Practice: Move Heavy Computation to a Background Thread

class FormatProductListUseCase @Inject constructor(
    private val productRepository: ProductRepository, // interface
    private val formatDateUseCase: FormatDateUseCase,
    private val calculateDiscountUseCase: CalculateDiscountUseCase,
    @CoroutineDefault private val defaultDispatcher: CoroutineDispatcher
) {
   suspend operator fun invoke(): List<Product> = withContext(defaultDispatcher) {
    productRepository.getProducts()
        .sortedByDescending { it.price }
        .map { product ->
            val formattedDate = formatDateUseCase(product.createdAt)
            val discount = calculateDiscountUseCase(product.price)
            
            product.copy(
                createdAt = formattedDate,
                discount = discount
            )
        }
}

data class Product(
    val id: String,
    val name: String,
    val price: Double,
    val createdAt: String,
    val discount: Double = 0.0
)

Why This Works

✅ Delegates Fetching to the Data Layer
The responsibility of fetching the products is handled by the Data Layer, keeping business logic focused in the Domain Layer.

✅ Uses Dispatchers.Default for CPU-intensive Tasks
Sorting and transformations run on a background thread, improving performance and preventing UI freezes.

✅ Injects CoroutineDispatcher for Testability
This allows for easy replacement with a test dispatcher during unit testing. This ensures that Coroutines execute in a controlled environment, making tests faster, more predictable, and isolated from real threading concerns.

✅ Keeps Business Logic Modular
By encapsulating the date formatting and calculating discounts in separate, reusable Use Cases, the code remains modular, and easier to maintain.

3. Combining Data from Multiple Repositories

While it’s possible to merge data from multiple sources in a ViewModel or Repository, doing so can make these classes complex and difficult to test. Instead, it’s better to create a Use Case that aggregates data from different Repositories, keeping business logic separate and reusable.

✅ Best Practice: Combining Products With User Bag Count Using Flows

class GetProductsWithBagCountUseCase @Inject constructor(
    private val productsRepository: ProductsRepository, // interface
    private val bagRepository: BagRepository, // interface
    private val userRepository: UserRepository // interface
) {
    operator fun invoke(): Flow<ProductsWithBagCount> {
        val userId = userRepository.getUserId()
        return combine(
            productsRepository.getUserProducts(userId),
            bagRepository.getUserBagCount(userId)
        ) { products, bagCount ->
            ProductsWithBagCount(products, bagCount)
        }
    }
}

data class ProductsWithBagCount(
    val products: List<Products>,
    val bagCount: Int
)

Why This is Better

✅ Uses Flow.combine()
Aggregates data reactively, ensuring any updates from either Repository propagate automatically. combine() emits the latest values from all combined flows.

✅ Avoids Blocking Threads
Data fetching is asynchronous via Flows, ensuring non-blocking, efficient execution.

✅ Keeps the ViewModel Focused
The ViewModel only collects a single source of truth, rather than managing multiple Repository calls, making it simpler and more focused on UI state.

✅ Repositories Maintain a Single Responsibility
Repositories avoid dependencies on one another, maintaining a clear separation of concerns, which simplifies testing and maintenance.

✅ Improves Testability
The Use Case is easier to mock in unit tests, eliminating the need to handle multiple StateFlow or Flow instances directly in the ViewModel.

4. Data Validation

Data validation is a critical aspect of ensuring the integrity and correctness of the data flowing through your application. By handling validation logic within the Domain Layer, we achieve:

✅ Consistency
Ensuring data is validated before being processed or presented.

✅ Reusability
Avoiding redundant validation logic across different parts of the app.

✅ Separation of Concerns
Keeping validation independent of the Presentation and Data Layers.

Input Validation
Ensures user inputs meet specific criteria before being processed or stored.

• Checking if an email follows the correct format (e.g. user@example.com).
• Verifying that a password meets minimum length and complexity requirements.

Business Rule Validation
Ensures data complies with domain-specific business rules. Frontend validation can help improve UX by checking business rules before an action is performed, based on received data.

• Checking if a user has sufficient funds before placing an order to avoid unnecessary REST API calls.
• Ensuring a product is in stock before proceeding with a purchase. If this check fails we could disable the “Purchase” button.

Format Validation
Ensures data follows a predefined structure or pattern.

• Validating that a date string follows a certain format like YYYY-MM-DD.
• Ensuring a phone number contains the correct number of digits.

✅ Best Practice: Data Validation in the Domain Layer
Let’s consider an example where we need to validate a user’s email address and password before allowing them to register.

class ValidateUserRegistrationUseCase @Inject constructor(
    private val emailValidator: EmailValidator,
    private val passwordValidator: PasswordValidator
) {
    suspend operator fun invoke(
      email: String, 
      password: String
    ): ValidationResult {
        return when {
            !emailValidator.isValid(email) -> ValidationResult.InvalidEmail
            !passwordValidator.isValid(password) -> ValidationResult.InvalidPassword
            else -> ValidationResult.Valid
        }
    }
}

sealed interface ValidationResult {
    data object Valid : ValidationResult
    data object InvalidEmail : ValidationResult
    data object InvalidPassword : ValidationResult
}

Validation Overview

✅ Keep Validation Logic Simple and Focused
Each validator should focus on one specific task (e.g. validating email format or password length).

✅ Error Handling
Use sealed classes or sealed interfaces to represent validation states (valid/invalid), making error handling simpler and more readable.

✅ Avoid Duplicating Validation Logic
Keep validation logic reusable to avoid duplicating code across different parts of the app.

✅ Test Validation Logic Independently
Since validation logic is part of business rules, unit tests should focus on ensuring that the validation logic works correctly in various scenarios (e.g. invalid email formats, short passwords, etc.).

❌ Hardcoding Error Messages
Avoid hardcoding error messages. Instead, define error states to ensure consistency across the app.

Managing Use Cases: Injection, Lifecycle, and Execution

In a ViewModel-based architecture, Use Cases are injected into the ViewModel and executed as needed. Hilt can automatically provide a Use Case if it has only one implementation. To ensure the Use Case lives as long as the ViewModel, annotate it with @ViewModelScoped. This ensures the Use Case instance is created once when the ViewModel is initialized and remains the same throughout the ViewModel’s lifecycle, avoiding unnecessary re-creations.

@ViewModelScoped
class GetCustomerBagUseCase @Inject constructor() {}

Some Use Cases may benefit from being @Singleton scoped which ensures a single instance exists for the lifecycle of the app. This can be useful for persistent business logic like authentication.

If a Use Case has multiple implementations or follows an interface-based abstraction, bind the implementation in a @Module and install it in ViewModelComponent.

@Module
@InstallIn(ViewModelComponent::class)
abstract class BagModule {
    @Binds
    @ViewModelScoped
    abstract fun bindGetCustomerBagUseCase(
        impl: GetCustomerBagUseCaseImpl
    ): GetCustomerBagUseCase
}

Injection Methods: Standard vs Lazy

There are two primary ways to inject Use Cases:

• Standard injection for frequently used Use Cases
• Lazy injection for Use Cases that are only needed conditionally

1. Standard Injection (For Frequently Used Use Cases)

For Use Cases that are used frequently, we can constructor-inject them directly into the ViewModel. The instance is created once when the ViewModel is initialized and remains active throughout the ViewModel’s lifecycle.

@HiltViewModel
class BagViewModel @Inject constructor(
    private val getCustomerBagUseCase: GetCustomerBagUseCase
) : ViewModel() {

    private val _customerBag = MutableStateFlow<CustomerBag?>(null)
    val customerBag: StateFlow<CustomerBag?> = _customerBag.asStateFlow()
    
    fun getCustomerBag() {
        viewModelScope.launch {
            _customerBag.update { getCustomerBagUseCase() }
        }
    }
}

2. Lazy Injection (For Selectively Used Use Cases)

For Use Cases that are only used in specific scenarios, lazy injection delays instantiation until needed. This reduces unnecessary object creation and avoids injecting dependencies that might not be used.

import dagger.Lazy

@HiltViewModel
class BagViewModel @Inject constructor(
    private val saveItemToWishListUseCase: Lazy<SaveItemToWishListUseCase>
) : ViewModel() {

    fun saveItemToWishList(item: Item) {
        viewModelScope.launch {
            saveItemToWishListUseCase.get().invoke(item)
        }
    }
}

Here, SaveItemToWishListUseCase is not instantiated until get() is called, reducing memory usage and improving app performance when the Use Case isn’t always needed.

Use viewModelScope for Coroutine Management 🚀

When executing Use Cases within a ViewModel, always use viewModelScope.launch{}. This ensures:

• Coroutines are automatically cancelled when the ViewModel is destroyed, preventing memory leaks.
• Background tasks terminate properly when the UI is no longer active.

By default, viewModelScope.launch{} uses the Main Dispatcher, making it ideal for UI-related operations.

Note that @ViewModelScoped controls the lifecycle of the Use Case instance. It ensures a single Use Case instance per ViewModel lifecycle, while viewModelScope.launch{} manages Coroutine execution and cancellation. Whilst named similarly these are separate concerns.

Key Takeaways

✅ Use Cases persist with the ViewModel
Scoping a Use Case with @ViewModelScoped ensures it lives as long as the ViewModel, avoiding unnecessary re-creations.

✅ Leverage viewModelScope.launch{} in ViewModels
Runs on the Main Dispatcher by default making it suitable for UI operations and guarantees automatic Coroutine cancellation when the ViewModel is cleared, preventing memory leaks.

✅ Choose the right injection method based on usage
Standard injection for frequently used Use Cases and lazy injection for optional Use Cases to defer instantiation and reduce memory overhead.

❌ Do not inject Use Cases into the Data Layer
Use Cases belong to the Domain Layer and should be invoked from the Presentation Layer or other Use Cases when necessary. They should not be injected into the Data Layer (e.g. Repositories, Data Sources or Mappers) as this violates Clean Architecture principles by introducing unnecessary dependencies and increasing coupling between layers.

Data Access Restrictions in the Domain Layer

A common question in Clean Architecture is:

Should ViewModels and other Presentation Layer components access Repositories directly, or should all data access go through Use Cases?

Restricting data access to the Domain Layer has its advantages and drawbacks:

✅ Ensures Consistent Business Logic Execution
Use Cases enforce rules such as analytics tracking, validation, and data transformations, ensuring that business logic is consistently applied and preventing inconsistent access to raw data from the Data Layer.

✅ Supports Modularisation
In modularised API/Implementation projects, feature modules expose Use Case interfaces in the :api module. This keeps inter-module dependencies minimal, and simplifies the overall architecture.

✅ Simplifies ViewModel Testing
Since ViewModels depend only on Use Cases instead of Repositories, testing becomes easier. There’s no need to mock Repositories in ViewModel tests, allowing for more isolated, focused, and maintainable unit tests.

❌ Introduces Overhead for Simple Fetches
When a Use Case simply wraps a Repository call without adding business logic, it can feel redundant and introduce unnecessary complexity.

At ASOS, we follow the API/Implementation modularisation strategy, where restricting direct data access to the Domain Layer aligns naturally with our architecture. This ensures consistent data handling, reduces coupling, and simplifies long-term maintainability as the project scales.

Package Structure

Below is an example of how the Domain Layer can be structured. This is a simple representation and could change in a modularised app.

📂 domain
 ├── 📂 model
 │    ├── ProductsWithBagCount.kt
 │    ├── Bag.kt
 │    ├── Product.kt
 │
 ├── 📂 repository
 │    ├── ProductsRepository.kt  //interface
 │    ├── BagRepository.kt  //interface
 │
 ├── 📂 usecase
 │    ├── AddItemToBagUseCase.kt
 │    ├── RemoveItemFromBagUseCase.kt

Conclusion

Incorporating the Domain Layer into your Android application offers numerous benefits, including scalability, testability, and maintainability. By isolating business logic within the Domain Layer, you ensure that the ViewModel and other UI components remain lean and focused solely on rendering the UI, without the burden of complex operations or data management. This separation of concerns helps create a robust and easily extensible architecture, especially as the app grows in size and complexity.

By properly structuring Use Cases, handling threading efficiently, and deciding on access restrictions wisely, you can build a maintainable app architecture that stands the test of time.

I’m Sean Coyle and I joined the ASOS Android team in August 2022. I started my career in Android development in 2019. Before that, I was a social worker and spent a few years teaching English in Japan.

Android Clean Architecture: Understanding the Domain Layer was originally published in ASOS Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Cancer fund for children is an exceptional charity which offers an escape from the hardships faced by families dealing with Cancer, they provide necessary services and support to families during this difficult time.

We’ve arranged several activities over the year to fundraise and support our chosen charity, and this blog will highlight what we’ve achieved and organised throughout the year.

We kicked off our fundraising with a short talk from Cancer Fund For Children around what services and support they’ve provided families along with a testimonial from one of the families that benefited from their services. With this new motivation, we then kicked of our charity row. This all took place during ASOS Develops, a two day event which we are entitled to use through ASOS for our own personal development.

The Great ASOS Row

The row consisted off 13 individuals rowing the distance of 109 km which is the distance of our ASOS Belfast Office to Daisy Lodge and back. Daisy Lodge is a purpose-built therapeutic centre located in Newcastle Co. Down which Cancer Fund For Children offer for families across the island of Ireland affected by cancer.

The row itself kicked off around 8am and finished up at 5pm, rotating consecutively through each of our rowers to reach our 109km target. We divided it up into 15–45 minute time slots. Those that completed 45 minutes enjoyed a bit of competition on the distance which they could cover during that time and there were a few sore legs in the days following. A huge thanks to Custom House Offices for allowing us to utilise the gym for this event.

Santa Hats & Raffle

Around Christmas time, our charity committee got creative and designed personalised Santa hats. Individuals donated £10 to Cancer Fund For Children, we then designed and created a tailored Santa hat using their name and had them delivered to the office in time for Christmas. We also ran a small raffle for an extra fundraising boost.

The Great ASOS Bake Off

In February, we held our Great ASOS Bake Off where we had some prizes contributed by a few fantastic local businesses. On the day, everyone in the office could place their votes for first, second and third place with each place being worth 3, 2 or 1 points. To increase the odds of winning even further there where also winners for the most Aesthetic and most Creative bake.

Individuals interested in taste testing and voting for each of the baked goods then donated towards our Just Giving page. It was a dough-lightful day for everyone involved, especially those with a sweet tooth!

Bucket Collections

We then offered our volunteering time back in May, collecting donations at the entrance to Belsonic for a few hours with the high footfall traffic. Once finished, we then had time to relax and enjoy the final act. One of the many advantages of partnering with Cancer Fund For Children.

Volunteering Day

Finally, we visited Daisy Lodge in Newcastle on Monday 29th July to volunteer with the Cancer Fund For Children. We were able to help out with painting and weeding, bringing the lodge back up to peak condition. Before kicking off our tasks, we received a tour of the beautiful retreat they have created and the wonderful restful opportunities they provide to families affected by cancer, both children and parents, and also for bereaved families who have lost someone to cancer over the last 10–15 years.

We are all inspired by the facilities and services that Cancer Fund For Children provide. Unfortunately Cancer Fund For Children are limited on the number of people they can offer these to at one given time as they currently can only have 200 families on the waitlist and there are hundreds, if not sadly thousands, of families in both Northern Ireland and Ireland in need of their special support.

We would love to help Cancer Fund For Children continue to support these families by exceeding our fundraising target of £2,000 before our next financial year when our local charity renews.

If you feel like you can, please donate using the link below. It’ll be greatly appreciated.

Cancer Fund for Children fundraising

Thank you!!

Hi, I’m Niamh McGuigan, an Engineering Manager on the Web team at ASOS. I support Web Engineers and QAs in their career growth while ensuring our technology platforms deliver high-quality solutions.

I’m also active in the NI Charity Committee and volunteer externally with Women Techmakers. Outside of work, I love planning and going on outdoor adventures — like this one from my recent trip to the Dolomites in Italy!

Feel free to connect with me on Linkedin below ⬇️

https://www.linkedin.com/in/niamh-mcguigan-6b766aa5/

ASOS NI x Cancer Fund For Children was originally published in ASOS Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

The second in a two-part series where we share how at ASOS we are measuring agility across our teams and the wider tech organisation…

Recap on part one

For those who didn’t get a chance to read part one, previously I introduced our holistic measurement to agility, covering four themes of:

• Flow — the movement of work through a teams workflow/board.
• Value — the outcomes/impact in what we do and alignment with the goals and priorities of the organisation.
• Culture — the mindset/behaviours we expect around teamwork, learning and continuous improvement.
• Delivery — the practices we expect that account for the delivery of Epics/Features, considering both uncertainty and complexity.

Now let’s get to explaining how the results are submitted/visualized, what the rollout/adoption has been like along with our learnings and future direction.

Submitting the results

We advise teams to submit a new assessment every six to eight weeks, as experience tells us this gives enough time to see the change in a particular theme. When teams are ready to submit, they go to an online Excel form and add a new row, then add the rating and rationale for each theme:

Visualizing the results

Team view

By default, all teams and their current rating/trend, along with the date when the last assessment was run are visible upon opening the report:

Viewers can then filter to view their team — hovering on the current rating provides the rationale as well as the previous rating and rationale. There is also a history of all the submitted ratings for the chosen theme over time:

Filters persist across pages, so after filtering you can also then click through to the Notes/Actions page to remind yourself of what your team has identified as the thing to focus on improving:

Platform/Domain view

Normally, we facilitate a regular discussion at ‘team of teams’ level which, depending on the size of an area, may be a number of teams in a platform or all the teams and platforms in a Domain:

This helps leaders in an area understand where the collective is at, as well as being able to focus on a particular team. It also can highlight where teams in an area learn from each other, rather than just relying on an Agile Coach to advise. Again filtering persists to allow for Leaders to have a holistic view of improvements across teams:

This is key for leaders as it informs them in understanding how they can support an environment towards continuous improvement and agility. For example if a team was experimenting with WIP limits to improve their rating for Flow, if a leader is pushing more work to them then this probably isn’t going to result in the theme improving!

Tech Wide View

The Tech Wide View provides an overview of the most recent submissions for all teams across the organisation. We feel this gives us the clearest ‘measurement’ and holistic view of agility in our tech organisation, with the ability to hover on a specific theme to see if ratings are improving:

As coaches, this also helps inform us as to what practices/coaching areas we should be focusing on at scale, rather than trying to go after everything and/or focusing on just a specific team.

In turn we can use this data to help inform things like our own Objectives and Key Results (OKRs). We use this data to guide us on what we should be focusing on and, more importantly, if we are having impact:

Rollout, adoption and impact

In rolling this out, we were keen to stick to our principles and invite teams to complete this, rather than mandating (i.e. inflicting) it across all of our technology organisation. We used various channels (sharing directly with teams, presenting in Engineering All Hands, etc.) to advertise and market it, as well as having clear documentation around the assessment and the time commitment needed. After launching in Jan, this is the rate at which teams have submitted their first assessment:

In addition to this, we use our internal Team Designer app (more on this here) to cross-reference our coverage across domains and platforms. This allows us to see in which areas adoption is good and in which areas we need to remind/encourage folks around trialling it:

With any ‘product’, it’s important to consider what are appropriate product metrics to consider, particularly as we know measurable changes in behaviour from users are typically what correlate with value. One of the ways to validate if the self-assessment is adding value for teams is if they continue to use it. One-off usage may give them some insight but if it doesn’t add value, particularly with something they are ‘invited’ to use, then it will gradually die and we won’t see teams continue to complete it. Thankfully, this wasn’t the case here, as we can see that 89% of teams (70 out of 79) have submitted more than one self-assessment:

The main thing though that we are concerned with in demonstrating the impact/value of this approach is if teams are actually improving. You could still have plenty of teams adopt the self-assessment yet stay the same for every rating and never actually improve. Here we visualise each time a team has seen an improvement between assessments (note: teams are only counted the first time they improve, not counted again if they improve further):

Overall we can see the underlying story is that the vast majority of teams are improving, specifically that 83% of teams (58 out of 70) who have submitted >1 assessment have improved in one (or more) theme.

Learnings along the way

Invitation over infliction

In order to change anything around ways of working in an organisation, teams have to want to change or “opt-in”. Producing an approach without the acceptance going in that you may be completely wrong and being prepared to ditch it leads to sunk cost fallacy. It is therefore important with something like this that teams can “opt-out” at any time.

Keep it lightweight yet clear

There are many agility assessments that we have seen in different organisations/the industry over the years and almost always these fall foul of not being lightweight. You do not need to ask a team 20 questions to “find out” about their agility. Having said this, lightweight is not an excuse for lack of clarity, therefore supporting documentation on how people can find out where they are or what the themes mean is a necessity. We used a Confluence page with some fast-click links to specific content to allow people to quickly get to what they needed to get to:

Shared sessions and cadence

Another way to increase adoption is to have teams review the results together, rather than just getting them to submit and then that’s it. In many areas we, as coaches, would facilitate a regular self-assessment review for a platform or domain. In this each team would talk through their rationale for a rating whilst the others can listen in and ask questions/give ideas on how to improve. There have been times for example when ratings have been upgraded due to teams feeling they were being too harsh (which surprisingly I also agreed with!) but the majority of time there are suggestions they can make to each other. In terms of continuous improvement and learning this is way more impactful than hearing it from just an Agile Coach.

Set a high bar

One of the observations we made when rolling this out was how little ‘green’ there was in particular themes. This does not automatically equate to teams being ‘bad’, more just they are where we think good is from an agility perspective, relevant to our experience and industry trends.

One of the hard parts with this is not compromising in your view of what good looks like, even though it may not be a message that people particular like. We leaned heavily on the experience of Scott Frampton and his work at ASOS to stay true to this, even if it at times it made for uncomfortable viewing.

Make improvements visible

Initially, the spreadsheet did not contain the column about what teams are going to do differently as a result of this, it was only after a brief chat with Scott and with his learnings we implemented this. Whilst it does rely on teams to add in the detail about what they are going to do differently, it helps see that teams are identifying clear action to take, based on the results of the assessment.

Culture trumps all when it comes to improvement

This is one of the most important things when it comes to this type of approach. One idea I discussed with Dan Dickinson from our team was around a ‘most improved’ team, where a team had improved the most from their initial assessment to what they are now. In doing this one team was a clear standout, yet they remained at a value of ‘red’ for culture. This isn’t the type of team we should be celebrating, even if all the other factors have improved. Speedy delivery of valuable work with good rigour around delivery practices is ultimately pointless if people hate being in that team. All factors to the assessment are important but ultimately, you should never neglect culture.

Measure it’s impact

Finally, focus on impact. You can have lots of teams regularly assessing but ultimately, if it isn’t improving the way they work it is wasted effort. Always consider how you will validate that something like an assessment can demonstrate tangible improvements to the organisation.

What does the future hold?

As a coaching team we have a quarterly cadence of reviewing and tweaking the themes and their levels, sharing this with teams when any changes are made:

Currently, we feel that we have the right balance in the number of themes vs. the light-weightiness of the self-assessment. We have metrics/tools that could bring in other factors, such as predictability and/or quality:

Right now we’ll continue the small tweaks each quarter with an aim to improve as many teams, platforms and domains as we can over the next 12 months…watch this space!

About Me

I’m Nick, Lead Agile Coach at ASOS. I help guide individuals, teams and platforms to improve their ways of working in a framework-agnostic manner. Outside of work, me and my wife Nisha have a one-year old that keeps us on our toes agility-wise…

ASOS are hiring across a range of roles in Tech. See all our open positions

Flow, value, culture, delivery — measuring agility at ASOS (part 2) was originally published in ASOS Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

The first in a two-part series where we share how at ASOS we are measuring agility across our teams and the wider tech organisation. This part covers the problems we were looking to solve, what the themes are, as well as exploring the four themes in detail…

Context and purpose

As a team of three coaches with ~100 teams, understanding where to spend our efforts is essential to be effective in our role. Similarly, one of our main reasons to exist in ASOS is to help understand the agility of the organisation and clearly define ‘what good looks like’.

Measuring the agility of a team (and then doing this at scale) is a difficult task and in lots of organisations this is done through the usage of a maturity model. Whilst maturity models can provide a structured framework, they often fall short in addressing the unique dynamics of each organisation, amongst many other reasons. The rigidity of these models can lead to a checklist mentality, where the focus is on ticking boxes (i.e. ‘agile compliance’) rather than fostering genuine agility. Similarly they assume everyone follows the same path where we know context differs.

Unfortunately, we also found we had teams at ASOS that were focusing on the wrong things when it comes to agility such as:

• Planned vs. actual items per sprint (say-do ratio)
• How many items ‘spill over’ to the next sprint
• How many story points they complete / what’s our velocity / what is an “8-point story” etc.
• Do we follow all the agile ceremonies/events correctly

When it comes to agility, these things do not matter.

We therefore set about developing something that would allow our teams to self-assess, which focuses on the outcomes agility should lead to. With the main problems to solve being:

• Aligning ASOS Tech on a common understanding of what agility is
• Giving teams a lightweight approach to self-assess, rather than relying on Agile Coaches to observe and “tell them” how agile they are
• Having an approach that is more up to date with industry trends, rather than how people were taught Scrum/Kanban 5, 10 or 15+ years ago
• Having an approach to self-assessment that is framework agnostic yet considers our ASOS context
• Allowing senior leaders to be more informed about where their teams are agility wise

Our overarching principle being that this is a tool to inform our collective efforts towards continuous improvement, and not a tool to compare teams, nor to be used as a stick to beat them with.

The Four Themes

In the spirit of being lightweight, we restricted ourself to just four themes, these being things that we think are most important for teams when it comes to the outcomes you should care about when it comes to your way of working.

• Flow — the movement of work through a teams workflow/board.
• Value — focusing on the outcomes/impact of what we do and alignment with the goals and priorities of the organisation.
• Culture — the mindset/behaviours we expect around teamwork, learning and continuous improvement.
• Delivery — the practices we expect that account for the delivery of features and epics, considering both uncertainty and complexity.

Each theme has three levels, which are rated on a Red/Amber/Green scale — mainly due to this being an existing scale of self-assessment in other tools our engineering teams have at their disposal.

Flow

The focus here is around flow metrics, specifically Cycle Time and Work Item Age, with the three levels being:

Teams already have flow metrics available to them via a Power BI app, so are able to quickly navigate and understand where they are:

The goal with this is to make teams aware just how long items are taking, as well as how long the “in-flight” items have actually been in progress. The teams that are Green are naturally just very good at breaking work down, and/or have already embedded looking at this on a regular basis into their way of working (say in retrospectives). Those teams that are at Red/Amber have since adopted techniques such as automating the age of items on the kanban board to highlight aging items which need attention:

Value

The focus with this theme is understanding the impact of what we do and ensuring that we retain alignment with the goals and priorities of the organisation:

In case you haven’t read it, in the ASOS Tech blog previously I’ve covered how we go about measuring portfolio alignment in teams. It essentially is looking at how much of a team backlog goes from PBI/User Story > Feature > Epic > Portfolio Epic. We visualise this in a line chart, where teams can see the trend as well as flipping between viewing their whole backlog vs. just in-flight work:

Similar to flow metrics, teams can quickly access the Power BI app to understand where they are for one part of value:

The second part is where many teams currently face a challenge. Understanding the impact (value) of what you deliver is essential for any organisation that truly cares about agility. We’re all familiar with feature factories, so this was a deliberate step change to get our teams away from that thinking. What teams deliver/provide support for varies, from customer facing apps to internal business unit apps and even tools or components that other teams consume, so having a ‘central location’ for looking at adoption/usage metrics is impossible. This means it can take time as either data is not readily available to teams or they had not actually really considered this themselves, most likely due to being a component part of a wider deliverable.

Still, we’ve seen good successes here, such as our AI teams who measure the impact of models they build around personalised recommendations, looking at reach and engagement. Obviously for our Web and Apps teams we have customer engagement/usage data, but we also have many teams who serve other teams/internal users, like our Data teams who look at impact in terms of report open rate and viewers/views of reports they build:

Culture

Next we look at the behaviours/interactions a team has around working together and continuously improving:

Ultimately, we’re trying to get away from the idea that many have around agility that continuous improvement = having retrospectives. These are meaningless if they are not identifying actionable (and measurable) improvements to your way of working, no matter how “fun” it is to do a barbie themed format!

We aren’t prescriptive in what team health tool teams use, so long as they are doing it. This could be our internal tool, PETALS (more on this here), the well known Spotify Team/Squad Health Check or even the Team Assessment built into the retrospectives tool in Azure DevOps:

The point is that our good teams are regularly tracking this and seeing if it is getting better.

A good example of what we are looking for at ‘green’ level is from this team who recently moved to pairing (shout out to Doug Idle and his team). Around 8 weeks before this image was taken they moved to pairing, which has not only made them happier as a team, but has clearly had a measurable impact in reducing their 85th percentile cycle time by 73%:

Combine this with then sharing more widely, primarily so teams can learn from each other, then this is what we are after in our strongest teams culturally.

Delivery

The final theme touches on what many agile teams neglect which is ultimately about delivering. When we mean delivery in this context we’re focusing on delivery of Features/Epics (as opposed to PBI/Story level). Specifically, we believe it’s understanding risk/uncertainty and striving towards predictability and what this means when using agile principles and practices:

The good teams in this theme understand that due to software development being complex, you need to forecast delivery with a percentage confidence, and do this regularly. This means using data which, for our teams is available to them within a few clicks, here they can forecast, given a count of items when will they be done or, given a time box, what can they deliver.

Many teams have multiple features in their backlog, thus to get to ‘green’ our teams should leverage Feature Monte Carlo so the range of outcomes that could occur for multiple Features is visible:

Previously I’ve covered our approach to capacity planning and right-sizing, where teams focus on making Features no bigger than a certain size (batch) and thus can quickly (in seconds) forecast the amount of right-sized features they have capacity for, which again is what we look for in our ‘green’ criteria:

The best way to do this really is to have a regular cadence where you specifically look at delivery and these particular metrics, that way you’re informed around your progress and any items that may need breaking down/splitting.

Part two…

In this post I share how teams submit their results (and at what cadence) as well as how the results are visualised, what the rollout/adoption has been like, along with our learnings and future direction for the self-assessment.

About Me

I’m Nick, Lead Agile Coach at ASOS. I help guide individuals, teams and platforms to improve their ways of working in a framework-agnostic manner. Outside of work, me and my wife Nisha have a one-year old that keeps us on our toes agility-wise…

ASOS are hiring across a range of roles in Tech. See all our open positions

Flow, value, culture, delivery — measuring agility at ASOS.com (part 1) was originally published in ASOS Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

This month, Google hosted the first of its follow-up series of events for their annual Google I/O conference. In this post, Ed Holloway-George highlights what he learned at the I/O Connect event held in Berlin, Germany.

As an Android developer and self-proclaimed tech nerd, the Google I/O conference is one of the dates I always look forward to on my calendar each year.

Held at the impressive Shoreline Amphitheatre in Mountain View, California, it’s usually Google’s primary showcase of all the exciting announcements they have to share across their software, hardware and other digital products. In years gone by, we’ve seen major announcements including the launch of Google Assistant, Google Home, numerous Android versions and of course, the ill-fated and slightly ahead of its time, Google Glass.

However, this year’s edition held on May 14th had from the offset a very specific focus — AI. As the hottest topic in tech right now, it comes as no surprise that Google is also going all-in with its AI offerings this time around. In fact, so much so, that “AI” was mentioned at least 120 times during the main keynote presentation 😅 That aside, there were also many other announcements in the mobile, cloud and web spaces for developers and consumers to look forward to. If you missed any of these yourself, you should check out the official site and catch up 👀

Whilst the main conference was primarily focused on announcements, Google also has several smaller developer-focused follow-up events known as I/O Connect. The idea behind I/O Connect events is to get the new technologies announced at the main conference in the hands of developers, have Google employees (Googlers) readily available to take questions as well as present additional content and of course, for developers from across the world to meet up and share a common passion for Google’s tech.

Being a Google Developer Expert for Android, I was fortunate enough to be invited to this year’s European instalment of I/O Connect, held in a swelteringly hot Berlin 🤒

So, to completely misquote the Ramones, “I/O let’s go!”…

What I learned at I/O Connect 24

In my experience, there’s no such thing as a dull Google event. I/O Connect this year comes as no exception with an indoor artificial river installation being the centrepiece of the event’s location within a converted warehouse complex. With multiple auditoriums, workshop spaces and free barista-made coffee, the stage was already set for a great developer event.

But what did we learn? There were some amazing announcements, but here’s a summary of some of my personal key takeaways!

• Google’s investment in AI is scaling up

Google used I/O Connect’s keynote to announce their latest “Gemma 2” suite of models. The newly available models boast the ability to support either 9 billion or 27 billion parameters and have performance metrics that surpass known industry leaders such as the popular Llama-3 offering from Meta. The rapid release of Google’s AI products and the mind-boggling numbers associated with them is a testament to how much effort they are focusing on this area and it continues to be at the forefront of developer’s minds.

A live demo of Google’s Gemini AI being used in developer tooling to aid the investigation of a bug in software was incredibly popular with the Keynote’s crowd and despite another AI live demo going a bit wrong, the sentiment with most is that AI is not just something to benefit end-users but something that can be used at all stages of software development.

Like many tech-centric companies, we are no strangers to AI’s benefits as we’ve previously blogged about a real-world application of AI/ML used here at ASOS and also our process of looking into new ways to use Gen AI through hackathons. Google’s recent announcements have all but reinforced our belief that the future is AI ✨

• Kotlin Multiplatform continues to thrive

Kotlin Multiplatform (KMP) are the words on many mobile developer’s lips right now. The ability to effectively share code between iOS, Android, Desktop and Web sounds almost too good to be true, but the KMP model is one that is growing in popularity and shows no signs of slowing down its adoption at scale.

Google recently announced a series of changes to some of their core Android ‘Jetpack’ libraries that allows their popular libraries such as ViewModel, Paging and Room to now be used in a KMP context. I/O Connect was an opportunity to revisit these announcements, see them in action and have a discussion with Googlers about their future plans for KMP support. As it was made clear in their presentations, Google is now fully endorsing ‘KMP for shared business logic between Android & iOS’ which is an exciting prospect for many mobile developers.

I am pleased to reveal that our mobile teams at ASOS have recently been exploring KMP for shared business logic between our iOS and Android apps and have been actively trialling the use of shared ASOS KMP libraries in our most recent Android release (with iOS coming very soon). If you’d like to find out more about how this went, our approach and results, then perhaps keep an eye out for a future blog post! 👀

• Performance in mobile is still key

Another key area of focus within Google’s Android ecosystem right now is that of app performance. I/O Connect was no exception with hands-on workshops and tech-talks focussing on performance libraries such as Baseline Profiles and Macrobenchmarks.

This was an awesome opportunity to chat, raise any issues and pair program directly with the Googlers involved in these libraries and had great feedback from all involved. Sadly, a conflict with another event commitment meant I wasn’t able to attend directly — but I am told it was incredibly useful!

App performance is something we are always looking to improve at ASOS and I am pleased to say we have a roadmap to introduce these libraries into the Android app in the very near future. Watch out Usain Bolt, we are coming for your speed record 🏃‍♂️💨

• The wider tech community continues to be impressive

With over 100 countries represented from across Europe, the Middle East and Africa, Google’s I/O Connect event embodied the very best of the tech community and brought together people who all share a common passion; To make the world a better place through technology.

ASOS is one of many companies that actively work with cutting-edge technologies, such as those announced at I/O, to deliver better results and experiences to our customers. We’ll continue to keep on top of the rapidly changing tech landscape and we are all excited to share more about our advancements in these areas in future posts!

In closing, I hope you found this insightful and join me in looking forward to seeing what else comes from the remaining I/O Connect events in Bengaluru — India and Beijing — China later this summer.

I hope to catch you at next year’s events wherever they might be! 🗺️

Hi, I am Ed Holloway-George an Android Lead here at ASOS and Google Developer Expert for Android. I joined the company in 2021 and when I’m not sweating buckets at developer events abroad, I can be found talking about Mobile Security or tweeting pictures of my dog 🐶

Here’s what we learned at Google I/O Connect Berlin was originally published in ASOS Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Melissa Perri — Becoming Truly Product Led

The day kicked off with the anticipated keynote by Melissa Perri; who delved into essential topics such as product strategy and operations, sharing anecdotes and real-world examples from her extensive industry experience and expertise. Melissa highlighted that companies are just doing too much and not focusing on the right thing for their customers. This has led to the tech industry experiencing 28k layoffs since 2023! From this, it is clear how important it is for organisations to have a product portfolio strategy and recognising that the product IS the business.

The mention of product operations (The discipline of helping your product management function scale well. Surrounding the team with all of the essential inputs to set strategy, prioritize, and streamline ways of working) sparked our interest, it is centred around data and enabling product teams to see everything they need to (something we’re REALLY passionate about as coaches!). Making it possible for self-serve data to exist will allow people to do research, make informed decisions and measure the impact of product initiatives.

1. Business and data insights — get the information out of systems and into the hands of people making decisions.
2. Customer and market insights — aggregate external research
3. Process and governance — leverage the skills and information for seamless collaboration

Product operations helps to translate a company strategy and goals into an actionable roadmap. Clearly mapping out an organisation’s planning processes is key for creating a balance between governance and agility.

Planning enablers

• Design the cadence of inputs, decisions and communications
• Generate alignment in initiatives
• Bring together the right product people and stakeholders for decision making
• Define key meetings: Set a fast-paced agenda with clearly defined meeting outcomes

We were so inspired by the talk we rushed to get a signed copy of Melissa’s new book ‘Product Operations — How successful companies build better products at scale’. A huge highlight for Dan 😊

Matthew Skelton — DevOps Topologies 10 Years on. What have we learned about silos, collaboration and flow

After a short break we attended Matthew Skelton’s talk on Team Topologies and his observations from the last 10 years. An interesting point and theme which appeared throughout the talk was the linking between Fast Flow (Quickly developing and releasing) and Cognitive Load (The amount of memory resources that are used or required for mental processes), Matthew clarified that success lies in addressing dynamic interactions, not building a perfect static structure.

Cognitive load appeared throughout the day in a variety of formats, however it’s clear the focus on Developer Experience (DevEx) is becoming more prudent within the industry. To support this, Matthew mentioned “The cost of tangled software” and the staggering impact (£100,000 per dev/year) of blocking engineers one hour a day on the operational cost of a company. To improve flow, we need to untangle our organisations, which in turn will decouple the software developed.

Matthew mentioned key metrics that team topologies has led to organisations uncovering as good measures to use around agility:

Key metrics (and what they monitor)

• Lead time — Flow (Elapsed time between the identification of a requirement and its fulfilment)
• Deployment Frequency — Flow (How frequently new code is deployed to production)
• Mean time to restore — Operability (Average time taken to recover a product or system failure)
• Change fail percentage — Operability (% of changes which lead to production failures)
• % of time building vs waiting — Flow Efficiency (% of time spent actively working on items vs waiting/blocked)

Understanding the problem — Matthew mentioned both Wardley mapping and Conway’s Law to highlight how complex org structures lead to highly complex products, which in turn cause increased cognitive load of developers. The greater the cognitive load on developers, the slower they are going to build and have a greater chance of unknowingly impacting another product or service.

Matthew provided an example where J P Morgan applied team topologies by mapping dependencies between teams and then actively worked to decouple teams wherever possible. This saw a 60% reduction in dependencies and a direct cost saving as teams experienced less delays. Similarly, the Home Office were able to reduce technology costs by 40% by making Product Owners account for the cost spent on their services, which instantly encouraged a cleaner split of teams and technology structure. This reinforced the message that cognitive load on developers significantly impacts flow and build and maintenance costs.

Emma Dahl Jeppesen — From assumptions to measured impact: Improving developer experience at TV2

Having split to cover more talks, Dan attended a session by broadcasting company TV2, which is used at least one hour a day by 85% of Danes. This session covered the topic of DevEx and how new measures have been introduced to highlight bottlenecks and pain points in the development process.

Emma referenced how TV2 previously introduced DORA metrics (Deployment Frequency, Mean Lead Time for Changes, Mean Time to Recover, Change Failure Rate) across the company as a way of monitoring performance. However, since the metrics were used as targets instead of simply measuring the trends (Goodhart’s Law), they noticed how teams would act in certain ways to game the metrics. An example of this was teams deploying multiple smaller chunks of code which should have been deployed together, this became apparent once tech leadership started to challenge why some teams were deploying less than others.

TV2 introduced qualitative surveys to gain a deeper understanding of how Developers are feeling and the flows work passes through before considered done. These surveys were highly welcomed and the insights allowed the organisation to focus on improving specific issues which blocked developers day to day such as streamlining the CI pipeline.

How can we utilise this approach ourselves?

• Value stream mapping — Research our developer’s journeys using both qualitative and quantitative data
• Ask Devs to walk through their process and how they’re feeling at each point, highlighting painful steps
• Review and update both As Is and To Be, continually measure if moving in the right direction
• Aim to implement changes as quickly as possible, validate and then continually improve. Don’t spend too much time planning the change (Better to monitor and adjust as you go)

Kristian Lindwall — Innovating at scale — Spotify’s experimentation journey

Later in the day we heard from Kristian Lindwall as he walked through the various ways in which Spotify focus on experimentation across the entire development journey. Throughout the talk, Kristian referred to “cultivating curiosity” by creating an environment which encourages autonomy, transparency and connectivity. An example of this was Spotify’s experimentation platform (ABBA), which enabled running tests on a far greater scale while also monitoring wider KPIs. This approach simplified how teams create and run tests, encouraging better development practices as testing was easy to do and provided insight to the wider impacts across Spotify.

The platform ABBA was formed from an experimental approach in Spotify to identify pain points in the dev process. By taking an experimental approach, Spotify was able to identify and focus on the largest problems. After several iterations, the platform was able to separate experiments from flags, measure metrics and coordinate experimentation within a single tool. Spotify’s confidence in the tool has enabled them to package and sell ABBA as a separate product entirely, this is something that we’ve talked about previously in this blog, such as @Scott Frampton (in Medium you could tag him) and the journey with fundamentals or @Callum Trounce post on how we embrace experimentation.

Whilst this talk was heavily focussed on the experimentation platform created by Spotify, it did reinforce their constant focus on experimentation and continuous improvement. By taking time to understand the developer’s experiences, they have reduced complexity and simultaneously create a product which has introduced additional revenue streams.

Sven Peters — Developer Joy — How great teams get s&#t done

The final talk we went to was all about improving developer experience, Sven Peters from Atlassian calls this “Developer Joy”. Over the past 10 years the cognitive load of developers has significantly increased as technology advanced and they became responsible for much more than just writing code. The question of how to measure developer productivity arose and almost has become an obsession with leaders.

We travelled back in time with Sven to remind ourselves that software development is not the same as a production line so productivity cannot be measured in the same way. At Atlassian, the team thought about what improves the developer experience and what brings them joy, measured it through satisfaction surveys and then handed over the information to the actual teams to solve (not a productivity committee!).

What they found was that if developers can work on great quality code and it can flow through with reduced waiting time as well as getting customer feedback, then developer joy emerges.

An example of changes made at Atlassian includes addressing the Quality Assurance (QA) ‘wait time’. The team found that they had a QA to developer ratio of 1:30 which created a bottleneck in their flow, so they pivoted the role to be Quality Assistance. This change in remit meant the QA role would do a kick off work with developers and coach them to carry out better testing and write test plans. This enabled the developers to carry out testing themselves, leaving the QA role to run test environments and reduce the developer cognitive load.

Steps taken to improve developer joy

1. Ask your developers how satisfied they are — use surveys
2. Give the teams time (10–20%) to solve developer issues
3. Spread the learnings across teams so others can benefit from improvements

Key Learnings

We felt there was a lot of connection between the talks we went to, one of which being that unlocking flow in an organisation and a developer’s journey creates both cultural and financial benefits.

We were reminded how important it is for successful businesses to recognise not only customer but also developer experience when creating valuable products. Further supported by the role of leaders when creating organisational structure, our thinking must span beyond the products and instead encompass the supporting structures and systems to ensure we are able to pivot quickly as needed.

About Me

I’m Dan Dickinson, an Agile Coach at ASOS. I help guide platforms and domains through our continuous improvement journey, utilising data and insights to drive better behaviours, processes and mindset. Outside of work I’m a Dog Dad, Golfer and Scuba Diver.

Observations from the London DevOps Conference 2024 was originally published in ASOS Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.