DEV Community: mobile.IT

Unearthing the Quirk: Dealing with File Access Issues that arise from Resource Optimization in Android Applications

mobile.IT — Thu, 04 Apr 2024 10:16:07 +0000

While technological advancements often make processes more efficient, they can sometimes introduce unexpected challenges. This is exemplified by the Android Gradle Plugin from version 4.2 onwards, which introduced resource optimization. This process is designed to reduce APK size and increase efficiency, but it also includes changes to file names in the resources directory.

For instance, if an Android application is designed to read localization strings from files stored in the raw subdirectory of the resources folder using a file path, this optimization process could create an obstacle. After the optimization process concludes, the file path could be obfuscated, changing, for example, from res/raw/strings.xml to something like res/Gh4.xml. This unexpected change can cause issues with accessing the required files.

For further information about these optimizations, you can refer to Jake Wharton’s detailed article titled Smaller APKs with Resource Optimization. This write-up provides a deeper understanding of the resource optimization process in Android development, which is central to the issue discussed in our article.

When Optimization Gets Tricky

During its operation, Gradle executes the ‘optimizeReleaseResources’ task which entails invoking the Android Asset Packaging Tool (AAPT) binary to operate on the assembled APK file.

For a more detailed look into the specifics of how this task operates, you can refer to the source code available on Google’s Android Project repository.

The optimizeReleaseRes task executes the following lines of code:

and maps enum values to the following AAPT parameters:

The AAPT documentation describes these parameters as follows:

It becomes evident that these parameters are at the heart of the issue that hinders the direct access of files by their names from the code.

However, as it stands at the time of writing this article, with the Android Gradle Plugin in version 8.3, Gradle does not provide an explicit way to control these parameters via its configuration settings. This means developers are required to employ other approaches to tackle this side effect of resource optimization.

Don’t worry, there are multiple potential solutions available to circumvent this issue.

Option One: Turning Off Resource Optimizations Using the Gradle Flag

The first method for resolving this issue involves the use of the android.enableResourceOptimizations=false flag. Adding this flag to the gradle.properties file effectively disables the resource optimization process and thus resolves the issue.

Pros: This solution is straightforward and can be implemented with a single line addition to your Gradle configuration.

Cons: This flag is set to be deprecated in the upcoming Android Gradle Plugin 9.0. With that in mind, this solution serves as a temporary fix and may not be applicable in the future.

Option Two: Anticipating the Forthcoming Solution from the Android team

An active issue on Google’s issue tracker reflects ongoing development to provide a way to disable specific optimizations by adding buildTypes options based on the AAPT2 Optimize suboperations. This suggests that they plan to include a provision for explicit configuration before the version 9.0 release.

Pros: This approach would only necessitate minor changes in the Gradle configuration.

Cons: As this development is still in progress, the solution is not available at the moment.

Option Three: Moving Files Outside the Resource Directory

Another straightforward solution involves moving the resource files from the /res directory to a different location, such as the /assets directory. This is a viable option because the optimization process only affects files within the /res directory.

Pros: This method offers a quick fix to the issue.

Cons: It disrupts the more standard practice of maintaining all resources within the /res directory. This inconsistency could potentially lead to confusion in large-scale applications or teams.

Option Four: Resource Path Mapping

Another approach involves deriving a mapping that converts the original paths back to their changed names and locations. This provides a way to navigate resources as if they’ve not been altered.

This might be implemented as a Gradle task that calls an AAPT to generate the mapping.

Running aapt2 dump resources command produces information about the resource files as follows:

This mapping is expected to remain consistent across multiple iterations of the build, but it should be checked each time the list of resources is altered.

The Gradle task can be performed manually or incorporated into CI processes. It involves running a script each time resources change. Since the mapping is required at runtime, it must be included in the APK. Therefore, the APK assembly process should be done twice: first to build the APK and then to include the mapping. As a result the original file path can be used in the code to retrieve the obfuscated file path. Collapsed resource names remain the same, so running the assemble task twice will only be required if the resources have been modified.

Pros: The files can remain at their current locations at /res directory.

Cons: It requires running an APK file with the AAPT executable’s dump parameter, creating the need for additional Gradle tasks. If more resource files are added or renamed in future builds, this solution may not hold up.

Option Five: Providing a Custom OptimizeReleaseResources Gradle Task

The last solution is a more ambitious one. Implementation would require modifications of the task we need to optimize, as well as all dependent tasks. This strategy allows us to possibly disable undesired sub-operations of the optimization process.

Moreover, there is a more specific method to exclude certain files from the optimization process. Particular resources can be exempted using the no_collapse directive in a file defined by --resources-config-path. The specified path leads to a resources.cfg file that lists resources along with directives for each one. The expected format for providing directives is: type/resource_name#[directive][,directive]. In our scenario, it would be xml/strings#no_collapse.

Pros: This approach addresses the issue in a manner similar to a planned solution on AGP side described as Option two…

Cons: This complex solution requires an in-depth comprehension of related Gradle tasks and involves the creation of a custom chain of Gradle tasks. It’s worth noting that altering or extending internal tasks of the Android Gradle plugin is generally not advised due to potential stability, compatibility, and support issues.

Wrapping Up The Tale

While stumbling across such issues can feel like landing in a labyrinth, knowing that there are possible workarounds can equip you with the necessary solutions to navigate your way successfully.

The puzzle of accessing obfuscated resource files might seem challenging. But remember, every problem in Android development is just another opportunity for mastering the craft.

Let’s keep pushing the boundaries, one line of code at a time.

Written by Ivan Roshchynskyi #seniorandroiddeveloper

Context Switching pt.5: Long-Term Approach

mobile.IT — Thu, 07 Mar 2024 10:26:24 +0000

This is the last part of our series about context switching. In this post, I'd like to have a more distant look at the sustainability of our work practices and habits and wrap up the whole series.

So far I've omitted an aspect that has become an integral part of our modern work culture: remote work. We'll look at how working away from the office affects our ability to switch contexts effectively and explore ways of staying productive and mentally healthy in the ever-blurring lines between our professional and personal lives.

Benefit from Compounded Improvements

Before we get into the intricacies of remote work, let's pause for a moment to consider a philosophical perspective on change and improvement. Often, we encounter opportunities for minor adjustments in our habits or routines. These changes might seem trivial at first glance, leading us to question their worth. Yet, it's in these small shifts where transformative potential lies.

Take, for instance, the inspiring story of the British cycling team. Their ascent from obscurity to global dominance in the cycling world is a testament to the power of incremental change.

It's a tale of how small, seemingly insignificant changes can lead to monumental victories. This approach, often referred to as the "aggregation of marginal gains", was used by Sir Dave Brailsford, the performance director of British Cycling. Brailsford believed that by making a small improvement in a variety of areas, the cumulative benefits would lead to significant enhancement in overall performance.

Before Brailsford's tenure, British Cycling had experienced very limited success and was an outsider at competitions.

The results were extraordinary. British cyclists dominated the 2008 and 2012 Olympic Games and won the Tour de France multiple times, starting with Bradley Wiggins in 2012.

This success hanged on a simple yet profound idea: improve everything you do by just 1%.

It wasn't just about pedaling faster or longer; it was about refining every detail, from the ergonomics of the bike seat to the way cyclists washed their hands.

It's about seeking out those tiny victories, knowing that they add up. Just like the British cyclists, who turned marginal gains into gold medals, anyone can turn small, consistent improvements into remarkable success stories.

Let's take this idea into everyday life. Imagine if every aspect of your work process got just a bit better - code quality improves bit by bit, build times get slightly faster, team communication becomes a tad clearer, and you need to update one less status manually. Investing time to find improvements that help you have one less context switch every hour will probably have a noticeable benefit on your energy levels over time.

These small improvements might not make headlines on their own, but collectively, they can propel a project to a higher level of efficiency and quality.

Remote Work Culture

The shift to remote work, accelerated by recent global events, has fundamentally transformed our professional environments. While this transition offers flexibility and eliminates commutes, it also brings unique challenges in managing context switching. In our homes, the boundaries between work and personal life blur, creating a fertile ground for increased task-switching and potential productivity pitfalls.

Remote work environments differ significantly from traditional office settings. At home, the distractions vary from family interactions to household chores, each demanding attention and contributing to frequent context switches. Unlike the controlled environment of an office, home settings require individuals to self-regulate their focus. It requires not just a physical adjustment, but also a significant mental shift.

The isolation and lack of direct supervision can lead to feelings of disconnection and uncertainty. This psychological aspect of remote work is crucial to understand, as it directly influences how individuals handle context switching and maintain productivity.

In remote work, reliance on digital communication tools skyrockets. Emails, instant messages, and video calls become the primary means of interaction, each with its potential for interruption. The constant barrage of notifications from tools like Slack, Microsoft Teams, or email can fragment attention, making it challenging to engage in deep, focused work. This digital communication overload often leads to a paradox where workers are simultaneously more connected yet more isolated than ever before.

One of the most significant psychological challenges of remote work is the sense of isolation. Without the casual interactions and social cues of an office environment, workers may feel disconnected from their team and organization. This isolation can lead to a decrease in motivation and engagement, making context switching more challenging due to a lack of immediate collaborative feedback. Remote workers might feel cut off from their colleagues, leading to a sense of loneliness and decreased job satisfaction.

Strategies for Reduction of Context Switching While Working from Home

Developing strategies that reduce context switching in the short term is essential, but considering the long-term impact on mental health, productivity, and work satisfaction is crucial for sustained performance. Managing context switching effectively over the long haul can prevent burnout and promote a healthier work-life balance.

To combat the unique context-switching challenges of remote work, consider the following strategies:

Establish Routines: Creating regular routines can reinforce healthy work habits. For example, starting the day with the most challenging tasks when cognitive resources are at their peak can help maintain high productivity levels throughout the day.
Promote Work-Life Balance: Encourage clear boundaries between work and personal time. Discourage the habit of checking work communications after hours, which can lead to mental fatigue and impede the ability to recharge fully.
Foster a Culture of Focus: Cultivate a workplace culture that values deep work and focused attention. Implement policies that reduce unnecessary meetings and encourage concentration, such as quiet hours or no-interruption zones.
Find Your Peak Hours: Analyze your work patterns and habits over a week to identify peak productivity periods. Track your productivity over a week. Note the times when you feel most focused and energetic. These are likely your peak productivity hours. Try to schedule demanding tasks during these peak times and use the tool to block these periods for focused work.
Creating a Work-Only Zone: Establish a designated area in your home exclusively for work. This physical separation helps in mentally distinguishing between 'work mode' and 'home mode', reducing the likelihood of context switches due to household distractions.
Ergonomic Setup: Invest in an ergonomic chair and desk. Comfortable and supportive furniture reduces physical strain, allowing for longer periods of focused work. Make sure the computer screen is at eye level and that you have adequate support for your back and wrists. An external screen is a must if your primary work tool is your laptop.
Structured Schedule: Maintain regular work hours to create a sense of stability and routine. This structure helps in mentally preparing for work and winding down, clearly demarcating work time from personal time. This helps support the creation of routines and habits, leading to less mental overhead.
Mindful Communication: Be deliberate about digital communication. Set specific times for checking emails and messages to avoid constant interruptions. Utilize status indicators on communication tools to signal availability and focus times.
Breaks and Personal Time: Regular breaks are crucial, especially in a remote setting. Step away from your workspace for short periods to clear your mind. This practice helps in maintaining focus and reducing mental fatigue from prolonged periods of concentration.
Virtual Collaboration Etiquette: Establish clear guidelines for virtual meetings and collaborative work. This includes respecting agreed-upon meeting times, being mindful of different time zones, and ensuring that digital collaborations are purposeful and efficient.
Minimize Distractions: Identify and minimize potential distractions in your home environment. This might include noise-canceling headphones to block out household noise or using apps that limit social media access during work hours.
Adequate Lighting: Ensure your workspace is well-lit, preferably with natural light. Good lighting reduces eye strain and improves mood and energy levels.
Start-of-Day and End-of-Day Routines: Create a routine to mark the start and the end of your workday, such as a short walk or a closing ritual. This helps in mentally transitioning out of work mode.

Key Takeaways

We made it to the very end of this series. I hope the strategies and tips shared across these posts will help you in taking control of your workday and reclaim the cognitive energy so often depleted by the fragmented nature of modern work environments.

There was a lot covered, so before we finish, here are a few of the most important tips:

Identify your context switches to understand what causes you to switch tasks.
Set priorities using approaches like the Eisenhower Matrix.
Block time for your most important tasks.
Set aside specific times to check emails and messages. Use 'Do Not Disturb' settings in communication tools or simply switch the notifications off permanently.
Batch similar tasks together.
Try day theming to dedicate specific days to specific projects.
Schedule breaks into your workday.
Integrate key apps to reduce the need to switch between them.
Implement no-meeting days or periods to reduce meeting-related context switching.

Written by Otakar Krus #scrummaster

Context switching pt.4: Team Dynamics and Organizational Approaches

mobile.IT — Thu, 29 Feb 2024 10:21:09 +0000

The approach to context switching can vary significantly across different workplace cultures. In some environments, deep work and minimal interruptions are highly valued, fostering a culture of sustained focus. In contrast, other workplaces might prioritize responsiveness and agility, with a higher tolerance for multitasking and frequent switches in attention.

This is part 4 out of 5 of a series about context switching.

Regain Transparency

The ability to construct and adhere to an effective task management framework is an invaluable skill in today's multitasking work environment.

Enhancing the visibility of work is a strategic move that can significantly ease the cognitive strain of context switching. When we've got a clear picture of our tasks and their statuses, making transitions between them becomes more manageable, and our focus can remain sharper. Here's how you can shine a light on your work processes:

Use Visual Management Tools: Kanban boards or other visual task management tools allow you and your team to see the flow of work at a glance. This transparency helps to prioritize and pull work strategically while reducing the overhead of determining what to work on next.
Create a Single Source of Truth: Centralize documentation, project plans, and progress tracking so that switching contexts doesn't mean digging through disparate sources to find the information you need.
Hold Regular Check-ins: With regular check-ins or stand-up meetings, team members can briefly update each other on what they're working on, align priorities, and ascertain when uninterrupted work time is necessary.

Greater visibility of work can lead to improved team dynamics as everyone is aware of the bigger picture and can adapt to reduce bottlenecks or overlaps. This clarity not only enhances productivity but also alleviates the stress associated with uncertainty in task management.

By making work more visible, you minimize the time and cognitive load spent on catching up or reorienting when switching tasks. This fosters a rhythm of work where transitions are smoother, less energy is wasted, and more cognitive resources can be devoted to the task at hand.

Task management tools can be your ally in the fight against the chaos of context switching. These applications help you organize tasks by project, priority, and deadline, thereby clarifying what needs your attention and when.

A unified framework for task management within your team can greatly reduce friction: Use a shared platform where all team members track and update their progress, reducing the need for disruptive check-ins and updates.

That's why transparency and visibility of all work is a frequently used practice in agile development.

Software Development Specifics

Specific tactics can be adopted that align well with agile methodologies and the general nature of development work.

Deep Work during Sprints: Portions of sprints dedicated solely for uninterrupted coding or testing, akin to the concept of 'hackathons.' These can be interwoven with more “collaborative” portions.
Clear Sprint Goals: Ensuring that sprint goals are well-defined and understood by all team members help minimize the need for context switching related to clarifications or priorities.
Feature Branching: By using a branching strategy tailored to your team's needs, you can minimize the disruption caused by frequent merges.
Regular Commits: Encouraging smaller, more frequent commits can make merges less daunting and reduce the cognitive overhead associated with integrating large amounts of code.
Pair Programming: Having two developers work together on the same task can help keep them focused on the task at hand, reducing the likelihood of context switching.
Integrating Workflows: Leverage integrations between different tools to create a more seamless workflow. For example, linking your project management tool with version control systems like GitHub or GitLab can automate the tracking of progress and reduce the need to manually update the status of development tasks.
Automation of Repetitive Tasks: Where possible, automate repetitive or administrative tasks. If you find yourself repeatedly doing the same task when switching contexts, consider if a tool could handle it for you to save time and reduce cognitive load. Tools that automate processes like code deployment, testing, or even email sorting can free up mental space, allowing professionals to focus on more complex and meaningful work without constant interruptions.
Unified Communication Platforms: Use tools like Slack or Microsoft Teams that can integrate directly with your project management software. This allows for real-time updates and conversations around work items to be centralized and easily accessible, preventing the need for context switching between communication and task-tracking platforms.
Create communication tool policies: It might be useful to designate individual communication tools for information and requests with a certain urgency. For instance, only use private messages in platforms like Slack for information that requires a timely reaction. Use common Slack channels for less urgent topics. And for items that can wait a day or two, use email. This principle can leave you at peace knowing there is no need to check your email every half an hour because your colleagues don't expect the answer that fast. Otherwise, they would use a different communication channel..
Self-reflection: Encourage team members to reflect on their most productive periods and identify which types of task switches are most jarring or disrupt their flow.
Minimize Work in Progress (WIP): Limit the number of tasks or features developers are working on simultaneously. Tools like WIP limits in Kanban can be particularly effective in controlling the pace and amount of context switching.
Standardize Coding Practices: Simplify and standardize development processes to reduce cognitive overhead. This might include implementing consistent coding standards.

Setting Clear Boundaries and Expectations

It's crucial not to overlook the human aspect – setting boundaries and communicating expectations can significantly influence task management:

Clearly communicate your availability and work hours to teammates, and respect theirs, to reduce interruptions.
Designate 'quiet hours' or 'focus time' where the team agrees to limit communications to only urgent matters, allowing deep work to take priority.

By establishing and maintaining a structured approach to managing tasks, you can create a work environment conducive to focus and productivity, significantly reducing the occurrence and impact of context switching.

Implementing "Focus Hours"ň

Organizations can cultivate a culture of deep work by implementing 'focus hours'—designated times during the day when interruptions are minimized, and team members are encouraged to engage in uninterrupted work. This practice not only enhances individual productivity but also fosters a collective respect for focused work time.

Reducing the number of unnecessary meetings can have a profound impact on reducing context switching. Encouraging concise, well-planned meetings and discouraging impromptu or non-essential gatherings can free up significant amounts of time, allowing employees to engage in more sustained, focused work periods.

Reserve Mornings for Code: Mornings designated as a no-meeting period, dedicated solely to coding and critical development work. This move capitalizes on the fresh energy levels and fewer distractions early in the day.
Afternoons for Collaboration: Afternoons set aside for meetings, code reviews, and collaborative work, reflecting a more natural dip in concentration levels.

Clearly defined times for checking messages to prevent constant notifications from interrupting developers' flow.

Conclusion

The key lies in balancing structured processes with individual flexibility. Integrating visual management tools, embracing agile methodologies, and setting clear boundaries, help to enhance transparency and focus. Implementing 'focus hours' and reducing unnecessary meetings further consolidates this approach, allowing for deeper work and minimizing cognitive overload.

In the next (and last) part we'll gaze into the future to try to find an answer on how to build habits that save context-switching costs in today's remote working environment.

Written by Otakar Krus #scrummaster

Context Switching pt.3: Personal Techniques to Maintain Mental Clarity

mobile.IT — Fri, 23 Feb 2024 09:41:57 +0000

In my previous posts, we delved into the nature of context switching and its impact on productivity, (not just) within software development. Armed with that knowledge, it's now time to pivot from diagnosis to finding solutions. Today's post is dedicated to the strategies and pragmatic measures we can employ to master the disruptive forces of context switching. We'll explore various techniques that have proved valuable in combating this productivity drain.

Strategies for Maintaining Mental Clarity and Productivity

Now, let's explore techniques to combat the cost of context switching. These methods seek to maintain mental clarity and boost productivity, acting as a defensive bulwark against the onslaught of interruptions.

Prioritized Task Management: One of the most effective strategies to stave off the ill effects of context switching is to prioritize tasks. By categorizing work into urgent, important, and less critical, you can focus on what truly matters without the constant shift in priorities. Utilize tools like the Eisenhower Matrix to help in this process.

Time Blocking: Carve out specific time blocks dedicated to singular tasks or types of work. This method not only promotes deep work but also sets clear boundaries around when you are available for collaboration or meetings.

Controlling Notifications: In the age where every app vies for your attention with incessant notifications, take proactive measures to mute or schedule them. For example, use the 'Do Not Disturb' mode during your deep work sessions to prevent unnecessary digital interruptions.

Batching Similar Tasks: Grouping similar tasks together can reduce the cognitive load of switching gears. For instance, handle all your code reviews at a designated time or set aside a block for administrative tasks. Separating complex tasks that require deep focus from more routine, less demanding tasks. This allows your brain to engage with each type of activity without the burden of constant gear-shifting.

Streamlining Communications: Communication is vital, but it can be a significant source of context switching. Define clear windows during the day when you check and respond to emails and messages. This confines communication to specific times, minimizing the interruption to your primary work.

Identifying Triggers: Recognizing what prompts you to switch contexts can help preempt unnecessary breaks.

Structured Procrastination: If certain tasks are a frequent source of self-interruption, allocate specific times for them, minimizing their intrusion into more critical work periods.

All these strategies underscore one thematic resolution: to establish a structured approach to your workday that respects the need for focused, uninterrupted time. Not only does this shield you from the adverse effects of context switching, but it also paves the way for a more ordered and productive professional life.

Eisenhower Matrix

The Eisenhower Matrix, a time management tool named after President Dwight D. Eisenhower, is particularly effective for prioritizing tasks based on their urgency and importance. This matrix divides tasks into four categories:

urgent and important
important but not urgent
urgent but not important
neither urgent nor important

In software development, an example of an "urgent and important" task could be fixing a critical bug that's causing a system outage, as it directly impacts the functionality and user experience. An "important but not urgent" task might involve refactoring code to improve maintainability, which, while not pressing, significantly enhances long-term project health.

"Urgent but not important" tasks could include responding to non-critical emails that require timely replies but don't contribute directly to development goals. Lastly, tasks that are "neither urgent nor important" might include attending optional meetings that don't directly relate to current project objectives. Categorizing tasks can help more effectively allocate time and resources, ensuring that critical issues are addressed promptly while also making room for strategic, long-term improvements.

Personal Experimentation - Finding What Works for You

Despite the array of techniques to curb context switching, there is no one-size-fits-all solution. For this reason, an essential element in mastering one's workflow is personal experimentation. Trying different strategies and observing their impact on your productivity and well-being is key to customizing an approach that aligns with your cognitive style and work responsibilities.

Experiment with Focus Techniques:

Regular Breaks: Integrate short, regular breaks into your schedule to clear your mind and avoid cognitive overload. The Pomodoro Technique is one method that incorporates this idea effectively. Work for 25 minutes, then take a 5-minute break. This can increase focus by creating urgency and allowing regular breaks to recharge.
Day Theming: Assigning different themes to your work days can help you maintain a clearer focus. For instance, you might dedicate Mondays to development work, Tuesdays to meetings and for administrative duties, and so on.
Adjust Communication Habits: Is it really necessary to have your email ding every time something arrives in your inbox?
Try checking emails only at certain times. Observe how this affects your ability to concentrate on tasks without the anticipation of upcoming communications.
Manage Your Environment: Physical and virtual workspace organization can have a significant impact on your focus. See how decluttering your desk or desktop affects your ability to switch between tasks.
Physical Exercise
Beyond organizational strategies, personal health, particularly regular physical exercise, plays a crucial role in combating the effects of context switching. Activities like jogging, yoga, or even brisk walking can enhance cognitive function and focus, providing a natural buffer against the mental fatigue caused by frequent task-switching.
Mindfulness and Meditation: Regular mindfulness practice helps train your brain to focus on the present moment, reducing the mental clutter that often accompanies task switching. This not only improves your ability to concentrate on a single task but also helps in quickly regaining focus after an interruption. Science has shown that 2 things are especially effective for mental resting: a swift walk and looking at details in nature (like shapes of leaves, colors of birds or movement of clouds). You can try doing this during your breaks while resisting the urge to check your Facebook. It helps to mentally recover for upcoming work.

Studies suggest that switching mindsets may be less disruptive than switching tasks, an interesting notion worthy of exploration. While you may not be able to reduce the number of tasks, changing your approach to how they're tackled – emphasizing mindset rather than the tasks themselves – could result in a smoother transition between them.

Personal experimentation with these strategies can also lead to better self-awareness concerning how context-switching affects you individually. What works for one person may not work for another, and understanding your unique responses to task-switching can inform a more personalized and effective workflow.

A Practical Tip for Swift Task Resumption

What if all mitigation failed and you got interrupted? I got a tip for you.

A counterintuitive yet effective practice for speeding up the resumption of work after an interruption is to leave a task exactly as it is, even if it means stopping mid-sentence or leaving a logical piece incomplete. Resist the urge to “finish” the sentence or thought before you leave.

This approach, as extreme as it may sound, creates a cognitive bookmark that makes it significantly easier to pick up right where you left off, thereby reducing the time and mental effort needed to reorient yourself back into the task. You simply reread the preceding text and continue with a single following word. Because it is a much smaller piece of puzzle to fill in as opposed to starting a completely new paragraph, it makes it easier to get moving.

Conclusion

As we wrap up this first part of our exploration into personal strategies for managing context switching, remember that the key lies in structured, prioritized task management and setting clear boundaries for deep work. Stay tuned for our next post, where we'll dive into team techniques and strategies to handle context switching.

Written by Otakar Krus #scrummaster

Context Switching pt.2: Psychological factors

mobile.IT — Thu, 15 Feb 2024 11:01:54 +0000

Welcome back to our series on context switching. In the first part, we explored the fundamental aspects of context switching, its impact on productivity, and the cognitive challenges it presents, especially in the area of software development. Now, in this second post, we turn our attention to the psychological dimensions of context switching. We'll delve into how it affects mental health and work quality, the signs of an overwhelmed context-switching capacity, and the personal and team dynamics that influence its impact.

The Neuroscience of Task Switching

To truly grasp context switching, we must delve into the realm of cognitive science and understand the neural mechanisms at play. A study by Santiago Galella and Salva Ardid in 2023 casts light on the neural gymnastics involved in task switching. They describe it as a cognitive control challenge—our brains effectively 'rewire' themselves in realtime to manage the demands of different tasks.

Task switching involves a network of brain regions that include the prefrontal cortex—a command center for executive functions—and the posterior parietal cortex, which integrates sensory information. When we switch tasks, these areas must work together to suppress the rules and goals of the previous task and activate those relevant to the new task. This activity represents a significant overhead and can be visualized through neuroimaging techniques.

Moreover, Galella and Ardid highlight the impact of context inputs, suggesting that the surrounding environment can aid or hinder the brain's ability to switch tasks. For instance, a cluttered workspace with multiple visual stimuli can exacerbate the cognitive control required to switch tasks effectively compared to a minimalist and orderly environment.

In essence, understanding these neural representations and the cognitive control required for task switching can help us comprehend why context switching is burdensome and how we might mitigate that by manipulating our work setup and conditions.

Psychology and neuroscience research by Harvard Business Review shows that jumping between tasks is cognitively taxing and can significantly impact productivity and mental well-being. This strain on cognitive resources, the research speculates, is rooted in our brain's finite capacity to process and hold information 'in mind' at any given time, leading to strain when switching between multiple tasks or topics.

Every time we switch tasks, we incur a "cost" that can deplete our cognitive reserves. When we context switch, we're drawing from our limited pool of cognitive resources. Each transition requires reorienting our mental framework to accommodate a new set of variables and challenges, akin to reprogramming a computer for a different task. Cognitive psychologists have found that the act of context switching can deplete our focus, attention, and working memory capacity—vital components for effective software development. Meanwhile, crucial moments of insight could be slipping through the cracks as they attempt to regain their flow. Applied to a typical workday with numerous interruptions, we’re talking about a substantial cumulative effect on productivity.

Intensified Cognitive Load Under Time Pressure

Imagine you're working on a task and you know there's a meeting in 15 minutes. This awareness alone can heighten the cognitive load. You're not just dealing with the mental shift of context switching; you're also racing against the clock. Research indicates that such time constraints can force us into a mental shortcut mode, where we might not process information as deeply as we would under less pressure.

With an eye on the clock, the quality of your work during these switches can suffer. You might find yourself skimming through tasks rather than engaging deeply, as you would if time weren't a factor. This hurried approach can lead to mistakes or incomplete work, especially in fields requiring high attention to detail, like software development.

Knowing that both context switching and time pressure can be mentally taxing, planning your day with these factors in mind becomes essential. This might mean scheduling deep-focus work during quieter hours or setting realistic expectations for what can be achieved within given time frames.

While occasional deadlines and periods of time pressure might increase one's performance, it is important to use this tool with caution. Time pressure is usually understood as a project deadline or a release date, but I believe it's important to view it in its broader context. Even seemingly trivial time restrictions like an approaching meeting, a fixed departure of a train home, or colleagues waiting for me to join them for lunch are time pressures on their own.

The presence of an impending deadline or a tight timeframe can indeed amplify the cognitive cost of context switching. It's not just the switch itself that matters, but also the environment and time constraints within which it occurs.

Addressing the Elephant in the Room: Productivity and Software Quality

Let’s not forget the implications for software quality. As the cognitive load increases due to frequent interruptions and context switches, so does the propensity for errors. The mental 'loading time' to retrieve all the relevant details surrounding their task can lead to oversights. As studies highlighted, this decreased efficiency is a straight road to a higher likelihood of bugs and poorly implemented features, affecting not just productivity but the integrity of the end product.

Frequent task switching in software development doesn't just slow down the process; it introduces a higher likelihood for errors. The connection between interrupted work and reduced quality underscores the importance of fostering environments where deep, uninterrupted work is possible. The tenacity needed to track down a tricky bug or refactor a critical module is substantially undermined every time the developer's attention is diverted. The more our cognitive load is taxed, the more prone we become to mistakes, and in the context of software development, these errors are not just mere slip-ups; they can lead to critical system failures or security vulnerabilities.

The drawbacks of context switching extend beyond just immediate productivity dips—they also have a tangible influence on the quality of the work produced and the mental health of those producing it. This dual impact demands a nuanced approach that accommodates both organizational goals and personal well-being.

A codebase is a reflection of the concentration and care placed into it. When developers are pulled away mid-thought, mistaken logic or coding errors are more likely to creep in. Frequent context switching has been shown to reduce efficiency, and the reduced attention to detail can lead to subtle but critical bugs. A study by Shakeri Hossein Abad et al. (2018) emphasizes that context switching significantly contributes to an increased likelihood of defects and technical debt.Constant context switching not only affects immediate productivity but also has implications for long-term memory and learning. Cognitive psychology suggests that when our brain is frequently interrupted, it hampers the process of consolidating information into long-term memory, thereby affecting our ability to learn and retain new knowledge effectively.There's a compelling incentive, then, to build frameworks that shield our developers from the barrage and give them the space to cultivate deep work. This might manifest as implementing policies that recognize the value of uninterrupted time, formalizing code review processes to catch errors that slipped through context-switching cracks, or leveraging pair programming to maintain a shared context and reduce cognitive load.

Signals of an Overwhelmed Context-Switching Capacity

The toll exacted by context switching isn't exclusively measured in moments of lost productivity—it's also captured in the subtle deterioration of our mental stamina.

How to know you're having too many context switches? Atlassian Blog points to signs symptomatic of a troublesome context-switching load:

Missing details: when details start slipping through the cracks
Difficulty in starting tasks: procrastination or a heavy sense of dread when it comes to initiating tasks
Habitual deferring of simple tasks

These signals may well be red flags indicating that our cognitive capacities are overstretched. Each of these signals points to a strain that goes beyond mere task-related stress; it infiltrates deeper levels of cognitive operation, affecting how we manage information, make decisions, and proceed with our work.

Frequent context switching can have a long-term impact not just on productivity, but in severe cases mental health, and overall work satisfaction can suffer too.

Mental Health: The Silent Sufferer in the Shadows

Beyond tangible productivity metrics, context switching exerts a less visible but equally concerning toll on mental health. The Atlassian Blog and Spike's analysis of workplace productivity discuss the fatigue and stress that arise from frequent task switching. The constant demand to recalibrate one's frame of mind can lead to burnout and reduced job satisfaction over time.

43% of workers report feeling fatigued by the act of juggling multiple tasks, highlighting the mental cost associated with context switching.

Personal vulnerability factors, such as stress levels and individual resilience against interruptions, significantly influence how people handle context switches. Moreover, recognizing and adapting to the unique interaction patterns within a team—some members might prefer segmented work blocks while others thrive on dynamic task juggling—can help managers allocate work more optimally, minimizing involuntary context switching.

Key Takeaways

Context switching incurs a cognitive tax that significantly hinders productivity and quality of work, demanding meticulous management.
Self-interruptions are often more disruptive than external ones, thus necessitating strong self-discipline and structured work habits.
Agile environments, while collaborative and dynamic, can amplify cognitive challenges during task transition, making tailored mitigation strategies crucial.
Technological advancements such as automation in tooling offer promising avenues for easing the cognitive burden.
The dual impact of context switching on software quality and mental health underscores the need for a balanced approach that promotes both professional performance and personal well-being.
Understanding individual and contextual factors that affect the disruptiveness of task switching is key to crafting personalized strategies for each team member.

By watching for the strain signals, we can take timely measures to counterbalance the cognitive load, such as implementing more rigid task prioritization, streamlining workflow processes, or simply taking more frequent breaks to refresh the mind. Recognizing the signs is the first step towards effecting a change in our work habits and environment to preserve our mental agility.

Conclusion

We've explored how the cognitive load intensifies under time pressure, the impact on software quality, and the subtle yet significant toll it takes on mental health.

In our next post, we will focus on practical mitigation strategies. We'll explore tips to manage the cognitive tax of context switching more effectively as individuals.

Written by Otakar Krus.

Context Switching pt.1: What's the Cost?

mobile.IT — Wed, 31 Jan 2024 16:15:39 +0000

In today's fast-paced world, where multitasking is often glorified, context switching is an unavoidable aspect of both our professional and personal lives. Companies often even state a requirement for the ability to multitask in their job advertisements.

The tendency to rapidly shift from one task to another has become a defining characteristic of contemporary work environments, more so in the complex world of software development.

As much as we'd like to believe that juggling multiple tasks simultaneously is a hallmark of efficiency, evidence suggests otherwise.

This is the first part of a series on the topic of context switching. Today, we're addressing what context switching actually is, why it is a problem, and what its true cost is. The goal of this first blog post is to examine the depths of context switching, look at its broader implications on productivity and quality of work, and start laying the groundwork for practical mitigation strategies.

In the following parts, we're going to have a look at the psychological and scientific aspects and then cover tips and practices that may change the way you approach your day-to-day activities.

What is Context Switching?

At its core, context switching refers to the process of moving from one task to another and adjusting our mental context accordingly. You've likely heard the term context switching tossed around in workplace conversations or across productivity forums, but do we really grasp what it entails?

In software development, it typically means moving from coding to a meeting, then jumping to email, and back to debugging. Then a barrage of Slack messages, an unexpected call, or even a 'quick' progress call - all within a short time.

Yet this phenomenon isn't confined to developers alone; it’s prevalent across countless professions and can seep into our home lives too. Context switching is essentially the mental gymnastics we perform when shifting our focus from one task to another.

For professionals, particularly those in intellectually demanding fields like software development, context switching is like trying to juggle while running a marathon—you're bound to drop the ball, or worse, burn out before reaching the finish line.

Understanding Context Switching and Its Impact on Productivity

In the pre-digital era, professionals often dealt with tasks sequentially, allowing for a deeper focus on each task. In the industrial era, work was often repetitive and singular in focus, contrasting sharply with today's digital age where professionals juggle diverse tasks. Today, however, the digital age has exponentially increased the frequency of context switching, bombarding us with a constant stream of emails, messages, and notifications. This evolution from a mono-tasking to a multi-tasking work environment has significantly increased the frequency of context switching. This shift has not only changed the way we work but also significantly increased the cognitive load, making it more challenging to maintain productivity and focus.

Context switching is the nemesis of deep work. Deep work requires uninterrupted periods of concentration, fostering an environment where high-quality, productive output thrives.

Studies underscore a grim reality: It's not just a mere minute or two to refocus; the cognitive gears need significant realignment. The toll it takes on productivity is not trivial. The cognitive load imposed by task switching can see developers losing precious minutes of concentration, leading to a dip in productivity.

Let's have a look at some statistics from various researches on context switching done by Atlassian and Reclaim.ai:

It can take a staggering 9.5 minutes to regain workflow post-switch. Some other studies even talk about up to 23 minutes. Imagine the cumulative effect of multiple switches in a day.
97.5% of people cannot multitask effectively.
The average person is interrupted 31.6 times per day.
On average, the loss in cognitive capacity (thus productivity) due to context switching can be upwards of 20%. That is a 'fifth-day' practical loss in a typical work week.
At least 45% of people self-characterized as less productive while context-switching.

Multitasking vs. Multi-Failing

It's a common misconception that multitasking boosts efficiency. However, research consistently reveals that only about 2.5% of people can effectively multitask. Essentially, when we believe we are multitasking, we're often just task-switching with lower efficiency and quality as the unwanted sidekicks.

The takeaway here is stark: context switching, though an unavoidable aspect of modern professional life, is a substantial drain on productivity, creativity, and performance.

So what happens when we context switch, particularly in mentally taxing jobs? Once the interrupted person returns to their initial task, it's not just a matter of picking up where they left off; they must also reload the context of the problem space, which imposes a significant cognitive load. The time needed to resume a previous task isn't just silent time; it's active cognitive effort being expended without contributing to the task's progress.

It's a phenomenon where the brain changes its 'mental control settings' when moving to a new task.

What are the Types of Context Switching?

Factors influencing the disruptiveness of task switching include the nature of the interruption (self versus external), the complexity of the task at hand, and even the time of day. What factors influence the impact of context switches? We can distinguish between a few basic ones:

Switch of topic: we jump to a completely different topic of problem
Switch of depth: we remain in the same problem, but jump to a different level of it
Externally caused switch: someone else actively interrupts us
Internally caused switch: we initiate a switch by our own voluntary decision
Complexity of task: how mentally challenging a given task interrupted by a switch is

For example, complex tasks, such as writing new code or solving software architecture problems, usually suffer more from interruptions than more routine ones, such as checking email or attending regular meetings.

Switching both the topic and depth of tasks is found to be particularly jarring and draining for productivity, indicating the complexity of cognitive processes involved. For instance switching from performing routine, procedural tasks to tackling strategic, high-level thinking imposes an even greater load on our cognitive capacity.

The Unseen Thief: Self-Interruptions and Their Stealthy Toll

Not all interruptions are created equal. While you might assume external factors are the primary culprits in hijacking your focus, the reality appears to be quite the opposite. Research on context switching has revealed some intriguing findings, particularly about self-interruptions.

The urge to switch to a 'quick' secondary task is alluring, yet it leaves us suspended in a state of reduced productivity for longer than we might expect. The "Let me just quickly check the status of that other task" disruption.

It’s somewhat counterintuitive, but those moments when we voluntarily shift tasks - those moments when we decide to switch tasks on our own, think of checking a quick email mid-task - can be more disruptive than if someone else had interrupted us. The autonomy we value so much appears to have its drawbacks, as these self-directed switches tend to lead our productivity astray.

I think this is fascinating. Why? Because it suggests that the mere act of deciding to shift focus is in itself a distracting force.

Through self-interruptions, we disrupt our workflow often underestimating its impact. It appears that the structure of our productivity is linked to our discipline in managing (and resisting) these self-imposed diversions. And for those of us in leadership or team management roles, understanding and guiding teams through the maze of self-interruption can be the key to unlocking higher efficiency and better mental acuity.

Now, while we might not have the power to eliminate all interruptions (some are necessary and valuable), we can create a structure that minimizes unnecessary self-imposed diversions. This includes creating strict "focus zones" in our work schedules or employing stringent, but realistic, communication protocols.

But it's worth noting that voluntary task switching may sometimes be synonymous with poor impulse control.

When we talk about the challenges of context switching, it's important to consider how looming deadlines or upcoming commitments, like meetings, add to the cognitive strain. This aspect is often overlooked, yet it plays a crucial role in how effectively we manage task transitions.

Cognitive Challenges Faced by Agile Software Development Teams

Agile methodologies, with their emphasis on adaptability and collaborative work, have revolutionized the software development landscape. However, even the most well-oiled agile teams are vulnerable to the cognitive overload that context switching can induce.

In agile frameworks, the quick feedback loops and iterative processes demand frequent task transitions. Novice developers especially may find this environment sprouting with cognitive landmines.

The cognitive overhead of managing multiple agile practices can ripple through a team, affecting communication, work quality, and mental exhaustion.

Statistical Insight: A survey found that 45% of agile practitioners named "managing distributed teams" as a significant challenge in agile implementations, suggesting the cognitive complexity of coordinating work across contexts and locations.

Conclusion

In the first part of the series, we've discovered that it's clear that this phenomenon is more than just a minor inconvenience. It's a significant challenge that impacts productivity, software quality, and mental health. We've explored the cognitive tax of context switching.

In the next part of this series, we will shift our focus to the psychological aspects of context switching. We'll examine how it affects our mental well-being and the subtle signs that indicate an overwhelmed context-switching capacity.

Written by Otakar Krus.

The role of continuous feedback in software development

mobile.IT — Thu, 22 Jun 2023 12:01:25 +0000

Just like a boomerang coming back to you, feedback in software development and product management helps you improve. In this article, we're going to explore feedback mechanisms and purpose in its broader sense. Not just person-to-person feedback, but also product, market, and development practices. We'll back up our points with evidence from psychological research, so buckle up for a fact-based feedback adventure!

Several kinds of research have been performed to analyze the relationship between feedback and improvement. In this post, I've picked two well fitting to the world of software development.

By understanding Kahneman's and Melton's researches, we can see why immediate feedback is so crucial to our software development and product management success.

1. The Kahneman study on immediate vs. delayed feedback

In his study, psychologist Daniel Kahneman compares the experiences of anesthesiologists and radiologists to illustrate the difference between immediate and delayed feedback. He analyzed their job's inherent feedback nature. He then assessed the effect of such an environment on an individual's development.

A radiologist is a type of doctor who specializes in medical imaging. Radiologists analyze images, such as X-rays, to help diagnose, monitor, and treat various conditions or injuries. An anesthesiologist is a doctor who gives a patient medication so they do not feel pain when undergoing surgery.

There is one key difference when it comes to the feedback loop.

Anesthesiologists work alongside the patient and get feedback straight away, such as whether the patient is unconscious with stable vital signs. On the other hand, radiologists don't get rapid feedback on their diagnoses, if they get it at all. They often have to wait for weeks or even months to find out whether their diagnosis was correct.

The immediate feedback helps anesthesiologists learn the regularities of their environment and adjust their actions accordingly. As a result, anesthesiologists tend to have a higher success rate in administering anesthesia and managing patients throughout the procedure.

The delay in feedback for radiologists makes it much harder to improve their skills and recognize patterns. Consequently, radiologists typically correctly diagnose breast cancer from X-rays just 70% of the time.

2. The Melton study on predicting freshman success

Richard Melton's study aimed to predict the grades of freshmen at the end of their first year of college. A set of 14 counselors interviewed each student for about an hour and had access to high school grades, several aptitude tests, and a four-page personal statement. Based on this information, the counselors made predictions about the students' first-year college performance.

In comparison, Melton created an algorithm that used only high school grades and one aptitude test as input. Despite the limited information, the formula was more accurate than 11 of the 14 counselors, outperforming them by a significant margin. Melton's study was reported alongside over a dozen similar results across various domains, such as predicting parole violations and success in pilot training.

The key finding of this study is that, in many cases, simple algorithms using limited data can outperform human judgment. This insight can be applied to various decision-making processes where data is available, emphasizing the importance of relying on (simplified) data and patterns rather than solely on subjective assessments of complex factors.

Benefits of continuous feedback in software development

Imagine your software development team as a well-oiled machine. With continuous feedback, the gears are in sync, communication is smooth, and everyone's on the same page. Like Kahneman's anesthesiologists, the immediate feedback loop helps your team adapt quickly to change, keeping them nimble and responsive. Plus, it boosts team morale and motivation, as everyone knows they work together towards a common goal. It's like a software development symphony!

Agile development methods employ short iterations. Those are tools that transform findings from feedback loops into high business value and relevance when performed correctly.

Many teams adopting Agile development approach miss this aspect. It is not sufficient to develop in small chunks and short cycles on its own. If a relevant feedback loop mechanism isn't employed, the whole point of agile development can be missed because the ecosystem does not improve itself.

Techniques for effective continuous feedback in software development

According to Kahneman's concept of deliberate practice, a guitarist can't become an expert by playing the same songs for 25 years. If we apply this logic to our software development team, it needs to be pushed beyond their comfort zone to grow.

Immediate feedback creates a productive learning environment, helping your team members become experts in their craft. Not only can it help your team collaborate and improve individual skills, but it can also give valuable insights into your product's market relevancy, usability, and development practices.

In software development and product management, this translates to the effective employment of metrics, analytics, and user feedback. Developers and managers can make more informed decisions about the product's direction, team performance, and areas for improvement.

Furthermore, implementing continuous integration, automated testing, and regular code reviews can provide developers with a very short feedback cycle, enabling them to learn quickly and avoid making the same mistakes, ultimately leading to a higher-quality product and a more efficient development process.

So let's now be more particular about how to incorporate findings from the mentioned studies in practice. I'll break down typical best practices corresponding to the feedback studies I mentioned earlier.

Applying the Kahneman and Meloton studies to software development

There are several typical ways to foster immediate feedback mechanisms in software development.

Continuous integration

Continuous integration (CI) can be implemented to provide immediate feedback on code changes. As developers commit code to the shared repository, CI tools automatically build and test the application, providing rapid feedback on whether the changes pass or fail the tests. This immediate feedback allows developers to quickly fix any issues, reducing the risk of accumulating technical debt and ensuring the product remains stable.

Code reviews by peers are often an integral part of the continuous integration process.

Testing in minimum increments

By testing in minimum increments the team takes every chance it gets to test a newly written code - even multiple times per day. The smaller the change is, the shorter the feedback loop is. That is why it is so important to have automated processes set up to make this a pain-free process.

Frequent reviews with stakeholders

Another way to incorporate immediate feedback in Agile development is by conducting regular sprint reviews and surveys with stakeholders and end-users. These reviews provide an opportunity for the team to demonstrate the functionality they have completed and gather feedback from stakeholders.

Qualitative or quantitative surveys provide in-depth feedback and sanity checks. The team can then use this feedback to prioritize work for the next sprint, ensuring that the most important features and improvements are addressed promptly.

Retrospectives

An analogy of reviews, which are outward-oriented, are retrospectives. While it is more inward-focused, it is a great tool to provide access and obtain immediate feedback from within the team. There is no need to keep rigorous and employ complex or sophisticated mechanisms, keeping it as a simple and to-the-point discussion is often sufficient.

Leveraging the Melton study in software development

The Melton study demonstrates that simple algorithms using limited data can outperform human judgment. In software development, this insight highlights the importance of relying on data and patterns to inform decision-making, rather than solely on subjective assessments.

Using metrics to inform backlog prioritization

One way to apply data-driven decision-making in Agile development is by using metrics to inform backlog prioritization. For example, a product manager could analyze user engagement data, customer feedback, and bug reports to determine which features or improvements should be prioritized in the backlog. By using data to inform these decisions, the development team can focus on the most impactful work, ultimately leading to a better product that meets the needs of its users.

The takeaway here is that the statistics don't necessarily need to be extremely complex and sophisticated. Quite the contrary - a simple but highly relevant metric helps tremendously. Such simple metrics can be user story completion rates, velocity measurement, net promoter score, time to restore a service etc. Metrics that are really trivial in principle.

Managers can identify trends and patterns that indicate strengths and weaknesses by collecting data on the team's velocity, code quality, and other relevant metrics. People sometimes evaluate snapshots of situations without seeing the trends.

This data-driven approach can lead to more effective and efficient development teams.

Tips for making the continuous feedback work

Now that we've explored the what, why, and how of continuous feedback, let's talk about making it work in real life. First, create a feedback-friendly culture where team members feel safe to share their thoughts and ideas. Encourage open communication and make feedback sessions a regular part of your team's routine. This is paramount, without a culture valuing honesty, feedback receptiveness is greatly hindered.

A side note for managers: this culture of human-to-human feedback goes both ways—be receptive to the feedback you receive and use it to sharpen your own skills and processes.

But wait, there's more! We must broaden our understanding of feedback by extending it beyond the individual level. Design the entire development system to generate and be responsive to feedback, encompassing aspects such as development practices, product quality, financial efficiency, and any other aspect crucial to the product being developed.

A strong emphasis on feedback loops is a crucial factor that distinguishes traditional waterfall development methods from Agile development. Simply adopting short iterations and frequent planning cycles isn't enough to fully embrace the Agile philosophy if feedback reception mechanisms don't exist. Establishing a system that generates and processes feedback is absolutely essential. Being able to gather feedback and react to it is Agile's primary objective.

Conclusion

Just as a chef needs to taste his dish while cooking to ensure the flavors are on point, continuous feedback is an essential ingredient in the recipe for successful software development and product management.

By embracing feedback in various forms - from human-to-human interactions to product metrics and beyond - you'll create an environment where learning, growth, and improvement thrive. So go on, add a dash of continuous feedback to your development process and watch the magic happen!

Written by Otakar Krus

The Myth of Bigger Teams: Why Smaller Can Be Better

mobile.IT — Fri, 12 May 2023 08:25:56 +0000

In an effort to counter inefficiency and increase productivity, organizations often turn to increasing team size. The logic seems sound: more people means more hands on deck to tackle tasks and solve problems. However, this approach can often lead to growing overhead and inefficiencies.

Research has shown that small teams can often be more effective than larger ones. A study published in Harvard Business Review found that while large teams do advance and develop science, small teams are critical for disrupting it. Another study published in Forbes found that there is an ideal team size at which the benefits of putting more heads together are maximized and the drawbacks minimized.

So why do smaller teams often outperform larger ones? One reason is that large teams are more likely to have coordination and communication issues. Getting everyone on board for an unconventional hypothesis or method, or changing direction to follow a new lead can prove challenging with a larger group.

In contrast, smaller teams can be more nimble and adaptable. With fewer people involved, decision-making can be faster and communication more streamlined. This allows small teams to quickly pivot when needed and respond rapidly to changing circumstances.

This phenomenon is not limited to software development or business settings. In fact, examples can be found across different fields including military operations where smaller units are often able to operate with greater efficiency than larger ones.

Thus bigger isn’t always better when it comes to team size. Sometimes a highly productive team of 8 senior people can achieve better results than a mixed group of 60. Organizations would do well to consider this when trying to counter inefficiency.

Effects of team size on performance

But how exactly does this play out in practice? Let’s take a closer look at some real-world examples.

As more people are brought in to accelerate progress, it#39;s not unusual for software development projects to expand in size, a phenomenon known as ballooning. However, this approach can often backfire as communication becomes more difficult and coordination issues arise.

For example, imagine a project with 60 developers working on different parts of the codebase. With so many people involved, it becomes increasingly difficult for everyone to stay on the same page. Code conflicts become more common as developers unknowingly overwrite each other’s work. Meetings become longer as everyone tries to get up-to-speed on what everyone else is doing.

Now imagine the same project with just 8 highly skilled developers working together closely. Communication is easier because there are fewer people involved. Coordination issues are less likely because everyone has a clear understanding of what their colleagues are working on.

In the military, for example, special forces units like Navy SEALs or Army Rangers typically operate in small teams of around 8-10 members. These elite soldiers are highly trained and capable of operating independently from larger units.

In contrast, traditional infantry units may have hundreds or even thousands of soldiers operating together in large formations. While these units have their own strengths such as overwhelming firepower or logistical support capabilities they may lack the agility and adaptability of smaller special forces units.

Automation as an integral part of an organization

As companies grow and evolve, it’s important to consider the impact of organizational change on teams and processes. One key area to focus on is automation. By automating tasks and processes, companies can improve efficiency and reduce the need for manual labor. Let’s take a closer look at how automation can affect teams and collaboration.

Automation can have a significant impact on organizational change. By automating tasks and processes, teams can minimize manual effort and errors, and enhance feedback loops throughout the software development lifecycle. This can lead to smaller chunks of better-quality code releases in less time. Automation can also reduce the need for basic data-input and -processing skills which will be particularly affected by automation.

The adoption of automation technologies will transform the workplace. Deliberately automating aspects of testing, code styling, integrating, and deploying should aim to reduce the time and human labor needed to develop, deploy and verify the product increment. DevOps automation is applied across the entire lifecycle, including design, development, software deployment, and release, as well as monitoring.

The primary objective of DevOps automation is to streamline the DevOps lifecycle by reducing manual workload. This automation results in several key improvements: it lessens the need for large teams, drastically reduces human errors, increases team productivity, and creates a fast-moving DevOps lifecycle.

Why avoiding larger teams may be beneficial

Some common antipatterns may arise when trying to involve more people rather than keeping a small team. As organizations grow in size they may implement measures such as code freezes or external approvals for deployment in an attempt to manage complexity. While these measures may provide some benefits they can also hinder agile development by slowing down decision-making processes.

They might as well include authoritative behaviors where senior members impose their will on others or create an environment where team members form informal silos within the team based on common interests. This all leads to a lack of trust where team members don’t trust each other’s abilities; this in turn keeps them from delegating tasks effectively. The whole environment just becomes much harder to work in.

In actuality, the bulk value or result created by a smaller team might be even bigger (let alone cheaper) than the result yielded by a larger yet rigid group. Smaller teams have fewer coordination issues, this allows them to make quicker decisions and deliver faster results.

When undergoing an agile transformation, companies should consider carefully how they scale agile development across multiple teams in order to avoid unnecessarily large teams. One way companies can achieve this is by creating cross-functional teams which helps reduce the need for scaling agile by merging various departments together.

Sometimes, however, having large teams becomes a necessity when the product is large and complex. In spite of this, there are frequent cases of software development where teams that could have stayed small if transformation had been done right. In such cases product size is still manageable by a small team, but a large group is now working on it. In such situations companies should aim at creating cross-functional teams, this reduces the need for scaling agile by merging various departments together.

Conclusion

To wrap up, here are a few basic areas for consideration:

Conduct a thorough analysis: Before scaling up, teams should conduct a thorough analysis of their current processes and workflows to identify areas that may benefit from additional resources. This can help teams avoid adding unnecessary team members and instead focus on areas where additional resources will have the greatest impact.
Consider alternative approaches: Teams should also consider alternative approaches to scaling such as implementing new technologies or processes that can help improve efficiency without necessarily adding more team members.
Automate everything possible: Teams should automate everything necessary to minimize manual effort and errors, enhance feedback loops throughout the software development lifecycle. An effective continuous integration/continuous delivery (CI/CD) pipeline integrates automation tools and workflows an organization needs to build, compile, test and release its applications. Remote development teams cannot rely on end-users to perform robust user acceptance testing. They will need to automate platform, API, functionality, performance, and security testing.
Develop a clear plan: Teams should develop a clear scale-up plan that should include timelines, milestones and metrics. This can help ensure that everyone is on the same page and working towards a common goal.
Involve all stakeholders: When considering scaling up, it#39;s essential for teams to involve all stakeholders in the decision-making process to ensure their inclusion. This includes not only team members but also customers, suppliers and other partners who may be impacted by the decision.

The key takeaway here is that organizations should carefully consider team size when trying to counter inefficiency or improve productivity. While adding more people may seem like an obvious solution it may actually lead to growing overhead and inefficiencies. While there may be instances where expansion is inevitable, disregarding the potential benefits of remaining small can prove to be expensive.

Otakar Krus
Twitter: @otakarkrus

How Management Buy-In Affects Agile Transformation

mobile.IT — Thu, 06 Apr 2023 11:35:51 +0000

Agile transformation can be a powerful tool for businesses looking to improve efficiency, productivity, and flexibility. However, the success of an agile transformation is often tied to management buy-in. As I've written in my previous post, in many cases, the motivation for an agile transformation comes from believing that the current organizational structure is misaligned and that agile will be a cure-all solution. Management may also have unrealistic expectations of the transformation process.

In reality, management must play an active role in the transformation process, working collaboratively with teams to identify and solve problems. This requires a willingness to hear bad news, make difficult decisions, and address structural and systematic issues that may be inhibiting agility, such as overly complex organizational hierarchies, rigid technologies, and inflexible approval processes. Without this buy-in and active participation, agile transformations can become nothing more than a superficial change with little real impact on efficiency or productivity.

Definition of management and leadership

There are multiple definitions of what management actually is. Let me cite the two classical ones:

Harold Koontz: "Management is an art of getting things done through and with the people in formally organized groups. It is an art of creating an environment in which people can perform and individuals and can co-operate towards attainment of group goals."

F.W. Taylor: "Management is an art of knowing what to do, when to do and see that it is done in the best and cheapest way."

So basically, when it comes to transitioning to an agile approach, there are two key takeaways managers need to keep in mind: first, they're responsible for creating an environment where people can be productive, and second, they need to figure out what to do when others are uncertain.

In addition, it is worth mentioning that although there is an overlap between the skills and qualities of a manager and a leader, they are not the same. A manager oversees and directs a team or organization to achieve its goals and objectives, while a leader inspires and motivates people to work towards a shared vision or goal. Although it is ideal for a manager to also possess strong leadership skills, it is not always necessary for a manager to be a leader as they can still effectively manage a team without necessarily inspiring or motivating them. However, in many cases, having strong leadership skills can enhance a manager's ability to manage their team effectively.

How does this apply in the context of an agile transformation?

Top-down approach to agile transition

From what I've seen, a few key attributes are critical for a successful top-down approach to agile transition. Managers must be willing to hear "bad news" and make active decisions in the business's best interests. The "average employee" in the company needs to be encouraged by managers to identify obstacles and suggest both workarounds and proper solutions.

To ensure smooth and effective work, managers must make their visions and expectations clear to team members. Although structural changes may hinder progress, it's important to recognize that some changes take time. A shared vision can motivate team members to find workarounds in the interim, while also fostering the belief that higher-level management is actively working towards a long-term solution.

Having clear orientation, vision, and understanding of context on a higher level can greatly improve motivation, productivity, and the relevance of solutions during an agile transformation. It can lead to more efficient and effective solutions as they are developed with the bigger picture in mind. A sense of direction and a clear vision can be a powerful motivator for people to persevere through challenging times. Like seeing the horizon during turbulent waters, it provides a sense of stability and purpose that can help individuals stay focused and productive. It's the leader's responsibility to ensure such a vision exists and is understood by others.

Don't take it personally

Managers who resist hearing strategic-level criticisms can hinder the progress of agile transformation. It's important not to take it personally. The broader the problem, the more difficult it is to resolve. Attempting to fix it carries both risk and reward, which is why the agile transformation was initiated in the first place.

When managers view criticism or obstacles as a cover for employee incompetence or failures, it can create a lack of trust that hinders effective management. This can lead to a tendency to micromanage and excessively monitor employees, which can ultimately undermine all the transformation efforts. Eventually, a lack of trust can lead employees to keep their ideas to themselves to avoid potential conflicts or arguments with their managers. This can hinder creativity and innovation and create a toxic work environment where open communication and collaboration are discouraged.

It's crucial for managers to actively participate and collaborate with their teams, facilitating problem-solving and decision-making instead of expecting the teams to sort everything out themselves. Some obstacles are outside the control of individual teams and require higher-level interventions or support from the organization.

Make decisions - that's what leaders are supposed to do

Decision-making in a business context involves a shared responsibility between managers and lower-level colleagues. Effective managers take responsibility for their decisions, even in the face of uncertainty. They actively seek out the information they need to make informed decisions and recognize that some situations may not have enough information, yet still require a decision. In contrast, some managers may try to shift responsibility elsewhere rather than taking ownership and accepting accountability for their decisions in such situations out of fear of failure. It is essential for managers to understand that managing uncertainty is a critical part of decision-making and to accept this responsibility. Lower-level colleagues play a crucial role in facilitating decisions by providing valid, precise, complete, and most importantly honest information.

To handle critical decisions, organizations can foster a culture of experimentation and testing or establish a structured approach to collect and analyze data for making informed decisions. By exploring various scenarios of potential outcomes, measuring their impacts, and proactively engaging with such models, organizations can break free from this pattern.

Effective managers approach decision-making with a healthy dose of skepticism, validating and cross-checking data before making any commitments. This also applies to creating plans and commitments during the sales process. It's important to note that the criticism and ideas for improvement from individual teams may not just involve structural and technical aspects but also target plans. A common pitfall is when experts are not involved in the sales and planning process, resulting in unrealistic plans. In such cases, the team should not be held accountable for being unable to adhere to an unrealistic plan. Creating such a plan is a decision that involves risk, which managers are responsible for evaluating, managing, and accepting. Agile transition might painfully expose such naive plans.

Delegating competence and responsibility is an essential aspect of effective management. However, it's important to note that managers should also be willing to accept the consequences of delegation.

Overcoming fear and lack of trust

The fear of change can often hinder the agile transformation process, and many managers may be hesitant to make changes due to various fears that are common to any human being. These fears include fear of failure, fear of the unknown, fear of losing control, fear of job security, fear of being exposed as incompetent, fear of losing status or power, fear of conflict or opposition, and fear of the extensive changes required by the agile transformation process. However, effective managers and organizations are able to recognize and manage these fears, while still moving forward with the necessary changes to improve outcomes. It is important not to take these fears personally, but instead to approach them with a solution-focused mindset - because paralysis may be the other option.

Fear and lack of trust can be significant barriers to organizational success, particularly during a transformation toward an agile culture. Although these feelings are valid and may have justifiable reasons, they can ultimately hinder progress. For an organization to move forward and become more effective, it is essential to foster trust, delegate competencies and responsibilities, and empower employees to make decisions. Most individuals are naturally motivated by changes that save time and effort, and a culture of trust and collaboration can facilitate this motivation toward achieving organizational goals.

By fostering a culture of trust and collaboration, organizations can overcome fears and barriers to agile transformation and empower employees to take actions that save time and effort.

Otakar Krus
Twitter: @otakarkrus

How flawed motivations can derail Agile transformations

mobile.IT — Wed, 08 Mar 2023 12:26:22 +0000

Agile transformation has become a buzzword in the business world. Companies are eager to jump on the bandwagon and adopt Agile methodologies. The belief is that Agile transformation will increase productivity, efficiency, and speed, simplifying everything and making it faster. While this can be the case when done right, if the sole motivation for Agile transformation is focused on these outcomes and the company has a delusional idea about how difficult it will be to achieve them, things will go south. It's always a lot bumpier than anticipated.

This post is part of a series about the most common Agile transformation pains, as I've witnessed them in the organizations around me. This series focuses on the top-down hindrances.

Speed, efficiency, transparency

What's incorrect about the motivation mentioned above? Don't efficiency, effectiveness, transparency, flexibility, and speed embody the characteristics that the Agile culture promises?

In my view, the reason it falls short is that it lacks a crucial and integral aspect of Agile methodology, which is the concept of "failing fast" and promptly identifying and showcasing obstacles and challenges impeding progress. A true willingness to find problems sooner and improve collaboration must also be an integral and true part of the motivation.

The misconception I mentioned is problematic because it creates unrealistic expectations for what agile can achieve. Agile is not a quick fix for organizational problems. It's rather a fundamental shift in the way a company operates. It is a way of working that requires collaboration and a willingness to adapt. Everyone, including the senior management, must be willing to collaborate with teams to improve the environment for Agile work. The whole motivation stems from the belief that problems are caused by the disorganization of teams and wrong organizational structures.

Transformation project - its end is just the beginning

Regrettably, Agile transformation is often viewed by management teams as a silver bullet solution to a company's organizational issues. They mistakenly perceive it as a short, one-time investment that will provide immediate and long-lasting benefits. This misconception can lead to an overly simplified approach to Agile transformation, which does not consider the ongoing effort required to sustain it. Agile transformation requires continuous effort and commitment from both management and the teams involved.

Many managers mistakenly believe that adopting Agile is as simple as calling it a transformation project, allocating a budget, giving the project a fancy name, hiring consultants, and conducting a bunch of trainings. They think that these actions alone will suffice to achieve the transformation and their job is done. People just pat themselves on the back for renaming project managers as scrum masters and officially closing the transformation project. And then they sit back while the teams "self-organize" and Scrum Masters magically remove all obstacles. But that's not how it works.

Organizations often face structural and systematic problems that impede their agility. Every company has some - just their depth varies. These issues can manifest in various ways, including overly complicated organizational and decision-making hierarchies, dependence on inflexible technologies, convoluted deployment procedures, and rigid approval processes, just to name a few typical ones.

For example, a company that releases software updates twice a year with numerous dependencies, code freezes, centralized testing, and lengthy development-testing-acceptance loops will likely encounter significant obstacles when adopting Agile methodologies. The legacy processes and technology stack may be quite incompatible with Agile workflows, making it a challenge to achieve the desired level of flexibility and speed.

These inherent problems won't magically vanish during an Agile transformation - they'll just become painfully obvious and urgent. The good news is that teams will finally feel comfortable talking about them and trying to tackle them head-on. Problems will be found everywhere.

Beware of creating a Potemkin village

The flipside is that if this is not expected to happen, the whole transformation won't work. One must be willing to hear the "bad news" and be ready to make proactive decisions.

After years of simply accepting the problems, teams will suddenly start shouting from the rooftops about these issues, and senior management needs to step up and work with them to make the workplace more agile-friendly. If they don't, teams will remain stuck in a rigid environment. Everyone will just call himself with a new title, such as product owner or Agile coach. This reorganization is likely to be seen as "another waste of money" and a failure, with many concluding that "Agile doesn't work". A Potemkin village.

All levels of an organization need to be ready to face these challenges and work together to find solutions. A decision to adopt Agile is just the first step. Even the managers must be ready to roll up their sleeves and get involved in identifying and solving problems that arise during the transformation. It's a team effort, and everyone needs to play an active role. The more complex the business structure is, the longer the whole transformation will likely take. This is an ongoing process that is unlikely to ever come to a complete end. But the deciding factor is if there's actually a will to start and keep undergoing an uncomfortable change.

One surprising fact about Agile transformation is that it might lead to more bureaucracy if not implemented correctly. For example, suppose a company adopts Agile without addressing underlying issues such as convoluted decision-making processes or rigid approval procedures. In that case, it may inadvertently create more bureaucracy by adding more layers to the process. This is because Agile requires constant communication and collaboration, and if these processes are not streamlined, it can result in even more delays and inefficiencies.

True motivation: A sense of security

In my experience, failed attempts at agile transformation often stem from a common underlying issue: a lack of trust. This can manifest in various ways, such as a tendency to monitor and control teams closely. After one such transformation I've seen teams being required to share their sprint commitments, burn-down charts, and velocities, and then having to explain themselves when they don't meet those metrics. This happened at the senior management level.

Such reporting activity created a false sense of security by prioritizing the appearance of stunning charts and numbers on paper rather than the actual value of the work being done. The focus was on keeping commitments rather than questioning the sense of those commitments and the overall plans. Needless to say, what was missing was a critical examination of the actual business value of the effort invested and the value of the things developed. So it was quite obvious what the true initial motivation for Agile adoption had been.

Do you really want to go Agile?

In conclusion, Agile transformation can be a powerful tool for organizations looking to improve their productivity, efficiency, and speed. However, it is essential to approach it with realistic expectations and a willingness to address underlying structural and cultural issues. Agile transformation is not a quick fix or a one-time investment but requires continuous effort and commitment from all levels of the organization. Managers must be ready to roll up their sleeves and work with their teams to identify and solve problems that arise during the transformation.

Furthermore, it is crucial to approach the transformation focusing on business value and not just metrics and appearance. So, before embarking on the journey of Agile transformation, think twice and ensure you are willing to fully commit to the process. Going Agile is about being able to react more fluidly to changing business circumstances, isn't it? If there's little willingness to address the underlying issues that hinder progress, what's the point of identifying them in the first place? That by definition hinders the fluidity from happening.

If fundamentally changing an organization, including its core cultural, technical, and process aspects for the better, isn't the honest motivation, then maybe it will be more comfortable to maintain the status quo and save the embarrassment that an attempt to perform an Agile transition would inevitably bring.

Otakar Krus
Twitter: @otakarkrus

Challenges of Agile Development with Fixed Contracts

mobile.IT — Thu, 02 Feb 2023 11:31:15 +0000

In today's fast-paced business world, clients are constantly seeking the best of both worlds: the flexibility and speed of agile development, as well as the perceived safety of fixed-time fixed-price contracts. This trend of blending agile delivery with fixed contracts is becoming more and more prevalent as clients aim to find a balance between agile freedom and contractual security.

One potential reason behind this trend is that clients may be hesitant to enter into a lease agreement with a development team and instead opt for a fixed-time contract. This uncertainty may stem out of the unknown, a belief that a fixed contract offers more security for the scope of work, doubts about the supplier's ability to deliver on the agreed scope, or the client's own internal processes that prevent them from entering into such agreements.

This post covers such a hybrid model from the supplier's perspective.

Uncovering the pitfalls

When implementing an agile approach with a fixed-time fixed-price contract, a common structure involves a product owner from the client company. This dynamic can bring its own unique challenges as the supplier company is bound by the scope and price outlined in the contract, with the product owner significantly impacting the return on investment. In this scenario, trust is of the utmost importance as the supplier must rely on the product owner to make well-informed decisions regarding the project's direction and priorities.

One of the main risks for the supplier associated with this approach is the potential to deviate from the contract scope. Suppliers may want to do so to accommodate the client's requests and be more agile. However, as the contract is legally binding, the client may take advantage of this deviation and exert pressure on the supplier team. This poses a significant threat to the project's financial success as the supplier team may have already allocated budget towards items requested and discovered during the course of the project, leaving the client in a position of power and potentially exploiting the supplier team to the detriment of the project's outcome.

Furthermore, the typical behavior of a product owner in this situation is to focus on completing one feature area (epic) before moving on to the next rather than maintaining constant prioritization. This can lead to the desire of perfecting everything before progressing, causing further delays to the project and potentially damaging the supplier's budget. On the other hand, suppliers may have to fit the project budget at all costs, resulting in a loss of quality. The combination of both phenomena can be deadly.

Balancing Flexibility and Control

Balancing the complexities of agile development within the constraints of a fixed-time, fixed-price contract can be a challenging task. From a supplier's perspective, effectively balancing the benefits of agile delivery with the security of a fixed contract requires a strategic mindset from the very beginning. One common trap is for the supplier to overestimate the control of the product owner over the project scope without involving the development team in the process. To avoid this, it is essential to engage in ongoing negotiations about how newly prioritized items will affect the original scope and what to deprioritize.

The main motivation of the business relationship described is to deal more effectively with unplanned and unexpected work. Maintaining transparency about unplanned scope items that have been delivered and what needs to be exchanged is crucial. By implementing these practices from the beginning, the mindset of "trading" one item for another can become ingrained in the team's nature and working style.

It's also vital that the client understands from the outset that while an agile approach brings added flexibility in making the product more relevant and potentially better, it does not equate to a wildcard for obtaining more for less. The responsibility for decision-making goes hand in hand with this approach and must be made clear by the supplier's team. Furthermore, involving the development team in the process is crucial to ensure that the project stays on track. The team should be responsible for providing rough estimates of newly discovered items, allowing the product owner to make more informed decisions about prioritization.

Ultimately, managing scope in fixed-time fixed-price contracts relies heavily on a mutual understanding between the client and supplier. Therefore, honesty and transparency are crucial for the success of this approach. The supplier must provide realistic and accurate estimates for newly discovered items and be transparent about any obstacles or issues that arise during the project. Tracking development velocity may also be beneficial. In return, the client must be honest about their expectations and priorities and be willing to make trade-offs to keep the project on track.

Building trust through honesty and transparency is key to the success of this approach. Furthermore, having a solid understanding of the client's business and goals can help the supplier team to better align the project's scope and priorities with the client's needs and anticipate any potential roadblocks or challenges that may arise during the project.

Make the contract work in favor

Navigating the choppy waters of agile development with fixed contracts may seem like a breeze at first, but in reality, it takes a steady hand and discipline to steer the ship toward success. Creating a successful contract for agile development with fixed-time fixed-price contracts requires a balance of flexibility and control. As a supplier, it's important to approach the contract with a defensive mindset, taking into account that clients may not always be upfront about their expectations or try to expand the scope. Here are some key points to keep in mind:

Be cautious when crafting the scope and contract, being aware of scope items that are prone to inflation, and carefully formulating them in the contract. Clearly state that anything outside of the scope is considered a change request, and anything not explicitly mentioned is out of scope.
Use the difficulty of defining a comprehensive scope in an initial contract to your advantage by stating that nothing not explicitly mentioned in the contract is included, which can level the playing field and motivate the client to be fair when trading new items for the original scope.
Create flexible payment milestones that can accommodate changes in the scope and maintain cash flow. For instance, the milestones can be triggered once a scope worth X gets finished.
Describe the roles and responsibilities of key stakeholders from the client, such as the product owner, key users, and testers, to ensure smooth and efficient communication and decision-making throughout the project. This includes specifying that decisions and feedback must be provided quickly to avoid delays and blockages on the supplier's end.
Such definition should include the process for acceptance and sign-off of scope items throughout the duration of the contract, rather than waiting until the end of the project to ensure efficient progress and increase transparency.
Clearly define general acceptance criteria for scope items and require a continuous client testing and acceptance process throughout the project.
Keep in mind that the client company may try to enforce delivery of the entire defined scope while diminishing the value of the items developed extra, and make sure the contract reflects that.

In conclusion, while combining agile development with fixed-time fixed-price contracts can be tricky, it can also offer benefits for both parties. The contract should be viewed as a framework, keeping the development team working within a certain timeframe. The supplier should be mindful in formulating the scope items, making it specific enough for the client to have an idea of the product but not so strict that it limits the supplier's flexibility. Furthermore, trust and open communication between the client and supplier are vital in ensuring the project's success. It's important to be prepared for the fact that the client may try to enforce the original scope and to write the contract with that in mind. It's important to remember that the contract should serve as a backup plan in case things don't go as planned. But from experience when a contract gets pulled out and evaluated along the project, it is a telltale sign that the project is already in severe trouble. Thus the primary focus should be on building mutual trust through transparency and honesty. This approach is the most effective for successful long-term project outcome for both parties.

Still, there is no doubt that using a traditional agile delivery contract by hiring a team of experts is usually more beneficial for all stakeholders than adopting a hybrid approach when the situation allows.

Otakar Krus
Twitter: @otakarkrus

Architectural missteps in view, presentation, and navigation

mobile.IT — Tue, 20 Dec 2022 13:41:56 +0000

Every system and architecture tackles the test of time. It's an unfair battle, almost impossible to win. That doesn't mean we should surrender and hack unsustainable components without the ambition of longevity. We must develop them to deal with this challenge gracefully and try to defer the inevitable as long as possible.

Nothing lasts forever, though, especially in a fast-moving industry like mobile app development, and some missteps are bound to bubble up along the way. Let's define the most common and explain possible ways to avoid them.

Overly logical view

Let's start with an obvious one, an arch-enemy to any solid architecture—a view that does way too much.

The view is an excellent, self-describing name for a software component. Its purpose is to view what's happening inside the system in a user-comprehensive, preferably friendly way. It renders to the screen, listens for content updates, and delegates events to someone else to handle.

When there's a need for an extensive user-interface redesign, it's the view's role to step up, take all the heat, and keep all the vital bits of the application unchanged. It's a straightforward process, as no important presentation or business logic gets in the way.

That's an example from an optimal world where the view is a thin layer that does just the minimal job it should. Yet some programmers complicate the layer with additional logic, like persistence, state management, or navigation. Those should have their foundation elsewhere, and it's no surprise that dealing with all this extra complexity might prolong redesign estimates from a few days to a couple of months.

As system and platform designers, Google or Apple aren't leading by example either. On the contrary, they encourage programmers to place too much weight on their views' shoulders by providing them with components that require such an approach. One example for all: the FetchRequest property wrapper, defined in SwiftUI, fetches entities straight from the Core Data store. To quote usage from docs: "Use a FetchRequest property wrapper to declare a FetchedResults property that provides a collection of Core Data managed objects to a SwiftUI view." Ironic slow clap for encouraging programmers to couple views with data storage.

There are plenty of wolves in sheep's clothing, so keep your guard up and remember—just because you can doesn't mean you should. Your view should preferably not do much. The thinner the view layer is, the better. UI tends to change quite often, and keeping the view layer lean is a good practice for making swift and safe changes.

Almighty view models

As part of the presentation layer, view models are responsible for formatting content for the view and handling its events. It should be a comprehensive component, a little helper for the view, listening for changes, and handling presentation logic that lightens the load for the view.

Usage varies per project, but typically, it observes an application's state, transforms it into user-presentable data, and notifies the view. Unlike views, they are independent of UI frameworks, which makes them easily testable. That's not just icing on the cake but a massive step towards robustness.

However, they are often misunderstood and create a cesspool for what didn't fit elsewhere. So it happens that they handle business logic, navigation, and all other bits that don't have an official place elsewhere. Some scoundrels even compose requests and deal with networking! That's wrong on many levels; it defies the separation of concerns and tries to fit multiple components into one. This misplaced logic is not reusable and complicates further development on top of that. Such view models span hundreds of lines and compel us to recall massive view controllers from the Objective-C era.

Overly bloated view models are often present in architectures designed by proponents of MVVM who, in naive pursuit of simplicity, argue that three-layered architectures should easily cover all needs. Simplicity is, without a doubt, one of the goals, but the multi-hundred-line view model is anything but simple.

MVVM is not an architecture. It's a pattern describing how to structure the application’s presentation layer. It would be unwise to build a complete application around any pattern. Why should MVVM be an exception?

Should you find yourself struggling with where to put something in codebases where the MVVM pattern serves as an architecture of the whole system, you might be on the right track. Navigation, networking, business logic, and many others don't have a well-defined place in incomplete architectures. You can lift the burden from view models with proper domain modeling, define a spot for all those other concepts, name them, and be one step closer to a clear and comprehensive design.

Lost in navigation

In the early days of mobile application development, we didn't emphasize navigation much. Widely adopted architectural patterns such as MVC or MVP didn't have a letter in their name designated just for navigation, so we solely used system components such as UINavigationController, Activity, and Fragment, respectively, Storyboard segues. But these are massive system frameworks mainly “designed” for UI presentation. Their basic use complicates the view and further couples with the interface builder (used for scene designing) in the worst case.

Fortunately, things have gotten a lot better in the last few years, and with architectural enlightenment have come plenty of new designs. Some have even had their opinion or designated components on how to handle navigation. That's how coordinators, wireframes, flow controllers, and so on came to be. However, extracting the navigation into its place has revealed issues hidden in plain sight, such as sharing data between the screens. Some architectures do address this, but it is often neglected or misunderstood, so state propagation becomes another navigation responsibility.

The state dramatically complicates the situation for everyone involved in navigation. It must be obtained from the call site and passed to the next scene, which decides where to store such an incoming state. And it doesn't just end there. Once you wish to return to the previous scene, you need to take the state back with you and decide whether or not to replace the last one. That doesn't sound very easy, even for small-scale apps; imagine making sense of this in an app with hundreds of screens.

When you take a step back, however, you will notice that it is not so much a question of navigation. The problem is in state propagation and its coupling with navigation. Decoupling state to its place significantly improves usability, testability, and simplifies navigation. It also makes it clear as to who owns the state and where the source of truth is.

Architecture-agnostic

The post might seem to focus more on a separation of concerns than architecture, but those two go hand in hand. Once you realize the bloated multipurpose components are too hard to tolerate, you start to look for something more cultivated than three-word patterns dressed as architectures. More layers do not equal more complexity. They bring order, and clarity, and leave no place for presumptions (which lead to unwelcome pull-request surprises and heated discussions).

The resulting product is not the only and most important value we produce. By making the software genuinely soft, we can deliver continuously, with the same effort, and in the long run. That's an essential feature valued in any field by any business.

Libor Huspenina
Twitter: @liborhuspenina